Setting the value of `emacs-bzr-version' also from a git checkout (was: Emacs trunk binary on Dropbox)

Setting the value of `emacs-bzr-version' also from a git checkout (was: Emacs trunk binary on Dropbox)

[Dani Moncayo]

On Tue, Oct 1, 2013 at 6:36 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> Lennart Borgman <lennart.borgman@gmail.com> writes:
>
>> Must not that revision number be available somewhere in the mirror?
>
> $ git notes show d079fb16c40905c3ebb5a53483dc17eb85d1577b
> monnier@iro.umontreal.ca-20131001155253-f13ed73lrl2p8utj

That would be even better, yes: figure out the value of
"emacs-bzr-version" not only when building from a bzr branch, but also
when building from the savannah's git repo.

But FWIW, if I try Andreas' command on my git repo I get an error:

  $ git log -1 | head -n1
  commit 2c691e3566392fb2d234892cf379b58886e98361

  $ git notes show 2c691e3566392fb2d234892cf379b58886e98361
  error: No note found for object 2c691e3566392fb2d234892cf379b58886e98361.


-- 
Dani Moncayo

Re: Setting the value of `emacs-bzr-version' also from a git checkout

[Óscar Fuentes]

Dani Moncayo <dmoncayo@gmail.com> writes:

> But FWIW, if I try Andreas' command on my git repo I get an error:
>
>   $ git log -1 | head -n1
>   commit 2c691e3566392fb2d234892cf379b58886e98361
>
>   $ git notes show 2c691e3566392fb2d234892cf379b58886e98361
>   error: No note found for object 2c691e3566392fb2d234892cf379b58886e98361.

Same here. IIRC Andreas keeps its own mirror of the bzr repo. Possibly
his method incorporates bzr meta info while Savannah's doesn't.

But after cloning http://repo.or.cz/w/emacs.git (maintained by Andreas):

oscar@qcore:~/dev/emacs/foo/emacs$ git log -1 | head -n1
commit d079fb16c40905c3ebb5a53483dc17eb85d1577b
oscar@qcore:~/dev/emacs/foo/emacs$ git notes show d079fb16c40905c3ebb5a53483dc17eb85d1577b
error: No note found for object d079fb16c40905c3ebb5a53483dc17eb85d1577b.

Re: Setting the value of `emacs-bzr-version' also from a git checkout

[Andreas Schwab]

Dani Moncayo <dmoncayo@gmail.com> writes:

> But FWIW, if I try Andreas' command on my git repo I get an error:
>
>   $ git log -1 | head -n1
>   commit 2c691e3566392fb2d234892cf379b58886e98361
>
>   $ git notes show 2c691e3566392fb2d234892cf379b58886e98361
>   error: No note found for object 2c691e3566392fb2d234892cf379b58886e98361.

You need to configure your repo to fetch the notes.

$ git config --add remote.origin.fetch "+refs/notes/*:refs/notes/*"

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Setting the value of `emacs-bzr-version' also from a git checkout

[Dani Moncayo]

>> But FWIW, if I try Andreas' command on my git repo I get an error:
>>
>>   $ git log -1 | head -n1
>>   commit 2c691e3566392fb2d234892cf379b58886e98361
>>
>>   $ git notes show 2c691e3566392fb2d234892cf379b58886e98361
>>   error: No note found for object 2c691e3566392fb2d234892cf379b58886e98361.
>
> You need to configure your repo to fetch the notes.
>
> $ git config --add remote.origin.fetch "+refs/notes/*:refs/notes/*"

Yes, that worked:

  $ git notes show d079fb16c40905c3ebb5a53483dc17eb85d1577b
  monnier@iro.umontreal.ca-20131001155253-f13ed73lrl2p8utj

But the final goal would be to make `emacs-bzr-version' get the
correct value also when building emacs from the official git repo.
And since its value includes both the bzr revno and the bzr revision
ID (e.g. "114456 rgm@gnu.org-20130925101746-8kz06nvtpjms0hy3"), the
notes stored in the git repo are insufficient (they lack the bzr
revno).

-- 
Dani Moncayo

