Open Stack

On 2015-08-25 10:54:38 +0100 (+0100), Dave Walker wrote:
> On 25 August 2015 at 10:28, Alexis Lee <lxsli at hpe.com> wrote:
[...]
> > Without offering an opinion either way, I'm just wondering how
> > tag-every-commit is superior to never tagging? The git SHAs already
> > uniquely identify every commit; if you want only those on master, simply
> > `git log master`.
[...]
> The issue with this is deterministic version counting between commits,
> allowing distributed additional commits but still keeping the version
> counting centralised.
[...]

I guess to take this one step further, it should be pointed out that
"deterministic version counting" is really another way of saying
"human-readable branch state serialization." The point is that Git
already has a branch state serialization, where every commit
includes a pointer reference to the identifiers of its parent
commit(s). So really, tagging every state change within the branch
is simply an assignment of a memorable name for that new state,
mimicking the ordering implicit in Git, and tying that name (via a
cryptographic attestation) to the corresponding commit.

The commit ID of any point in the history on a branch is immutable,
so aside from being able to discuss memorable names for these rather
than a (typically abbreviated) hex representation of a SHA-1 hash
and allow the participants to fairly intuitively know their sequence
without looking it up, I'm unconvinced there's much difference
between tagging every commit and tagging no commits.
-- 
Jeremy Stanley