The `main' module depends on `path', not the other way around, just to
be sure to keep away compilation warnings or double compilation compile
`path' first.
Add an optional directory parameter to the `config update' and `config
hooks' commands, which, if specified, will limit any updates to the
given repository.
When checking when a repository is known or not be sure that there is
actually a chance that we are looking at a repository. If the thing to
be checked is neither a `<repository>' instance nor a string it's sure
that it's also not a registered repository.
Fixes an error that would cause values to be duplicated when specifying
multiple values for a setting.
Prior to this commit specifying multiple values for a setting would
blindly replace one occurrence and add the rest, leaving any possible
other occurrences intact. When starting fresh this would not be a
problem, but using it multiple times would add the same settings
repeatedly.
- gitto/config.scm (merge-setting): If the given value is a of type
`list', replace the `%a' specifier for each item in it.
- gitto/config.scm (merge-settings): Move the handling of the case of
`v' being a list into `merge-setting'.
- gitto/config.scm (split-setting): Rename `parse-setting' to
`split-setting'. Return a cons cell instead of a list.
- gitto/config.scm (read-setting): New function.
- gitto/config.scm (read-config): Remove unused variable. Use
`read-setting' to get the right value for each line of the config
file.
- gitto/config.scm (write-setting): In case we're dealing with a list,
print each value separately.
Setting a list as a value for `global-config' will instruct gitto to
place that setting in the config more than once. For example:
,----
| (set! global-config
| '(("remote \"origin\""
| ("url" . "git@somehost.com:~a.git")
| ("pushurl" "git@somehost.com:~a.git"
| "git@someotherhost.com:user/~a.git"))))
`----
Will produce output similar to:
,----
| [remote "origin"]
| url = git@somehost.com:repo-name.git
| pushurl = git@somehost.com:repo-name.git
| pushurl = git@someotherhost.com:user/repo-name.git
`----
The ordering may vary depending on what was already found in the
`origin' remote's settings.
gitto doesn't know or care which settings can and cannot appear more
than once in a configuration, it is up to the user to provide valid
values.
Introduces a new user configuration variable `hook-alist', which
specifies which hooks to link to which executables, for example:
,----
| (set! hook-alist '(("commit-msg" . "/path/to/my/commit/msg/hook")))
`----
With this setting the command `config hooks' will install
`/path/to/my/commit/msg/hook' to the `commit-msg' hook of each
repository not in the `config-exclusion-list' setting.
The `add' command will ask the user if they would like to merge their
settings with the newly registered repository's if the current input
is a tty and if the user has specified some settings.
The default for this is `#t', so pressing <RET> when presented with
this question will merge the settings, however if the user is never
asked (because the input is not a tty) no merge will happen.
The `pkg-config' program needs to know about the prefix DESTDIR to
determine where the files in `src/' should be installed. If this
option is not passed along to `pkg-config' it will always try to
install in `/usr/'.
Now instead of using `gitto --register' or `gitto -r' one would use
`gitto add'. Here is the list of what was and what is:
--version, -v => version
--help, -h => help
--register, -r => add
--remove, -R => remove
--repositories, -l => list locations
--purge, -p => purge
--check, -c => check
--config, -C => config
--global-config => config global
--update-config => config update
Running gitto without arguments keeps the same functionality, though
it can also be called as `gitto list'.
The variable `config-exclusion-list' can be used to specify project
names that should not have their configuration overwritten by
`gitto --update-config'. It is a normal list of strings which name the
repositories that should be left alone, like so:
(set! config-exclusion-list '("repo1" "repo2" "repo3"))
- The `register-repository' procedure was using a non-existent
procedure `repository-name', this should be `repo-name'.
- The `purge' procedure was working on a collection of `<repository>'
objects, but assuming they were file names, the `repo-location'
should first be extracted before calling `file-exists?'.
Unlike some other lisps scheme's `unless' returns `#<unspecified>'
instead of nil, and `string-append' doesn't accept this as a valid
argument. So use an empty string if XDG_*_HOME has been specified and
FALLBACK otherwise.
Instead of looking at the current HEAD, look at each branch
separately. This also means that if you customize the `print' method
in your init file you should also go over all the branches. You can
now also customize the `print' method for the `<branch>' type.
This changes the way formatting functions can be customized in the init
file to:
,----
| (define-method (print (repo <repository>))
| (format #t "~a: ~d up; ~d down; ~a. Updated ~a~%"
| (repo-name repo) (repo-pushable repo) (repo-pullable repo)
| (if (repo-clean? repo) "clean" "dirty") (repo-updated repo)))
`----
Note that it is possible that REPO doesn't exist, so you should always
check for that first.
Before using goops the relevant information was gathered when it was
needed, but now with goops everything is gathered at startup. So use
lazy evaluation to defer that gathering until it is needed.
This way people can override this function in their RC files, and
specify what information they would like to see where.
They would do this with, for example:
,----
| (set! format-repository
| (lambda (name pushable pullable clean? updated)
| (format #t "~a: ~d up; ~d down; ~a. Updated ~a\n"
| name pushable pullable (if clean? "clean" "dirty")
| updated)))
`----
To turn each line into the like of:
,----
| gitto: 1 up; 0 down; dirty. Updated 4 months ago
`----