Re: Setting the value of `emacs-bzr-version' also from a git checkout

[Óscar Fuentes]

Dani Moncayo <dmoncayo@gmail.com> writes:

> But the final goal would be to make `emacs-bzr-version' get the
> correct value also when building emacs from the official git repo.
> And since its value includes both the bzr revno and the bzr revision
> ID (e.g. "114456 rgm@gnu.org-20130925101746-8kz06nvtpjms0hy3"), the
> notes stored in the git repo are insufficient (they lack the bzr
> revno).

Just teach the build scripts to not require the revision number.

From the revision id whoever reads the bug report can get the revision
number (for a given branch.) Actually, if you look only to the revision
number you can end wasting your time, because you don't know which
branch was used to build that Emacs.

Re: Setting the value of `emacs-bzr-version' also from a git checkout

[Dani Moncayo]

On Tue, Oct 1, 2013 at 8:46 PM, Óscar Fuentes <ofv@wanadoo.es> wrote:
> Dani Moncayo <dmoncayo@gmail.com> writes:
>
>> But the final goal would be to make `emacs-bzr-version' get the
>> correct value also when building emacs from the official git repo.
>> And since its value includes both the bzr revno and the bzr revision
>> ID (e.g. "114456 rgm@gnu.org-20130925101746-8kz06nvtpjms0hy3"), the
>> notes stored in the git repo are insufficient (they lack the bzr
>> revno).
>
> Just teach the build scripts to not require the revision number.

Not sure what you mean.  AFAIK, the build scripts don't require it.

> From the revision id whoever reads the bug report can get the revision
> number (for a given branch.) Actually, if you look only to the revision
> number you can end wasting your time, because you don't know which
> branch was used to build that Emacs.

Yes I know, the bzr revision number is always relative to some bzr
branch, while the bzr revid is universally unique.  But my point is
that `emacs-bzr-version' gives both of them (on an Emacs built from a
bzr branch), and everyone in these lists prefer the bzr revno, because
is shorter/simpler.

Therefore, what I'd like is that "emacs-bzr-version" gave the exact
same string from an Emacs built from either bzr-trunk or git-master.

-- 
Dani Moncayo

Re: Setting the value of `emacs-bzr-version' also from a git checkout

[Stefan Monnier]

> Therefore, what I'd like is that "emacs-bzr-version" gave the exact
> same string from an Emacs built from either bzr-trunk or git-master.

Patch welcome,


        Stefan

Re: Setting the value of `emacs-bzr-version' also from a git checkout

[Josh]

[-- Attachment #1: Type: text/plain, Size: 402 bytes --]

On Tue, Oct 1, 2013 at 5:22 PM, Stefan Monnier <monnier@iro.umontreal.ca>wrote:

> > Therefore, what I'd like is that "emacs-bzr-version" gave the exact
> > same string from an Emacs built from either bzr-trunk or git-master.
>
> Patch welcome,
>
>
>         Stefan
>

If someone supplies a patch it will resolve the bug I filed about this last
week:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15468

[-- Attachment #2: Type: text/html, Size: 873 bytes --]

Re: Setting the value of `emacs-bzr-version' also from a git checkout

[Dani Moncayo]

On Wed, Oct 2, 2013 at 2:22 AM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> Therefore, what I'd like is that "emacs-bzr-version" gave the exact
>> same string from an Emacs built from either bzr-trunk or git-master.
>
> Patch welcome,

The below patch works for me.  But in order to get the intended
behavior (see above paragraph), it is necessary that the savannah git
repository includes also the bzr revno (in addition to the bzr revid)
in each note.  E.g.:

"114635 eliz@gnu.org-20131012090021-bau450cmd6gk61ag"
 ^^^^^^^
This part is currently missing.  We need it.


diff --git a/lisp/version.el b/lisp/version.el
index 9667456..030386a 100644
--- a/lisp/version.el
+++ b/lisp/version.el
@@ -126,6 +126,21 @@ Returns nil if unable to find this information."
                        "dir"))
         (buffer-string))))

