Re: Git transition checklist

[Eli Zaretskii <eliz@gnu.org>]

> From: esr@thyrsus.com (Eric S. Raymond)
> Date: Wed,  8 Jan 2014 08:52:00 -0500 (EST)
> 
> > 8. There's the emacs-bzr-version whose value gets copied into the bug
> >    reports.  This should be replaced by the suitable git equivalent,
> >    or else the bug reports (of which we have quite a few each day)
> >    will not identify the version correctly.
> 
> Proof of concept (tested):
> 
> (defun emacs-repository-get-version (&optional dir)
>   "Try to return as a string the version-control revision of the Emacs sources.
> Value is nil if the sources do not seem to be under version
> control, or if we could not determine the revision.  Note that
> this reports on the current state of the sources, which may not
> correspond to the running Emacs.
> 
> Optional argument DIR is a directory to use instead of `source-directory'."
>   ;; This is the only function that knows what VCS the Emacs sources are under.
>   (let ((here default-directory))
>     (cd (or dir (setq dir source-directory))) 
>     (message "Waiting for git...")
>     (with-temp-buffer
>       (if (zerop
>            (call-process "git" nil '(t nil) nil "describe" "--tags"))
>          (buffer-string)))
>     (cd here)))

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.

> This code is simpler than emacs-bzr-get-version because "git describe" is
> very fast - there's no need to avoid calling it for better performance.

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).

> 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.

> 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.

Thanks.