* Re: Setting the value of `emacs-bzr-version' also from a git checkout
2013-10-01 16:45 Setting the value of `emacs-bzr-version' also from a git checkout (was: Emacs trunk binary on Dropbox) Dani Moncayo
@ 2013-10-01 17:04 ` Óscar Fuentes
2013-10-01 17:45 ` Andreas Schwab
1 sibling, 0 replies; 31+ messages in thread
From: Óscar Fuentes @ 2013-10-01 17:04 UTC (permalink / raw)
To: emacs-devel
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.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Setting the value of `emacs-bzr-version' also from a git checkout
2013-10-01 16:45 Setting the value of `emacs-bzr-version' also from a git checkout (was: Emacs trunk binary on Dropbox) Dani Moncayo
2013-10-01 17:04 ` Setting the value of `emacs-bzr-version' also from a git checkout Óscar Fuentes
@ 2013-10-01 17:45 ` Andreas Schwab
2013-10-01 18:37 ` Dani Moncayo
1 sibling, 1 reply; 31+ messages in thread
From: Andreas Schwab @ 2013-10-01 17:45 UTC (permalink / raw)
To: Dani Moncayo
Cc: Sebastien Vauban, Eli Zaretskii, Lennart Borgman,
Emacs-Devel devel
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."
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Setting the value of `emacs-bzr-version' also from a git checkout
2013-10-01 17:45 ` Andreas Schwab
@ 2013-10-01 18:37 ` Dani Moncayo
2013-10-01 18:46 ` Óscar Fuentes
0 siblings, 1 reply; 31+ messages in thread
From: Dani Moncayo @ 2013-10-01 18:37 UTC (permalink / raw)
To: Andreas Schwab
Cc: Sebastien Vauban, Eli Zaretskii, Lennart Borgman,
Emacs-Devel devel
>> 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
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Setting the value of `emacs-bzr-version' also from a git checkout
2013-10-01 18:37 ` Dani Moncayo
@ 2013-10-01 18:46 ` Óscar Fuentes
2013-10-01 21:15 ` Dani Moncayo
0 siblings, 1 reply; 31+ messages in thread
From: Óscar Fuentes @ 2013-10-01 18:46 UTC (permalink / raw)
To: emacs-devel
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.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Setting the value of `emacs-bzr-version' also from a git checkout
@ 2013-10-01 20:23 Dani Moncayo
0 siblings, 0 replies; 31+ messages in thread
From: Dani Moncayo @ 2013-10-01 20:23 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Sebastien Vauban, Emacs development discussions
>> 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
^ permalink raw reply related [flat|nested] 31+ messages in thread
* Re: Setting the value of `emacs-bzr-version' also from a git checkout
2013-10-01 18:46 ` Óscar Fuentes
@ 2013-10-01 21:15 ` Dani Moncayo
2013-10-02 0:22 ` Stefan Monnier
0 siblings, 1 reply; 31+ messages in thread
From: Dani Moncayo @ 2013-10-01 21:15 UTC (permalink / raw)
To: Óscar Fuentes; +Cc: Emacs development discussions
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
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Setting the value of `emacs-bzr-version' also from a git checkout
2013-10-01 21:15 ` Dani Moncayo
@ 2013-10-02 0:22 ` Stefan Monnier
2013-10-02 14:36 ` Josh
2013-10-12 10:22 ` Dani Moncayo
0 siblings, 2 replies; 31+ messages in thread
From: Stefan Monnier @ 2013-10-02 0:22 UTC (permalink / raw)
To: Dani Moncayo; +Cc: Óscar Fuentes, Emacs development discussions
> 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
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Setting the value of `emacs-bzr-version' also from a git checkout
2013-10-02 0:22 ` Stefan Monnier
@ 2013-10-02 14:36 ` Josh
2013-10-12 10:22 ` Dani Moncayo
1 sibling, 0 replies; 31+ messages in thread
From: Josh @ 2013-10-02 14:36 UTC (permalink / raw)
To: Stefan Monnier
Cc: Óscar Fuentes, Emacs development discussions, Dani Moncayo
[-- 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 --]
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Setting the value of `emacs-bzr-version' also from a git checkout
2013-10-02 0:22 ` Stefan Monnier
2013-10-02 14:36 ` Josh
@ 2013-10-12 10:22 ` Dani Moncayo
2013-10-12 10:33 ` Eli Zaretskii
2013-10-13 20:49 ` Dani Moncayo
1 sibling, 2 replies; 31+ messages in thread
From: Dani Moncayo @ 2013-10-12 10:22 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Óscar Fuentes, Emacs development discussions
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
^ permalink raw reply related [flat|nested] 31+ messages in thread
* Re: Setting the value of `emacs-bzr-version' also from a git checkout
2013-10-12 10:22 ` Dani Moncayo
@ 2013-10-12 10:33 ` Eli Zaretskii
2013-10-12 10:42 ` Dani Moncayo
2013-10-13 20:49 ` Dani Moncayo
1 sibling, 1 reply; 31+ messages in thread
From: Eli Zaretskii @ 2013-10-12 10:33 UTC (permalink / raw)
To: Dani Moncayo; +Cc: ofv, monnier, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Setting the value of `emacs-bzr-version' also from a git checkout
2013-10-12 10:33 ` Eli Zaretskii
@ 2013-10-12 10:42 ` Dani Moncayo
2013-10-12 10:51 ` Óscar Fuentes
2013-10-12 10:58 ` Eli Zaretskii
0 siblings, 2 replies; 31+ messages in thread
From: Dani Moncayo @ 2013-10-12 10:42 UTC (permalink / raw)
To: Eli Zaretskii
Cc: Óscar Fuentes, Stefan Monnier, Emacs development discussions
>> "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
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Setting the value of `emacs-bzr-version' also from a git checkout
2013-10-12 10:42 ` Dani Moncayo
@ 2013-10-12 10:51 ` Óscar Fuentes
2013-10-12 10:58 ` Dani Moncayo
2013-10-12 11:16 ` Dani Moncayo
2013-10-12 10:58 ` Eli Zaretskii
1 sibling, 2 replies; 31+ messages in thread
From: Óscar Fuentes @ 2013-10-12 10:51 UTC (permalink / raw)
To: Dani Moncayo; +Cc: Eli Zaretskii, Stefan Monnier, Emacs development discussions
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.)
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Setting the value of `emacs-bzr-version' also from a git checkout
2013-10-12 10:42 ` Dani Moncayo
2013-10-12 10:51 ` Óscar Fuentes
@ 2013-10-12 10:58 ` Eli Zaretskii
2013-10-12 11:06 ` Dani Moncayo
1 sibling, 1 reply; 31+ messages in thread
From: Eli Zaretskii @ 2013-10-12 10:58 UTC (permalink / raw)
To: Dani Moncayo; +Cc: ofv, monnier, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Setting the value of `emacs-bzr-version' also from a git checkout
2013-10-12 10:51 ` Óscar Fuentes
@ 2013-10-12 10:58 ` Dani Moncayo
2013-10-12 11:16 ` Dani Moncayo
1 sibling, 0 replies; 31+ messages in thread
From: Dani Moncayo @ 2013-10-12 10:58 UTC (permalink / raw)
To: Óscar Fuentes
Cc: Eli Zaretskii, Stefan Monnier, Emacs development discussions
>>> 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
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Setting the value of `emacs-bzr-version' also from a git checkout
2013-10-12 10:58 ` Eli Zaretskii
@ 2013-10-12 11:06 ` Dani Moncayo
2013-10-12 11:37 ` Eli Zaretskii
0 siblings, 1 reply; 31+ messages in thread
From: Dani Moncayo @ 2013-10-12 11:06 UTC (permalink / raw)
To: Eli Zaretskii
Cc: Óscar Fuentes, Stefan Monnier, Emacs development discussions
>> 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
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Setting the value of `emacs-bzr-version' also from a git checkout
2013-10-12 10:51 ` Óscar Fuentes
2013-10-12 10:58 ` Dani Moncayo
@ 2013-10-12 11:16 ` Dani Moncayo
2013-10-12 11:40 ` Eli Zaretskii
2013-10-12 19:04 ` Óscar Fuentes
1 sibling, 2 replies; 31+ messages in thread
From: Dani Moncayo @ 2013-10-12 11:16 UTC (permalink / raw)
To: Óscar Fuentes
Cc: Eli Zaretskii, Stefan Monnier, Emacs development discussions
>>> 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
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Setting the value of `emacs-bzr-version' also from a git checkout
2013-10-12 11:06 ` Dani Moncayo
@ 2013-10-12 11:37 ` Eli Zaretskii
0 siblings, 0 replies; 31+ messages in thread
From: Eli Zaretskii @ 2013-10-12 11:37 UTC (permalink / raw)
To: Dani Moncayo; +Cc: ofv, monnier, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Setting the value of `emacs-bzr-version' also from a git checkout
2013-10-12 11:16 ` Dani Moncayo
@ 2013-10-12 11:40 ` Eli Zaretskii
2013-10-12 12:04 ` Dani Moncayo
2013-10-12 19:04 ` Óscar Fuentes
1 sibling, 1 reply; 31+ messages in thread
From: Eli Zaretskii @ 2013-10-12 11:40 UTC (permalink / raw)
To: Dani Moncayo; +Cc: ofv, monnier, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Setting the value of `emacs-bzr-version' also from a git checkout
2013-10-12 11:40 ` Eli Zaretskii
@ 2013-10-12 12:04 ` Dani Moncayo
0 siblings, 0 replies; 31+ messages in thread
From: Dani Moncayo @ 2013-10-12 12:04 UTC (permalink / raw)
To: Eli Zaretskii
Cc: Óscar Fuentes, Stefan Monnier, Emacs development discussions
>> 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
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Setting the value of `emacs-bzr-version' also from a git checkout
2013-10-12 11:16 ` Dani Moncayo
2013-10-12 11:40 ` Eli Zaretskii
@ 2013-10-12 19:04 ` Óscar Fuentes
2013-10-12 20:36 ` Juanma Barranquero
` (2 more replies)
1 sibling, 3 replies; 31+ messages in thread
From: Óscar Fuentes @ 2013-10-12 19:04 UTC (permalink / raw)
To: emacs-devel
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)
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Setting the value of `emacs-bzr-version' also from a git checkout
2013-10-12 19:04 ` Óscar Fuentes
@ 2013-10-12 20:36 ` Juanma Barranquero
2013-10-12 20:51 ` Óscar Fuentes
2013-10-12 20:56 ` Stefan Monnier
2013-10-12 21:25 ` Dani Moncayo
2 siblings, 1 reply; 31+ messages in thread
From: Juanma Barranquero @ 2013-10-12 20:36 UTC (permalink / raw)
To: Óscar Fuentes; +Cc: Emacs developers
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
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Setting the value of `emacs-bzr-version' also from a git checkout
2013-10-12 20:36 ` Juanma Barranquero
@ 2013-10-12 20:51 ` Óscar Fuentes
2013-10-12 20:57 ` Juanma Barranquero
0 siblings, 1 reply; 31+ messages in thread
From: Óscar Fuentes @ 2013-10-12 20:51 UTC (permalink / raw)
To: emacs-devel
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.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Setting the value of `emacs-bzr-version' also from a git checkout
2013-10-12 19:04 ` Óscar Fuentes
2013-10-12 20:36 ` Juanma Barranquero
@ 2013-10-12 20:56 ` Stefan Monnier
2013-10-12 21:25 ` Dani Moncayo
2 siblings, 0 replies; 31+ messages in thread
From: Stefan Monnier @ 2013-10-12 20:56 UTC (permalink / raw)
To: Óscar Fuentes; +Cc: emacs-devel
[ 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
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Setting the value of `emacs-bzr-version' also from a git checkout
2013-10-12 20:51 ` Óscar Fuentes
@ 2013-10-12 20:57 ` Juanma Barranquero
2013-10-12 21:16 ` Óscar Fuentes
0 siblings, 1 reply; 31+ messages in thread
From: Juanma Barranquero @ 2013-10-12 20:57 UTC (permalink / raw)
To: Óscar Fuentes; +Cc: Emacs developers
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
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Setting the value of `emacs-bzr-version' also from a git checkout
2013-10-12 20:57 ` Juanma Barranquero
@ 2013-10-12 21:16 ` Óscar Fuentes
2013-10-12 21:33 ` Juanma Barranquero
0 siblings, 1 reply; 31+ messages in thread
From: Óscar Fuentes @ 2013-10-12 21:16 UTC (permalink / raw)
To: emacs-devel
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.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Setting the value of `emacs-bzr-version' also from a git checkout
2013-10-12 19:04 ` Óscar Fuentes
2013-10-12 20:36 ` Juanma Barranquero
2013-10-12 20:56 ` Stefan Monnier
@ 2013-10-12 21:25 ` Dani Moncayo
2013-10-12 21:38 ` Óscar Fuentes
2 siblings, 1 reply; 31+ messages in thread
From: Dani Moncayo @ 2013-10-12 21:25 UTC (permalink / raw)
To: Óscar Fuentes; +Cc: Emacs development discussions
> 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
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Setting the value of `emacs-bzr-version' also from a git checkout
2013-10-12 21:16 ` Óscar Fuentes
@ 2013-10-12 21:33 ` Juanma Barranquero
0 siblings, 0 replies; 31+ messages in thread
From: Juanma Barranquero @ 2013-10-12 21:33 UTC (permalink / raw)
To: Óscar Fuentes; +Cc: Emacs developers
> Please don't be foolish. No, that's not an insult either
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Setting the value of `emacs-bzr-version' also from a git checkout
2013-10-12 21:25 ` Dani Moncayo
@ 2013-10-12 21:38 ` Óscar Fuentes
0 siblings, 0 replies; 31+ messages in thread
From: Óscar Fuentes @ 2013-10-12 21:38 UTC (permalink / raw)
To: emacs-devel
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
:-)
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Setting the value of `emacs-bzr-version' also from a git checkout
2013-10-12 10:22 ` Dani Moncayo
2013-10-12 10:33 ` Eli Zaretskii
@ 2013-10-13 20:49 ` Dani Moncayo
2013-10-13 22:16 ` Glenn Morris
1 sibling, 1 reply; 31+ messages in thread
From: Dani Moncayo @ 2013-10-13 20:49 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Óscar Fuentes, Emacs development discussions
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
^ permalink raw reply related [flat|nested] 31+ messages in thread
* Re: Setting the value of `emacs-bzr-version' also from a git checkout
2013-10-13 20:49 ` Dani Moncayo
@ 2013-10-13 22:16 ` Glenn Morris
2013-10-14 6:38 ` Dani Moncayo
0 siblings, 1 reply; 31+ messages in thread
From: Glenn Morris @ 2013-10-13 22:16 UTC (permalink / raw)
To: Dani Moncayo
Cc: Óscar Fuentes, Stefan Monnier, Emacs development discussions
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.)
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Setting the value of `emacs-bzr-version' also from a git checkout
2013-10-13 22:16 ` Glenn Morris
@ 2013-10-14 6:38 ` Dani Moncayo
0 siblings, 0 replies; 31+ messages in thread
From: Dani Moncayo @ 2013-10-14 6:38 UTC (permalink / raw)
To: Glenn Morris; +Cc: Emacs development discussions
>> 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
^ permalink raw reply related [flat|nested] 31+ messages in thread
end of thread, other threads:[~2013-10-14 6:38 UTC | newest]
Thread overview: 31+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-10-01 20:23 Setting the value of `emacs-bzr-version' also from a git checkout Dani Moncayo
-- strict thread matches above, loose matches on Subject: below --
2013-10-01 16:45 Setting the value of `emacs-bzr-version' also from a git checkout (was: Emacs trunk binary on Dropbox) Dani Moncayo
2013-10-01 17:04 ` Setting the value of `emacs-bzr-version' also from a git checkout Óscar Fuentes
2013-10-01 17:45 ` Andreas Schwab
2013-10-01 18:37 ` Dani Moncayo
2013-10-01 18:46 ` Óscar Fuentes
2013-10-01 21:15 ` Dani Moncayo
2013-10-02 0:22 ` Stefan Monnier
2013-10-02 14:36 ` Josh
2013-10-12 10:22 ` Dani Moncayo
2013-10-12 10:33 ` Eli Zaretskii
2013-10-12 10:42 ` Dani Moncayo
2013-10-12 10:51 ` Óscar Fuentes
2013-10-12 10:58 ` Dani Moncayo
2013-10-12 11:16 ` Dani Moncayo
2013-10-12 11:40 ` Eli Zaretskii
2013-10-12 12:04 ` Dani Moncayo
2013-10-12 19:04 ` Óscar Fuentes
2013-10-12 20:36 ` Juanma Barranquero
2013-10-12 20:51 ` Óscar Fuentes
2013-10-12 20:57 ` Juanma Barranquero
2013-10-12 21:16 ` Óscar Fuentes
2013-10-12 21:33 ` Juanma Barranquero
2013-10-12 20:56 ` Stefan Monnier
2013-10-12 21:25 ` Dani Moncayo
2013-10-12 21:38 ` Óscar Fuentes
2013-10-12 10:58 ` Eli Zaretskii
2013-10-12 11:06 ` Dani Moncayo
2013-10-12 11:37 ` Eli Zaretskii
2013-10-13 20:49 ` Dani Moncayo
2013-10-13 22:16 ` Glenn Morris
2013-10-14 6:38 ` Dani Moncayo
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.