+(defun emacs-bzr-version-git (dir)
+  "Ask git for the bzr version information for directory DIR.
+The official git repository of GNU Emacs stores this information
+as notes in each revision"
+  (message "Waiting for git...")
+  (with-temp-buffer
+    (if (zerop
+         (call-process "git" nil '(t nil) nil
+       (concat "--git-dir=" dir ".git")
+       "log"
+                       "-1"
+                       "--pretty=format:%N"))
+ (replace-regexp-in-string "\n" "" (buffer-string)))))
+
+
 (defun emacs-bzr-get-version (&optional dir external)
   "Try to return as a string the bzr revision of the Emacs sources.
 The format is: [revno] revision_id, where revno may be absent.
@@ -138,8 +153,8 @@ Optional argument EXTERNAL non-nil means to maybe
ask `bzr' itself,
 if the sources appear to be under bzr.  If `force', always ask bzr.
 Otherwise only ask bzr if we cannot find any information ourselves."
   (or dir (setq dir source-directory))
-  (when (file-directory-p (expand-file-name ".bzr/branch" dir))
-    (if (eq external 'force)
+  (cond ((file-directory-p (expand-file-name ".bzr/branch" dir))
+ ((if (eq external 'force)
       (emacs-bzr-version-bzr dir)
     (let (file loc rev)
       (cond ((file-readable-p
@@ -172,6 +187,9 @@ Otherwise only ask bzr if we cannot find any
information ourselves."
        rev))
     (external
      (emacs-bzr-version-bzr dir)))))))
+ ((file-directory-p (expand-file-name ".git" dir))
+ (if external
+     (emacs-bzr-version-git dir)))))

 ;; We put version info into the executable in the form that `ident' uses.
 (purecopy (concat "\n$Id: " (subst-char-in-string ?\n ?\s (emacs-version))


-- 
Dani Moncayo

Re: Setting the value of `emacs-bzr-version' also from a git checkout

[Eli Zaretskii]

> Date: Sat, 12 Oct 2013 12:22:29 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: Óscar Fuentes <ofv@wanadoo.es>,
> 	Emacs development discussions <emacs-devel@gnu.org>
> 
> "114635 eliz@gnu.org-20131012090021-bau450cmd6gk61ag"
>  ^^^^^^^
> This part is currently missing.  We need it.

Not necessarily (although it would be nice, indeed).  The revno can be
easily found using the revision-id:

  $ bzr revision-info eliz@gnu.org-20131012090021-bau450cmd6gk61ag
  114635 eliz@gnu.org-20131012090021-bau450cmd6gk61ag

IOW, the revision-id is enough to unequivocally identify the revision
in any given branch.

Re: Setting the value of `emacs-bzr-version' also from a git checkout

[Dani Moncayo]

>> "114635 eliz@gnu.org-20131012090021-bau450cmd6gk61ag"
>>  ^^^^^^^
>> This part is currently missing.  We need it.
>
> Not necessarily (although it would be nice, indeed).  The revno can be
> easily found using the revision-id:
>
>   $ bzr revision-info eliz@gnu.org-20131012090021-bau450cmd6gk61ag
>   114635 eliz@gnu.org-20131012090021-bau450cmd6gk61ag
>
> IOW, the revision-id is enough to unequivocally identify the revision
> in any given branch.

Of course, but that would require the user to have bzr installed, just
to get the revnos from the revids.  That would be too bad, and can be
easily avoided just by including the revnos in the git notes.

-- 
Dani Moncayo

Re: Setting the value of `emacs-bzr-version' also from a git checkout

[Óscar Fuentes]

Dani Moncayo <dmoncayo@gmail.com> writes:

>> IOW, the revision-id is enough to unequivocally identify the revision
>> in any given branch.
>
> Of course, but that would require the user to have bzr installed, just
> to get the revnos from the revids.  That would be too bad, and can be
> easily avoided just by including the revnos in the git notes.

Why is the *user* interested on getting the revno? For bug reporting,
the revid is perfectly valid (and, as stated before, it is more precise
than the revno.)

Re: Setting the value of `emacs-bzr-version' also from a git checkout

[Dani Moncayo]

>>> IOW, the revision-id is enough to unequivocally identify the revision
>>> in any given branch.
>>
>> Of course, but that would require the user to have bzr installed, just
>> to get the revnos from the revids.  That would be too bad, and can be
>> easily avoided just by including the revnos in the git notes.
>
> Why is the *user* interested on getting the revno? For bug reporting,
> the revid is perfectly valid (and, as stated before, it is more precise
> than the revno.)

When I wrote "user" there, I meant "person who wants to build emacs
from a git checkout, and doesn't want to have bzr installed".

...because, as I said:

>> what I'd like is that "emacs-bzr-version" gave the exact
>> same string from an Emacs built from either bzr-trunk or git-master.

-- 
Dani Moncayo

Re: Setting the value of `emacs-bzr-version' also from a git checkout

[Dani Moncayo]

>>> IOW, the revision-id is enough to unequivocally identify the revision
>>> in any given branch.
>>
>> Of course, but that would require the user to have bzr installed, just
>> to get the revnos from the revids.  That would be too bad, and can be
>> easily avoided just by including the revnos in the git notes.
>
> Why is the *user* interested on getting the revno? For bug reporting,
> the revid is perfectly valid (and, as stated before, it is more precise
> than the revno.)

(I think I didn't answer to your question in my previous reply.  Sorry.)

Many people prefer to use revnos while reporting bugs or discussing
changes (this mailing list is the clearest example).

I was even asked to include that revnos in the binaries I publish, see:

  http://lists.gnu.org/archive/html/help-gnu-emacs/2013-10/msg00002.html

So, even though the bzr revision IDs are unambiguous, (most) humans
prefer to use the revision numbers.

-- 
Dani Moncayo

Re: Setting the value of `emacs-bzr-version' also from a git checkout

[Eli Zaretskii]

> Date: Sat, 12 Oct 2013 13:16:59 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca>,
> 	Emacs development discussions <emacs-devel@gnu.org>
> 
> I was even asked to include that revnos in the binaries I publish, see:
> 
>   http://lists.gnu.org/archive/html/help-gnu-emacs/2013-10/msg00002.html

There's no such request in that message.  There's a question there why
the value of a variable is nil where it wasn't previously, that's all.

Look, you are welcome to make it so the git repo has the relevant
information to recreate also the revision numbers.  But when you ask
_others_ to do that job for you, please make sure it's really needed,
and not just a nicety.

Re: Setting the value of `emacs-bzr-version' also from a git checkout

[Dani Moncayo]

>> I was even asked to include that revnos in the binaries I publish, see:
>>
>>   http://lists.gnu.org/archive/html/help-gnu-emacs/2013-10/msg00002.html
>
> There's no such request in that message.  There's a question there why
> the value of a variable is nil where it wasn't previously, that's all.

Sorry, I meant another message on the same thread.  This one:
  http://lists.gnu.org/archive/html/help-gnu-emacs/2013-10/msg00004.html

Here is what Sebastien told me:

  [...] I had taken the habit of displaying
  the revision number in the window title, so that every screenshot would
  explicitly display with which version the problem occurred.


> Look, you are welcome to make it so the git repo has the relevant
> information to recreate also the revision numbers.  But when you ask
> _others_ to do that job for you, please make sure it's really needed,
> and not just a nicety.

I'm just proposing something, and the remaining work is tiny.  I have
no idea who can or know how to do it.  Right now I don't even know
where is the relevant source code (the one for replicating bzr commits
into the git repo).  I would not mind to do that change myself, but
since it's a trivial change, I think anyone could do it (assuming that
you -the maintainers- agree with the proposal).

-- 
Dani Moncayo

Re: Setting the value of `emacs-bzr-version' also from a git checkout

[Óscar Fuentes]

Dani Moncayo <dmoncayo@gmail.com> writes:

>> Why is the *user* interested on getting the revno? For bug reporting,
>> the revid is perfectly valid (and, as stated before, it is more precise
>> than the revno.)
>
> (I think I didn't answer to your question in my previous reply.  Sorry.)
>
> Many people prefer to use revnos while reporting bugs or discussing
> changes (this mailing list is the clearest example).
>
> I was even asked to include that revnos in the binaries I publish, see:
>
>   http://lists.gnu.org/archive/html/help-gnu-emacs/2013-10/msg00002.html
>
> So, even though the bzr revision IDs are unambiguous, (most) humans
> prefer to use the revision numbers.

That's because they don't understand the implications. The usefulness of
including version info on bug reports (something that IIRC is done
automatically, so there is no need to show the info on screenshots, etc)
is to pinpoint the sources used for the build. It is self-defeating to
use ambiguous info just because it seems more human-friendly, when the
non-ambiguous info makes no difference on terms of report write effort
nor on report read effort (it is easy to write a command that reads the
revid at point and shows the corresponding commit message and/or diff.)

Speaking of user's behavior, if I still were using bzr for my personal
branch of Emacs any bug report would include a revno that is wrong from
the POV of the developers, but they would not notice. Ditto for my
personal git branch (if your modification is accepted.) And, of course,
it is true for anyone using some of the experimental branches that share
the version number with a "major" branch (i.e. 24.3.50.1)

Re: Setting the value of `emacs-bzr-version' also from a git checkout

[Juanma Barranquero]

On Sat, Oct 12, 2013 at 9:04 PM, Óscar Fuentes <ofv@wanadoo.es> wrote:

> That's because they don't understand the implications.

Yes. Of course.

   J

Re: Setting the value of `emacs-bzr-version' also from a git checkout

[Óscar Fuentes]

Juanma Barranquero <lekktu@gmail.com> writes:

> Yes. Of course.

Thanks for your reasoned and well-balanced agreement with my poorly
explained position. It is always a pleasure when someone chimes in for
adding real substance on a discussion.

Re: Setting the value of `emacs-bzr-version' also from a git checkout

[Juanma Barranquero]

On Sat, Oct 12, 2013 at 10:51 PM, Óscar Fuentes <ofv@wanadoo.es> wrote:

> Thanks for your reasoned and well-balanced agreement with my poorly
> explained position. It is always a pleasure when someone chimes in for
> adding real substance on a discussion.

I knew you'd like it. I don't expect any less of someone who starts a
paragraph by insulting people, and then spends the rest of the
paragraph repeating things they already know... and then considers
these repetitions "arguments".

    J

Re: Setting the value of `emacs-bzr-version' also from a git checkout

[Óscar Fuentes]

Juanma Barranquero <lekktu@gmail.com> writes:

> I knew you'd like it. I don't expect any less of someone who starts a
> paragraph by insulting people,

Please don't be foolish. No, that's not an insult either, just a
reminder that your susceptibility does not apply to everybody else.

I'll not follow on this thoughtful discussion, so feel free to say the
last word.

Re: Setting the value of `emacs-bzr-version' also from a git checkout

[Juanma Barranquero]

> Please don't be foolish. No, that's not an insult either

Re: Setting the value of `emacs-bzr-version' also from a git checkout

[Stefan Monnier]

[ This whole discussion is largely pointless, since it comes from
  a misunderstanding, but anyway, here we are.  ]

> That's because they don't understand the implications.  The usefulness of
> including version info on bug reports (something that IIRC is done
> automatically, so there is no need to show the info on screenshots, etc)
> is to pinpoint the sources used for the build. It is self-defeating to
> use ambiguous info just because it seems more human-friendly, when the
> non-ambiguous info makes no difference on terms of report write effort
> nor on report read effort (it is easy to write a command that reads the
> revid at point and shows the corresponding commit message and/or diff.)

I never use that revid info, whereas I do occasionally use the revno,
because I can immediately tell (without having to remember which bzr
command to run) if it's "recent enough".

Before that, I used the timestamp which (in my experience) works just as
well anyway, so all this "include revision info" business is of no real
importance for me.


        Stefan

Re: Setting the value of `emacs-bzr-version' also from a git checkout

[Dani Moncayo]

> That's because they don't understand the implications. The usefulness of
> including version info on bug reports (something that IIRC is done
> automatically, so there is no need to show the info on screenshots, etc)
> is to pinpoint the sources used for the build.

Yes, but note that the bzr revision numbers have an advantage over the
revision IDs: they are numeric, so you can easily tell whether a given
revno is newer or older that another one.

So, for example if you know that one bug was fixed in revno 100200,
and you see one user reporting a similar bug with revno 100150, you
_immediately_ know that this user is running an older version which
does not include the bug fix.

But I also understand what you say: The revnos are ambiguous when you
don't specify the branch they come from.

In any case, what I'm trying to do here is simply making
"emacs-bzr-version" give the same info (i.e. both the revno and the
revid) from a binary made from either bzr-trunk or its official git
counterpart (savannah's git mirror).

-- 
Dani Moncayo

Re: Setting the value of `emacs-bzr-version' also from a git checkout

[Óscar Fuentes]

Dani Moncayo <dmoncayo@gmail.com> writes:

> Yes, but note that the bzr revision numbers have an advantage over the
> revision IDs: they are numeric, so you can easily tell whether a given
> revno is newer or older that another one.
>
> So, for example if you know that one bug was fixed in revno 100200,
> and you see one user reporting a similar bug with revno 100150, you
> _immediately_ know that this user is running an older version which
> does not include the bug fix.

Yes, and IIRC that's why there is some prominent people on the git
community that miss sequential revision numbers.

> But I also understand what you say: The revnos are ambiguous when you
> don't specify the branch they come from.

Exactly. Revision numbers are okay when you know the branch, but a
potential source of confusion on any other case.

> In any case, what I'm trying to do here is simply making
> "emacs-bzr-version" give the same info (i.e. both the revno and the
> revid) from a binary made from either bzr-trunk or its official git
> counterpart (savannah's git mirror).

And the message that I'm trying to send is that you already did the
really useful part. I also build Emacs from git and I think it is a good
thing to put the bzr revid on them. The difficulties you are facing now
is with a bit of information that is not really required, once you have
the revid, so I'll say don't bother with it and thank you for your work
:-)

Re: Setting the value of `emacs-bzr-version' also from a git checkout

[Eli Zaretskii]

> Date: Sat, 12 Oct 2013 12:42:51 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, Óscar Fuentes <ofv@wanadoo.es>, 
> 	Emacs development discussions <emacs-devel@gnu.org>
> 
> >> "114635 eliz@gnu.org-20131012090021-bau450cmd6gk61ag"
> >>  ^^^^^^^
> >> This part is currently missing.  We need it.
> >
> > Not necessarily (although it would be nice, indeed).  The revno can be
> > easily found using the revision-id:
> >
> >   $ bzr revision-info eliz@gnu.org-20131012090021-bau450cmd6gk61ag
> >   114635 eliz@gnu.org-20131012090021-bau450cmd6gk61ag
> >
> > IOW, the revision-id is enough to unequivocally identify the revision
> > in any given branch.
> 
> Of course, but that would require the user to have bzr installed, just
> to get the revnos from the revids.

Emacs developers and maintainers already have bzr installed.

Re: Setting the value of `emacs-bzr-version' also from a git checkout

[Dani Moncayo]

>> Of course, but that would require the user to have bzr installed, just
>> to get the revnos from the revids.
>
> Emacs developers and maintainers already have bzr installed.

But there are probably many people (like myself) who would like use
only git for all version control tasks.  And that's already possible.
What I want to do now is something very simple: getting the bzr revnos
out of the git notes, in order to produce binaries which included both
the revno and the revid.

-- 
Dani Moncayo

Re: Setting the value of `emacs-bzr-version' also from a git checkout

[Eli Zaretskii]

> Date: Sat, 12 Oct 2013 13:06:40 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, Óscar Fuentes <ofv@wanadoo.es>, 
> 	Emacs development discussions <emacs-devel@gnu.org>
> 
> >> Of course, but that would require the user to have bzr installed, just
> >> to get the revnos from the revids.
> >
> > Emacs developers and maintainers already have bzr installed.
> 
> But there are probably many people (like myself) who would like use
> only git for all version control tasks.  And that's already possible.
> What I want to do now is something very simple: getting the bzr revnos
> out of the git notes, in order to produce binaries which included both
> the revno and the revid.

The bzr revision information is for the maintainers to be able to
correlate reported problems with Emacs development.  For that purpose,
having the revision-id is enough.

As I said, if the revision numbers are also available, that is
better.  But it's not a requirement, and I have no idea why would a
user need to know the revision number.

Re: Setting the value of `emacs-bzr-version' also from a git checkout

[Dani Moncayo]

On Sat, Oct 12, 2013 at 12:22 PM, Dani Moncayo <dmoncayo@gmail.com> wrote:
> On Wed, Oct 2, 2013 at 2:22 AM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>>> Therefore, what I'd like is that "emacs-bzr-version" gave the exact
>>> same string from an Emacs built from either bzr-trunk or git-master.
>>
>> Patch welcome,
>
> The below patch works for me.

Actually that patch was lacking a change in loadup.el:  The call to
`emacs-bzr-get-version' now has to pass `t' in the EXTERNAL argument,
to open the possibility of asking the external version control program
(bzr or git) if the "internal" method fails.  (I've not implemented an
"internal" method for the git case - only the "external" one.).

So here is the new patch (tested in a real bootstrap from a git repo),
which also updates the docstring of `emacs-bzr-get-version'
accordingly:

diff --git a/lisp/loadup.el b/lisp/loadup.el
index 27148ce..f92d6a5 100644
--- a/lisp/loadup.el
+++ b/lisp/loadup.el
@@ -299,7 +299,7 @@
  (string-to-number
  (substring name (length base) exelen))))
      files)))
-      (setq emacs-bzr-version (condition-case nil (emacs-bzr-get-version)
+      (setq emacs-bzr-version (condition-case nil (emacs-bzr-get-version nil t)
                               (error nil)))
       ;; `emacs-version' is a constant, so we shouldn't change it with `setq'.
       (defconst emacs-version
diff --git a/lisp/version.el b/lisp/version.el
index 9667456..dfeb5f7 100644
--- a/lisp/version.el
+++ b/lisp/version.el
@@ -126,20 +126,41 @@ Returns nil if unable to find this information."
                        "dir"))
         (buffer-string))))

+(defun emacs-bzr-version-git (dir)
+  "Ask git for the bzr version information for directory DIR.
+The official git repository of GNU Emacs stores this information
+as notes in each revision"
+  (message "Waiting for git...")
+  (with-temp-buffer
+    (if (zerop
+         (call-process "git" nil '(t nil) nil
+       (concat "--git-dir=" dir ".git")
+       "log"
+                       "-1"
+                       "--pretty=format:%N"))
+ (replace-regexp-in-string "\n" "" (buffer-string)))))
+
+
 (defun emacs-bzr-get-version (&optional dir external)
   "Try to return as a string the bzr revision of the Emacs sources.
 The format is: [revno] revision_id, where revno may be absent.
-Value is nil if the sources do not seem to be under bzr, 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'.
-Optional argument EXTERNAL non-nil means to maybe ask `bzr' itself,
-if the sources appear to be under bzr.  If `force', always ask bzr.
-Otherwise only ask bzr if we cannot find any information ourselves."
+Value is nil 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 directory should correspond to either a
+bzr branch or a git mirror of a bzr branch.  In the second case,
+the bzr revision string should be stored as notes in each
+revision.
+
+Optional argument EXTERNAL non-nil means to maybe ask the
+external version control program (`bzr' or `git').  If `force',
+always ask the external program.  Otherwise only ask the external
+program if we cannot find any information ourselves."
   (or dir (setq dir source-directory))
-  (when (file-directory-p (expand-file-name ".bzr/branch" dir))
-    (if (eq external 'force)
+  (cond ((file-directory-p (expand-file-name ".bzr/branch" dir))
+ ((if (eq external 'force)
       (emacs-bzr-version-bzr dir)
     (let (file loc rev)
       (cond ((file-readable-p
@@ -172,6 +193,9 @@ Otherwise only ask bzr if we cannot find any
information ourselves."
        rev))
     (external
      (emacs-bzr-version-bzr dir)))))))
+ ((file-directory-p (expand-file-name ".git" dir))
+ (if external
+     (emacs-bzr-version-git dir)))))

 ;; We put version info into the executable in the form that `ident' uses.
 (purecopy (concat "\n$Id: " (subst-char-in-string ?\n ?\s (emacs-version))



--
Dani Moncayo

Re: Setting the value of `emacs-bzr-version' also from a git checkout

[Glenn Morris]

Dani Moncayo wrote:

> Actually that patch was lacking a change in loadup.el:  The call to
> `emacs-bzr-get-version' now has to pass `t' in the EXTERNAL argument,
> to open the possibility of asking the external version control program
> (bzr or git) if the "internal" method fails.

The existing bzr implementation intentionally does not call any external
executable during building Emacs. (I have no opinion on/interest in what
any git version should do.)

Re: Setting the value of `emacs-bzr-version' also from a git checkout

[Dani Moncayo]

>> Actually that patch was lacking a change in loadup.el:  The call to
>> `emacs-bzr-get-version' now has to pass `t' in the EXTERNAL argument,
>> to open the possibility of asking the external version control program
>> (bzr or git) if the "internal" method fails.
>
> The existing bzr implementation intentionally does not call any external
> executable during building Emacs. (I have no opinion on/interest in what
> any git version should do.)

Ok, but note that in practice, no external executable would be called
in the bzr case, because EXTERNAL is `t' (not `force'), and that means
that the "internal" method will be tried first;  only if that method
fails (should never fail), the bzr executable would be called.

IOW, the bzr case would work exactly as it does now.

But if that argument doesn't convince you, there are alternative ways
of doing this.  For example this one (not  tested yet):

diff --git a/lisp/loadup.el b/lisp/loadup.el
index c32bd00..093f34c 100644
--- a/lisp/loadup.el
+++ b/lisp/loadup.el
@@ -299,7 +299,9 @@
  (string-to-number
  (substring name (length base) exelen))))
      files)))
-      (setq emacs-bzr-version (condition-case nil (emacs-bzr-get-version)
+      (setq emacs-bzr-version (condition-case nil
+  (or (emacs-bzr-get-version)
+      (emacs-bzr-get-version-git))
  (error nil)))
       ;; `emacs-version' is a constant, so we shouldn't change it with `setq'.
       (defconst emacs-version
diff --git a/lisp/version.el b/lisp/version.el
index 9667456..6c2c9c4 100644
--- a/lisp/version.el
+++ b/lisp/version.el
@@ -173,6 +173,27 @@ Otherwise only ask bzr if we cannot find any
information ourselves."
       (external
        (emacs-bzr-version-bzr dir)))))))

