Re: Git transition checklist

[Eric S. Raymond]

Eli Zaretskii <address@hidden>:
> If I run the above git command in the Emacs git repo, I get this:
> 
>   $ git describe --tags
>   mh-e-8.5-4522-gaa5ae3b
> 
> I doubt that we want this.  We want the git sha1 value of the last
> commit instead, I think.

Why?  If the repo has proper release tags (which it will - I'm going to
do that), knowing the offset from the last release conveys more information
than a lump of SHA1.

> At least here (on MS-Windows), "git describe" is not very fast: with a
> warm cache it takes 0.265 sec, with a cold cache it takes several
> seconds.
> 
> But a command that prints the sha1 value should be much faster (about
> 30 to 45 msec here).

Performance may be an overriding factor her, but I'd prefer we think
about the use cases for the information and decide what we'd *like*
it to do first.

> > The change to integrate this and fix its callers is easy, five minutes'
> > work which I will cheerfully do immediately after the repo switchover.
> > No need to do it before as it really only becomes crucial to have this
> > working for the next point release.
> 
> No, I think it needs to be done before the first user checks out the
> git repo after the switch, because that signature is important in bug
> reports.  We don't want to have builds of Emacs that don't identify
> the git commit they are based on, because that makes it harder to
> decide whether a bug was already fixed.
> 
> So either the above function should be added to Emacs before the
> switch, wrapped with some code that would activate it when git starts
> to be used, or the repo should be locked for pulls for a few moments
> after the switch, until the function is committed.

Very well. One of these things can be made to happen; I'll ensure
the transition plan spells this out.

> > Nobody else explicitly suggested any additional preconditions.
> 
> I think we have identified another one today: repack the savannah
> repository, to avoid both slow initial clone and, what's more, local
> repacking that is problematic on slow or low-memory machines.

Right, and I saw the mail about where to post that request, too.  I
expect one of the people having performance problems will do that.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>