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
`----
When a repo is in the repositories list, but not where it should be,
don't care, if we know it, delete it.
Don't require the argument for delete to exist on the filesystem.
Because it looks cooler.
This way its easy to keep all the information about the function in
one place, and it makes it easier/more interesting to add new
functions later.
As of now, when using `-r' or `-R', relative directories can be used.
This *does not* include locations starting with `~', those still need
to be handled by your shell.
Because every repo is treated as a possible relative path, and thus
passed on to `realpath', the paths have become very uniform. This
means that it will now only register and unregister paths that don't
have a trailing `/'. This is not true during usage, so those paths
still work, but they can't be removed by gitto, and adding them again
will create a duplicate entry.
* gitto/Makefile (objects): Add `path.scm' and `path.go'.
(.PHONY): Add `all' as a phony target.
(all): New target, compiles all `.go' targets.
($(filter %.go,$(objects))): Use `env' to run guild so that include
paths are setup properly.
* gitto/main.scm (gitto): Use new `(gitto path)' module, it contains
the `realpath' function.
(register-repository):
(remove-repository): Always pass REPOSITORY through `realpath' and
use the result.
* gitto/path.scm: New file. Loads the `libguile-gitto-path' extension
and exports its `realpath' function.
* src/Makefile (CFLAGS):
(LDFLAGS): Use `pkg-config' to gather the necessary values for guile.
(libguile-gitto-path.so): New guile extension, wraps the `readline'
POSIX function.
* src/gitto-path.c: New file, wraps and exports the `realpath' POSIX
function from `stdlib.h'.
