Re: Finer timestamps and serialization in git

From: Elijah Newren <newren@gmail.com>
Date: May 20, 2019, 21:38 UTC
Message-ID: <CABPp-BHK1N2zZoeBeSgnh12LPqLgZxfbL0DzALj28y97_Q-ahg@mail.gmail.com>
In-Reply-To: <20190520141417.GA83559@thyrsus.com>

Hi,

On Mon, May 20, 2019 at 11:09 AM Eric S. Raymond <esr@thyrsus.com> wrote:

Show 5 quoted lines

> > For cookie to be unique among all forks / clones of the same repository
> > you need either centralized naming server, or for the cookie to be based
> > on contents of the commit (i.e. be a hash function).
>
> I don't need uniquess across all forks, only uniqueness *within the repo*.

You've lost me. In other places you stated you didn't want to use the commit hash, and now you say this. If you only care about uniqueness within the current copy of the repo and don't care about uniqueness across forks (i.e. clones or copies that exist now or in the future -- including copies stored using SHA256), then what's wrong with using the commit hash?

> I want this for two reasons: (1) so that action stamps are unique, (2)
> so that there is a unique canonical ordering of commits in a fast export
> stream.

A stable ordering of commits in a fast-export stream might be a cool feature. But I don't know how to define one, other than perhaps sort first by commit-depth (maybe optionally adding a few additional intermediate sorting criteria), and then finally sort by commit hash as a tiebreaker. Without the fallback to commit hash, you fall back on normal traversal order which isn't stable (it depends on e.g. order of branches listed on the command line to fast-export, or if using --all, what new branch you just added that comes alphabetically before others).

I suspect that solution might run afoul of your dislike for commit hashes, though, so I'm not sure it'd work for you.

Show 17 quoted lines

> (Without that second property there are surgical cases I can't
> regression-test.)
>
> > >                                                          For my use case
> > > that cookie should *not* be a hash, because hashes always break N years
> > > down.  It should be an eternally stable product of the commit metadata.
> >
> > Well, the idea for SHA-1 <--> NewHash == SHA-256 transition is to avoid
> > having a flag day, and providing full interoperability between
> > repositories and Git installations using the old hash ad using new
> > hash^1.  This will be done internally by using SHA-1 <--> SHA-256
> > mapping.  So after the transition all you need is to publish this
> > mapping somewhere, be it with Internet Archive or Software Heritage.
> > Problem solved.
>
> I don't see it.  How does this prevent old clients from barfing on new
> repositories?

Depends on range of time for "old". The plan as I understood it (which is suspect): make git version which understand both SHA-1 and SHA-256 (which I think is already done, though I haven't followed closely), wait some time, allow people to opt in to converting, allow more time, consider ways of nudging people to switch.

You are right that clients older than any version that understands SHA-256 would barf on the new repositories.

> So let me back up a step.  I will cheerfully drop advocating bumping
> timestamps if anyone can tell me how a different way to define a per-commit
> reference cookie that (a) is unique within its repo, and (b) only requires
> metadata visible in the fast-export representation of the commit.

Does passing --show-original-ids option to fast-export and using the resulting original-oid field as the cookie count?