~ivilata/gwit-spec

ca4df9c031feedcca1d18d3ca79695d21156c9d8 — Ivan Vilata-i-Balaguer 4 months ago 04c4740
Avoid `git rev-parse` in examples where a `git show-ref` suffices.
1 files changed, 2 insertions(+), 2 deletions(-)

M README.md
M README.md => README.md +2 -2
@@ 197,7 197,7 @@ If someone wants to retrieve updates to a gwit site identified by `<SITE-ID>` fo
1. Get the name of the default branch in the clone as `<BRANCH>` (e.g. `git symbolic-ref --short HEAD`).
2. Get its current head commit hash as `<OLD-HEAD>` (e.g. `git show-ref --verify --hash refs/heads/<BRANCH>`).
3. Try to fetch new objects from `<REMOTE>` (e.g. `git fetch --atomic --no-write-fetch-head <REMOTE> '+refs/heads/*:refs/remotes/<REMOTE>/*'`; this preserves all fetch heads for each remote).
4. Get the new head commit hash as `<NEW-HEAD>` (e.g. `git rev-parse --verify <REMOTE>/<BRANCH>`).
4. Get the new head commit hash as `<NEW-HEAD>` (e.g. `git show-ref --verify --hash refs/remotes/<REMOTE>/<BRANCH>`).
5. Check that `<NEW-HEAD>` is not an ancestor of the current head commit (e.g. not `git merge-base --is-ancestor <NEW-HEAD> <OLD-HEAD>`). If it is, then `<REMOTE>` does not contain newer content.
6. Update the site key (e.g. to allow new signing subkeys) by importing the `_gwit/self.key` file into the client's keyring (e.g. `git cat-file blob <NEW-HEAD>:_gwit/self.key | gpg --homedir <CLIENT-GPG-DIR> --import-options merge-only --import`).
7. Check that `<NEW-HEAD>` has a valid signature by the key that matches `<SITE-ID>` (case-insensitively), or by a subkey of it (e.g. `git verify-commit --raw <NEW-HEAD> 2>&1 | sed -nE 's/^\[GNUPG:\] VALIDSIG .*\b(\S+)$/\1/p'` reports `<SITE-ID>`).


@@ 317,7 317,7 @@ Let `gwit://[<VERSION>@]<SITE><PATH>` be the URI which identifies a particular f

The client MUST then establish which Git commit `<COMMIT>` to use, according to the `<VERSION>` in the URI (which has already been percent-decoded if necessary), by following the first of the steps below whose condition applies:

1. If `<VERSION>` is missing or empty, get the current `HEAD` commit as `<COMMIT>` (e.g. `git rev-parse --verify HEAD`).
1. If `<VERSION>` is missing or empty, get the current `HEAD` commit as `<COMMIT>` (e.g. `git show-ref --verify --hash HEAD`).
2. Else, if `<VERSION>` matches the format of a SHA-1 hash (40 hexadecimal digits, lower or upper case), use it as `<COMMIT>`. This is the case for a permanent link.
3. Else, if `<VERSION>` consists only of hexadecimal digits (lower or upper case), check that there is neither tag nor branch with that name (e.g. `git show-ref --tags --heads <VERSION>` reports nothing), then check that it is the prefix of a single commit object, and use its complete name as `<COMMIT>` (e.g. `git rev-parse --verify <VERSION>^{commit}` only reports the `<COMMIT>`).