+(defun emacs-bzr-get-version-git (&optional dir)
+  "Try to return as a string the bzr revision of the Emacs sources.
+The format is: [revno] revision_id, where revno may be absent.
+Value is nil 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 directory should correspond to a git
+mirror of a bzr branch, where the bzr revision data should be
+stored as notes in each git revision."
+  (or dir (setq dir source-directory))
+  (when (file-directory-p (expand-file-name ".git" dir))
+    (message "Waiting for git...")
+    (with-temp-buffer
+      (if (zerop
+   (call-process "git" nil '(t nil) nil "log"
+ "-1"
+ "--pretty=format:%N"))
+  (replace-regexp-in-string "\n" "" (buffer-string))))))
+
 ;; We put version info into the executable in the form that `ident' uses.
 (purecopy (concat "\n$Id: " (subst-char-in-string ?\n ?\s (emacs-version))
   " $\n"))


-- 
Dani Moncayo

Re: Setting the value of `emacs-bzr-version' also from a git checkout

[Dani Moncayo]

>> It would be nice if I could specify the bzr revno manually, for
>> example as a parameter to "configure" or "make", because having to
>> keep using bzr just for this little thing would also be too bad.
>
> You need to set the value of emacs-bzr-version (a string) during
> dumping.

I see.  As a temporary solution, I guess I could set that value
hard-coded, like this:

--------------------------------
diff --git a/lisp/loadup.el b/lisp/loadup.el
index c32bd00..5c1daab 100644
--- a/lisp/loadup.el
+++ b/lisp/loadup.el
@@ -299,8 +299,7 @@
                                (string-to-number
                                 (substring name (length base) exelen))))
                             files)))
-      (setq emacs-bzr-version (condition-case nil (emacs-bzr-get-version)
-                              (error nil)))
+      (setq emacs-bzr-version "rgm@gnu.org-20130925101746-8kz06nvtpjms0hy3")
       ;; `emacs-version' is a constant, so we shouldn't change it with `setq'.
       (defconst emacs-version
        (format "%s.%d"
--------------------------------

But I hope that `emacs-bzr-get-version' could be adapted to try a
second method when the primary one (the current one) fails.

That second method would assume a git repo instead of a bzr one
(Andreas showed how to get the bzr revid from a git repo).

-- 
Dani Moncayo