[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Git transition checklist
From: |
Eric S. Raymond |
Subject: |
Re: Git transition checklist |
Date: |
Wed, 8 Jan 2014 15:11:04 -0500 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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>
Re: Git transition checklist, Andreas Schwab, 2014/01/08
Re: Git transition checklist,
Eric S. Raymond <=
- Re: Git transition checklist, Eli Zaretskii, 2014/01/08
- Re: Git transition checklist, Eric S. Raymond, 2014/01/08
- Re: Git transition checklist, Eli Zaretskii, 2014/01/08
- Re: Git transition checklist, Eric S. Raymond, 2014/01/08
- Re: Git transition checklist, Eli Zaretskii, 2014/01/09
Re: Git transition checklist, David Kastrup, 2014/01/08
Re: Git transition checklist, Eli Zaretskii, 2014/01/08
Re: Git transition checklist, Angelo Graziosi, 2014/01/14