* The fixes-bug field
@ 2014-01-16 14:13 Eric S. Raymond
2014-01-16 16:13 ` Stefan Monnier
0 siblings, 1 reply; 39+ messages in thread
From: Eric S. Raymond @ 2014-01-16 14:13 UTC (permalink / raw
To: emacs-devel
Eli Zaretskii asked:
> Which reminds me: what about the "fixes bug" field of the commit
> metadata? are they copied into the git repo? If so, how can I display
> them in git?
The "fixes bug" field in the Bazaar logs is not copied in to the git logs.
This is because it's not actually part of the Bazaar log text. It is, one
member (often the only member) of a per-revision property/value list.
The Bazaar fast-export plugin can write these property lists in a
extension of fast-import format, but normally does not because
Git cannot interpret that extension. Thus, these properties are
normally lost in translation to git.
reposurgeon, on the other hand, *can* read and process these
properties (they're the one Bazaar feature I really like, and I wish
git supported them). In theory I could salvage these properties and
append a report of them them to the end of the log messages on their
corresponding git commits.
There's a complication, though. Quoting from the reposurgeon
manual:
<para>Limitation: bzr suffers from deep confusion over whether its
unit of work is a repository or a floating branch that might have been
cloned from a repo or created from scratch, and might or might not be
destined to be merged to a repo one day. Its exporter only works on
branches, but its importer creates repos. Thus, a rebuild operation
will produce a subdirectory structure that differs from what you
expect. Look for your content under the subdirectory 'trunk'.</para>
This reflects the state of play when I wrote the Bazaar support fore
reposurgeon in early 2011. I know how to get a fast-import-compatible
dump of a branch with the Bazaar properties in place, but I don't know
how to get a fast-import dump of an *entire Bazaar repo*, with or
without the properties.
Unless the Bazaar exporter has been up-gunned while I wasn't looking,
this might literally require iterating across a branch list and
stitching dumps together by hand. While I could do this with
reposurgeon, the operation would be an error-prone pain in the
ass.
Because of this, I had been planning to do the full-bore git
conversion based on the existing git mirror, rather than the
Bazaar repo. To save these properties I'd have to reverse that
decision. The additional complications could easily cost
me another week of work wrestling the Bazaar exporter into submission.
TL;DR: Possible, but a serious PITA. If this is just an It Would Be Nice
rather than being key to an established workflow I'd rather not go there.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
The IRS has become morally corrupted by the enormous power which we in
Congress have unwisely entrusted to it. Too often it acts like a
Gestapo preying upon defenseless citizens.
-- Senator Edward V. Long
^ permalink raw reply [flat|nested] 39+ messages in thread
* The fixes-bug field
@ 2014-01-16 14:15 Eric S. Raymond
2014-01-16 17:11 ` Eli Zaretskii
0 siblings, 1 reply; 39+ messages in thread
From: Eric S. Raymond @ 2014-01-16 14:15 UTC (permalink / raw
To: emacs-devel
I now have what appears to be a complete list of tag dispositions.
I still don't have a maintainer decision on whether we're going to
keep using pretest tags; until I hear otherwise they will be
retained. Release tags will be replaced by cryptosigned tag
objects. Most other tags have been confirmed irrelevant and
will be discarded.
Here's an updated list of fossil references in the Emacs tree and
commit comments. Some are to Bazaar revisions, some to CVS. My next
major task will be to figure out how these map onto action stamps
so they can be converted into VCS-independent form.
ChangeLog:
revno 108687
admin/ChangeLog:
revno:105007
etc/ChangeLog:
r112148
revno:108936
revision 106831
CVS-1.61
1.61 in CVS
lib-src/ChangeLog:
revno:106608
revno 100789
lisp/ChangeLog:
rev. 110325
r115470
of 2012-12-20 (r111276)
2013-12-11 (r115470)
revno:114543
revno:113793
revno:113117
r114834
revno:113431
revno:113147
masdos/ChangeLog
revno 101897
revno 101876
revno 100306
nt/ChangeLog:
revno 108687
src/ChangeLog:
revision 114614 (commit of 2013-10-10)
revno:113431
doc/lispref/ChangeLog:
revno 101949
lisp/ChangeLog.15:
revno:103013
rev 102609
revno 101688
revno 101459
revnos 101381
101422
rev 100010
lisp/ChangeLog.16:
revno:109911
109621
revno:88805
revno:88864
revno:89810
revision 106664
revno:105285
revno:104787 (2011-06-30)
revno:104988 (2011-07-06)
revno:101730 (2010-10-02)
revno:103877 (2011-04-09)
revno:99634.2.463 (2010-10-09)
revno:101913
src/ChangeLog.11:
revno 95090 dated 2009-03-06
revno 101757
revno 82799 (2007-11-30)
2010-07-29 (revno 100939)
revno 100928
revnos 100982..100984
revno 99854.1.6
revno 99950
revno:100708
revno:110851
cvs-1.12.1
Revision 1.694
src/ChangeLog.12:
revno 108687
revno:108521
revno:108341
2011-08-30 (revision 105619)
2011-08-30 (revision 105619)
revision 84777 on 2008-02-22
revno:102982 (2011-01-26)
revision 104625
revision 104134
revno:20537 (1998-01-01)
revno:87605 (2008-05-14)
revno:50135 (2003-03-16)
revno:87605 (2008-05-14)
revno:34925 (2000-12-29)
revno:20537 (1998-01-01)
revno:25013 (1999-07-21)
revno:43563.1.17 (2002-03-01)
revno:84043 (2008-02-1)
revno:25356 (1999-08-21)
revno:20870 (1998-02-08)
revno:36704 (2001-03-09)
revno:32591 (2000-10-17)
revno:25013 (1999-07-21)
revno:43563.1.32 (2002-03-01)
revno:14998 (1996-04-12)
revno:86854 (2008-04-19)
revno:20569 (1998-01-02)
revno 103623
revision 1.32
revision 1.30
lisp/changeLog.13:
version 1.100
1.39
revision 1.104, made on 2000-05-21
2007-07-18 (revision 1.51)
revision 1.90 (commitid mWoPbju3pgNotDps)
lisp/ChangeLog.14:
revision 1.117
1.85
lisp/ChangeLog.15:
1.878
lisp/ChangeLog.9:
1.113
1.244
1.34
src/ChangeLog.10:
1.233
rev 1.82
src/Changelog.4:
1.70 (Jan 5 changes)
Change comments:
bzrs 111300
111840
revision 111647
revno:11026
revno:88864
revno:88805
revno:89810
revision 10835
revision 106726
revision 87208
revision 84777 on 2008-02-22
revno:99634.2.463 (2010-10-09)
revno:101913 (2010-10-12).
revno:20537 (1998-01-01)
revno:87605 (2008-05-14)
revno:87605 (2008-05-14)
revno:34925 (2000-12-29)
revno:20537 (1998-01-01)
revno:25013 (1999-07-21)
revno:43563.1.16 (2002-03-01)
revno:84043 (2008-02-1)
revno:20870 (1998-02-08)
revno:36704 (2001-03-09)
revno:32591 (2000-10-17)
revno:25356 (1999-08-21)
revno:14998 (1996-04-12)
revno:86854 (2008-04-19)
revno:20569 (1998-01-02)
CVS rev 1.49, 2001-09-12
CVS rev 1.47, 2003/01/27
CVS r1.35
revno 95090 dated 2009-03-06
2005-02-15 (revno 60055)
r111320
revno 99854.1.6
\ revno 99950
revision 99649
rev 99649
rev 99553
revno 99212
revision 94343
r1.135
rev 1.114
1.878
revision 1.117
rev 1.14395
revision 1.56
3.85
1.17
revision 1.69
revision 1.1
rev 1.5
revisions 1.40
1.41
1.39
revision 1.104
revision 1.51
revision 1.90
revision 1.1509
revision 7.8
CVS v1.12.8 and 1.12.9
cvs-1.12.1
1.103
HEAD (1.72)
v1.275
1.58
v1.5046
v1.5039
rev 1.82
rev. 1.761
revision 1.3831
1.3832
revision 1.12
revision 1.13
revision 1.14
revision 1.15
The following revision references may not be identifiable by groveling
through the Bazaar trunk log, or may not need to be converted at all.
The author of each reference it identified. If it's you, please
tell me the committer email address and exact commit time of the
commit if you can.
Stefan Monnier:
"revision 46054 of the original lexbind branch"
Alan McKenzie:
"change 1.85"
Eli Zaretskii:
"revisions 103939.1.41..103939.1.44 (inclusive)"
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
The IRS has become morally corrupted by the enormous power which we in
Congress have unwisely entrusted to it. Too often it acts like a
Gestapo preying upon defenseless citizens.
-- Senator Edward V. Long
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: The fixes-bug field
2014-01-16 14:13 Eric S. Raymond
@ 2014-01-16 16:13 ` Stefan Monnier
2014-01-16 16:30 ` Eric S. Raymond
0 siblings, 1 reply; 39+ messages in thread
From: Stefan Monnier @ 2014-01-16 16:13 UTC (permalink / raw
To: Eric S. Raymond; +Cc: emacs-devel
> TL;DR: Possible, but a serious PITA. If this is just an It Would Be Nice
> rather than being key to an established workflow I'd rather not go there.
The "fixes" info is important. Not just "would be nice".
Maybe there are other ways to preserve it (e.g. "bzr log", collect the
"Fixes" notes and then pass them to "git notes" somehow).
Which format is used to keep the "fixes" info in the Git repository is
not terribly important, but the info should appear in the "git
log" output.
Stefan
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: The fixes-bug field
2014-01-16 16:13 ` Stefan Monnier
@ 2014-01-16 16:30 ` Eric S. Raymond
2014-01-16 16:55 ` Eli Zaretskii
` (2 more replies)
0 siblings, 3 replies; 39+ messages in thread
From: Eric S. Raymond @ 2014-01-16 16:30 UTC (permalink / raw
To: Stefan Monnier; +Cc: emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca>:
> > TL;DR: Possible, but a serious PITA. If this is just an It Would Be Nice
> > rather than being key to an established workflow I'd rather not go there.
>
> The "fixes" info is important. Not just "would be nice".
> Maybe there are other ways to preserve it (e.g. "bzr log", collect the
> "Fixes" notes and then pass them to "git notes" somehow).
>
> Which format is used to keep the "fixes" info in the Git repository is
> not terribly important, but the info should appear in the "git
> log" output.
OK, I'll come up with something.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: The fixes-bug field
2014-01-16 16:30 ` Eric S. Raymond
@ 2014-01-16 16:55 ` Eli Zaretskii
2014-01-16 17:54 ` Glenn Morris
2014-01-16 18:08 ` Eric S. Raymond
2014-01-16 17:00 ` Glenn Morris
2014-01-16 17:22 ` Achim Gratz
2 siblings, 2 replies; 39+ messages in thread
From: Eli Zaretskii @ 2014-01-16 16:55 UTC (permalink / raw
To: esr; +Cc: monnier, emacs-devel
> Date: Thu, 16 Jan 2014 11:30:11 -0500
> From: "Eric S. Raymond" <esr@thyrsus.com>
> Cc: emacs-devel@gnu.org
>
> Stefan Monnier <monnier@iro.umontreal.ca>:
> > > TL;DR: Possible, but a serious PITA. If this is just an It Would Be Nice
> > > rather than being key to an established workflow I'd rather not go there.
> >
> > The "fixes" info is important. Not just "would be nice".
> > Maybe there are other ways to preserve it (e.g. "bzr log", collect the
> > "Fixes" notes and then pass them to "git notes" somehow).
> >
> > Which format is used to keep the "fixes" info in the Git repository is
> > not terribly important, but the info should appear in the "git
> > log" output.
>
> OK, I'll come up with something.
Thanks.
I think we should decide on how to store this info and how to report
the fixed bugs once we switch to git, before we decide on how to
convert this data from bzr, and whether or not this justifies a new
conversion from scratch rather than reuse of the existing mirror.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: The fixes-bug field
2014-01-16 16:30 ` Eric S. Raymond
2014-01-16 16:55 ` Eli Zaretskii
@ 2014-01-16 17:00 ` Glenn Morris
2014-01-16 17:22 ` Achim Gratz
2 siblings, 0 replies; 39+ messages in thread
From: Glenn Morris @ 2014-01-16 17:00 UTC (permalink / raw
To: esr; +Cc: Stefan Monnier, emacs-devel
Is this relevant?
http://www.fusonic.net/en/blog/2013/03/26/migrating-from-bazaar-to-git/
I wrote a fast-export stream-rewriter which is capable of rewriting
the stream in a format that Git understands but with all our bug id
infos included.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: The fixes-bug field
2014-01-16 14:15 The fixes-bug field Eric S. Raymond
@ 2014-01-16 17:11 ` Eli Zaretskii
2014-01-17 20:29 ` Eric S. Raymond
0 siblings, 1 reply; 39+ messages in thread
From: Eli Zaretskii @ 2014-01-16 17:11 UTC (permalink / raw
To: Eric S. Raymond; +Cc: emacs-devel
> From: esr@thyrsus.com (Eric S. Raymond)
> Date: Thu, 16 Jan 2014 09:15:06 -0500 (EST)
>
> Eli Zaretskii:
> "revisions 103939.1.41..103939.1.44 (inclusive)"
This one is part of a merge commit in trunk revno 104201:
104201: Glenn Morris 2011-05-12 [merge] Merge from emacs-23; up to r100577.
99634.2.943: Drew Adams 2011-05-11 src/textprop.c (Fprevious_single_char_property_change): Doc fix (bug#8655).
99634.2.942: YAMAMOTO Mitsuharu 2011-05-11 Take account of fringe background extension in scroll_run_hook.
99634.2.941: Eli Zaretskii 2011-05-09 Typo fix in doc/lispref/files.texi.
99634.2.940: Eli Zaretskii 2011-05-09 Minor portability fix in smerge-mode.el.
99634.2.939: Stefan Monnier 2011-05-09 * lisp/emacs-lisp/lisp.el (lisp-complete-symbol, lisp-completion-at-point):
99634.2.938: Andreas Schwab 2011-05-09 * xmenu.c (set_frame_menubar): Fix submenu loops.
99634.2.937: Eli Zaretskii 2011-05-09 Backport revisions 103939.1.41..103939.1.44 (inclusive) from trunk (bug#8623)
99634.2.936: Ralph Schleicher 2011-05-08 Handle missing add-log-current-defun-function in Which Func mode (Bug#8260)
99634.2.935: Stefan Monnier 2011-05-06 * lispref/modes.texi (Region to Refontify): Rename from "Region to Fontify".
99634.2.934: Drew Adams 2011-05-05 doc/lispref/modes.texi (Region to Fontify): Fix typo.
104200: Glenn Morris 2011-05-12 bytecomp.el fix for bug#8647
That merge commit was a merge from emacs-23 branch to the trunk,
something we do frequently when both the trunk and the release branch
are active.
To see the details of that commit, do this (in the trunk branch):
bzr diff -c 99634.2.937
I see the origin of that commit in the emacs-23 branch:
100571: Eli Zaretskii 2011-05-09 Backport revisions 103939.1.41..103939.1.44 (inclusive) from trunk (bug#8623)
If that doesn't give you the info you want, please tell what else do
you need (e.g., bzr revision IDs are easy, if you need them).
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: The fixes-bug field
2014-01-16 16:30 ` Eric S. Raymond
2014-01-16 16:55 ` Eli Zaretskii
2014-01-16 17:00 ` Glenn Morris
@ 2014-01-16 17:22 ` Achim Gratz
2014-01-16 17:57 ` Glenn Morris
2 siblings, 1 reply; 39+ messages in thread
From: Achim Gratz @ 2014-01-16 17:22 UTC (permalink / raw
To: emacs-devel
Eric S. Raymond writes:
> Stefan Monnier <monnier@iro.umontreal.ca>:
>> > TL;DR: Possible, but a serious PITA. If this is just an It Would Be Nice
>> > rather than being key to an established workflow I'd rather not go there.
>>
>> The "fixes" info is important. Not just "would be nice".
>> Maybe there are other ways to preserve it (e.g. "bzr log", collect the
>> "Fixes" notes and then pass them to "git notes" somehow).
>>
>> Which format is used to keep the "fixes" info in the Git repository is
>> not terribly important, but the info should appear in the "git
>> log" output.
>
> OK, I'll come up with something.
Even with the doubts of what might happen to Git notes in the long run,
I'd think Emacs should have a notes tree (refs/notes/key-value perhaps)
that is used as a key/value store, not for amending commit messages.
Besides the "fixes" stuff maybe the Hydra build results could be stored
there so that when bisecting one could skip over broken commits
automatically.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
DIY Stuff:
http://Synth.Stromeko.net/DIY.html
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: The fixes-bug field
2014-01-16 16:55 ` Eli Zaretskii
@ 2014-01-16 17:54 ` Glenn Morris
2014-01-16 18:09 ` Eric S. Raymond
` (2 more replies)
2014-01-16 18:08 ` Eric S. Raymond
1 sibling, 3 replies; 39+ messages in thread
From: Glenn Morris @ 2014-01-16 17:54 UTC (permalink / raw
To: Eli Zaretskii; +Cc: esr, monnier, emacs-devel
Eli Zaretskii wrote:
> I think we should decide on how to store this info and how to report
> the fixed bugs once we switch to git, before we decide on how to
> convert this data from bzr, and whether or not this justifies a new
> conversion from scratch rather than reuse of the existing mirror.
Absolutely.
I also suggest that any conversion standardize the format of the entries.
At present you find examples of both
http://debbugs.gnu.org/16462
and
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16462
Both point to the same place, but I think the former format is better.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: The fixes-bug field
2014-01-16 17:22 ` Achim Gratz
@ 2014-01-16 17:57 ` Glenn Morris
0 siblings, 0 replies; 39+ messages in thread
From: Glenn Morris @ 2014-01-16 17:57 UTC (permalink / raw
To: Achim Gratz; +Cc: emacs-devel
Achim Gratz wrote:
> Besides the "fixes" stuff maybe the Hydra build results could be stored
> there so that when bisecting one could skip over broken commits
> automatically.
Nice idea. Would need some care, since my impression is that it fails
more often due to non-Emacs problems (hydra disk full or somesuch).
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: The fixes-bug field
2014-01-16 16:55 ` Eli Zaretskii
2014-01-16 17:54 ` Glenn Morris
@ 2014-01-16 18:08 ` Eric S. Raymond
2014-01-16 18:36 ` Eli Zaretskii
1 sibling, 1 reply; 39+ messages in thread
From: Eric S. Raymond @ 2014-01-16 18:08 UTC (permalink / raw
To: Eli Zaretskii; +Cc: monnier, emacs-devel
Eli Zaretskii <eliz@gnu.org>:
> I think we should decide on how to store this info and how to report
> the fixed bugs once we switch to git, before we decide on how to
> convert this data from bzr, and whether or not this justifies a new
> conversion from scratch rather than reuse of the existing mirror.
My tentative plan is to append a report of the fixes property to each
log message that has it.
In order to fix up commit references, I'm going to have to build a small
database that maps Bazaar revnos to action stamps. That in turn I will
use to generate a sequence of reposurgeon commands that will patch up
the repository content. For the curious, an example command would look
like this:
[ChangeLog] filter --regex /revno 108687/2012-06-13T21:07:35Z!eggert@cs.ucla.edu/
except I'll probably add a --replace modifier to the reposurgeon
filter command that avoids the regexp overhead.
Building that database already requires parsing the output of bzr log.
Since I have to do that anyway, parsing the fixes-bug property and
associating it with the revno is not much more work. I'll generate
commands that append each report to the proper commit (the
equivalent of the rewriter someone else mentioned).
All these commands, together with several hundred tag names and deletes,
will go into a reposurgeon script that I run on conversion day.
I also plan, by the way, to run a coalescence pass. There are cliques of
formerly-CVS commits with identical messages that didn't get properly
merged when Andreas did the CVS lift, probably because the merge time window
was set too small. (This is *very* common in CVS conversions.)
Yes, preparing for this will be a lot of work. Welcome to the difference
between a crappy conversion done with weak tools and a really high-quality
lift done with good tools and craftsmanlike attention to the individual
project history.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: The fixes-bug field
2014-01-16 17:54 ` Glenn Morris
@ 2014-01-16 18:09 ` Eric S. Raymond
2014-01-16 18:38 ` Darren Hoo
2014-01-16 18:55 ` Paul Eggert
2 siblings, 0 replies; 39+ messages in thread
From: Eric S. Raymond @ 2014-01-16 18:09 UTC (permalink / raw
To: Glenn Morris; +Cc: Eli Zaretskii, monnier, emacs-devel
Glenn Morris <rgm@gnu.org>:
> I also suggest that any conversion standardize the format of the entries.
> At present you find examples of both
>
> http://debbugs.gnu.org/16462
>
> and
>
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16462
>
> Both point to the same place, but I think the former format is better.
Can be done.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: The fixes-bug field
2014-01-16 18:08 ` Eric S. Raymond
@ 2014-01-16 18:36 ` Eli Zaretskii
2014-01-16 20:04 ` Eric S. Raymond
0 siblings, 1 reply; 39+ messages in thread
From: Eli Zaretskii @ 2014-01-16 18:36 UTC (permalink / raw
To: esr; +Cc: monnier, emacs-devel
> Date: Thu, 16 Jan 2014 13:08:09 -0500
> From: "Eric S. Raymond" <esr@thyrsus.com>
> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
>
> Eli Zaretskii <eliz@gnu.org>:
> > I think we should decide on how to store this info and how to report
> > the fixed bugs once we switch to git, before we decide on how to
> > convert this data from bzr, and whether or not this justifies a new
> > conversion from scratch rather than reuse of the existing mirror.
>
> My tentative plan is to append a report of the fixes property to each
> log message that has it.
And how would I commit a change that fixes a certain bug? What
commands would I use?
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: The fixes-bug field
2014-01-16 17:54 ` Glenn Morris
2014-01-16 18:09 ` Eric S. Raymond
@ 2014-01-16 18:38 ` Darren Hoo
2014-01-16 19:32 ` Stefan Monnier
2014-01-16 21:24 ` Eli Zaretskii
2014-01-16 18:55 ` Paul Eggert
2 siblings, 2 replies; 39+ messages in thread
From: Darren Hoo @ 2014-01-16 18:38 UTC (permalink / raw
To: emacs-devel
Glenn Morris <rgm@gnu.org> writes:
> Eli Zaretskii wrote:
>
>> I think we should decide on how to store this info and how to report
>> the fixed bugs once we switch to git, before we decide on how to
>> convert this data from bzr, and whether or not this justifies a new
>> conversion from scratch rather than reuse of the existing mirror.
>
> Absolutely.
>
> I also suggest that any conversion standardize the format of the entries.
> At present you find examples of both
>
> http://debbugs.gnu.org/16462
>
> and
>
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16462
>
> Both point to the same place, but I think the former format is better.
What benefit do we get by using bzr fixes bug over mentioning it in the
commit log like (Bug#16462)? I can see some of them in the ChangeLogs.
I like (Bug#16462) better because it also appears in the ChangeLog.
and since the Bug Id is universal, using full url is somewhat redundant.
As a regular user it is easier for me to just go through the ChangeLog file
to check whether a certain bug I care about is fixed in Emacs releases.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: The fixes-bug field
2014-01-16 17:54 ` Glenn Morris
2014-01-16 18:09 ` Eric S. Raymond
2014-01-16 18:38 ` Darren Hoo
@ 2014-01-16 18:55 ` Paul Eggert
2014-01-16 19:13 ` Glenn Morris
2 siblings, 1 reply; 39+ messages in thread
From: Paul Eggert @ 2014-01-16 18:55 UTC (permalink / raw
To: Glenn Morris; +Cc: esr, emacs-devel
On 01/16/2014 09:54 AM, Glenn Morris wrote:
> I also suggest that any conversion standardize the format of the entries.
> At present you find examples of both
>
> http://debbugs.gnu.org/16462
>
> and
>
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16462
>
> Both point to the same place, but I think the former format is better.
>
Better yet is:
http://bugs.gnu.org/16462
I use this URL format in places where plain "Bug#16462"
wouldn't do.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: The fixes-bug field
2014-01-16 18:55 ` Paul Eggert
@ 2014-01-16 19:13 ` Glenn Morris
2014-01-16 20:25 ` Paul Eggert
0 siblings, 1 reply; 39+ messages in thread
From: Glenn Morris @ 2014-01-16 19:13 UTC (permalink / raw
To: Paul Eggert; +Cc: esr, emacs-devel
Paul Eggert wrote:
> Better yet is:
>
> http://bugs.gnu.org/16462
Not sure I agree. I've never really liked this alias.
Imagine GNU switches to a new tracker a year from now, and it takes over
the bugs.gnu.org alias. Would the above url still be valid, and still
point to the right report? Who knows...
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: The fixes-bug field
2014-01-16 18:38 ` Darren Hoo
@ 2014-01-16 19:32 ` Stefan Monnier
2014-01-16 20:06 ` Glenn Morris
2014-01-16 21:24 ` Eli Zaretskii
1 sibling, 1 reply; 39+ messages in thread
From: Stefan Monnier @ 2014-01-16 19:32 UTC (permalink / raw
To: Darren Hoo; +Cc: emacs-devel
> What benefit do we get by using bzr fixes bug over mentioning it in the
> commit log like (Bug#16462)? I can see some of them in the ChangeLogs.
I agree that bug#NNN is the better format. Bzr preferred a URL, so we
obliged, but since Git doesn't care about it, I'd rather use
this format.
Stefan
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: The fixes-bug field
2014-01-16 18:36 ` Eli Zaretskii
@ 2014-01-16 20:04 ` Eric S. Raymond
2014-01-16 21:29 ` Eli Zaretskii
0 siblings, 1 reply; 39+ messages in thread
From: Eric S. Raymond @ 2014-01-16 20:04 UTC (permalink / raw
To: Eli Zaretskii; +Cc: monnier, emacs-devel
Eli Zaretskii <eliz@gnu.org>:
> > Date: Thu, 16 Jan 2014 13:08:09 -0500
> > From: "Eric S. Raymond" <esr@thyrsus.com>
> > Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> >
> > Eli Zaretskii <eliz@gnu.org>:
> > > I think we should decide on how to store this info and how to report
> > > the fixed bugs once we switch to git, before we decide on how to
> > > convert this data from bzr, and whether or not this justifies a new
> > > conversion from scratch rather than reuse of the existing mirror.
> >
> > My tentative plan is to append a report of the fixes property to each
> > log message that has it.
>
> And how would I commit a change that fixes a certain bug? What
> commands would I use?
There wouldn't be a --fixes sitch in git itself, if that's what you mean.
We could I suppose supply a wrapper command that would interpret it.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: The fixes-bug field
2014-01-16 19:32 ` Stefan Monnier
@ 2014-01-16 20:06 ` Glenn Morris
2014-01-16 21:30 ` Eli Zaretskii
0 siblings, 1 reply; 39+ messages in thread
From: Glenn Morris @ 2014-01-16 20:06 UTC (permalink / raw
To: Stefan Monnier; +Cc: emacs-devel, Darren Hoo
Stefan Monnier wrote:
> I agree that bug#NNN is the better format. Bzr preferred a URL, so we
> obliged, but since Git doesn't care about it, I'd rather use
> this format.
Nothing was stopping us using
bugtracker_debbugs_url = {id}
in bazaar.conf
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: The fixes-bug field
2014-01-16 19:13 ` Glenn Morris
@ 2014-01-16 20:25 ` Paul Eggert
0 siblings, 0 replies; 39+ messages in thread
From: Paul Eggert @ 2014-01-16 20:25 UTC (permalink / raw
To: Glenn Morris; +Cc: esr, emacs-devel
On 01/16/2014 11:13 AM, Glenn Morris wrote:
> Imagine GNU switches to a new tracker a year from now, and it takes over
> the bugs.gnu.org alias. Would the above url still be valid, and still
> point to the right report? Who knows...
Nobody knows the future for certain, but I'd be
quite surprised if the short URLs stopped working
any time soon. They're too-commonly used in other
GNU projects.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: The fixes-bug field
2014-01-16 18:38 ` Darren Hoo
2014-01-16 19:32 ` Stefan Monnier
@ 2014-01-16 21:24 ` Eli Zaretskii
1 sibling, 0 replies; 39+ messages in thread
From: Eli Zaretskii @ 2014-01-16 21:24 UTC (permalink / raw
To: Darren Hoo; +Cc: emacs-devel
> From: Darren Hoo <darren.hoo@gmail.com>
> Date: Fri, 17 Jan 2014 02:38:48 +0800
>
> What benefit do we get by using bzr fixes bug over mentioning it in the
> commit log like (Bug#16462)?
The benefit of making transition to git harder, of course.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: The fixes-bug field
2014-01-16 20:04 ` Eric S. Raymond
@ 2014-01-16 21:29 ` Eli Zaretskii
2014-01-16 21:47 ` Eric S. Raymond
0 siblings, 1 reply; 39+ messages in thread
From: Eli Zaretskii @ 2014-01-16 21:29 UTC (permalink / raw
To: esr; +Cc: monnier, emacs-devel
> Date: Thu, 16 Jan 2014 15:04:56 -0500
> From: "Eric S. Raymond" <esr@thyrsus.com>
> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
>
> There wouldn't be a --fixes sitch in git itself, if that's what you mean.
> We could I suppose supply a wrapper command that would interpret it.
I think we need to figure out these details and more or less agree on
them, before converting the repository (if needed). The worst thing
that can happen is to invest all that effort, only to find out later
that adding more "fixes bug NNN" commits don't work well, or that
there's a much more easy/elegant way of doing that.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: The fixes-bug field
2014-01-16 20:06 ` Glenn Morris
@ 2014-01-16 21:30 ` Eli Zaretskii
0 siblings, 0 replies; 39+ messages in thread
From: Eli Zaretskii @ 2014-01-16 21:30 UTC (permalink / raw
To: Glenn Morris; +Cc: darren.hoo, monnier, emacs-devel
> From: Glenn Morris <rgm@gnu.org>
> Date: Thu, 16 Jan 2014 15:06:06 -0500
> Cc: emacs-devel@gnu.org, Darren Hoo <darren.hoo@gmail.com>
>
> Stefan Monnier wrote:
>
> > I agree that bug#NNN is the better format. Bzr preferred a URL, so we
> > obliged, but since Git doesn't care about it, I'd rather use
> > this format.
>
> Nothing was stopping us using
>
> bugtracker_debbugs_url = {id}
>
> in bazaar.conf
I think we just went for the example of Launchpad, that's all.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: The fixes-bug field
2014-01-16 21:29 ` Eli Zaretskii
@ 2014-01-16 21:47 ` Eric S. Raymond
2014-01-17 7:32 ` Eli Zaretskii
0 siblings, 1 reply; 39+ messages in thread
From: Eric S. Raymond @ 2014-01-16 21:47 UTC (permalink / raw
To: Eli Zaretskii; +Cc: monnier, emacs-devel
Eli Zaretskii <eliz@gnu.org>:
> I think we need to figure out these details and more or less agree on
> them, before converting the repository (if needed). The worst thing
> that can happen is to invest all that effort, only to find out later
> that adding more "fixes bug NNN" commits don't work well, or that
> there's a much more easy/elegant way of doing that.
You guys figure out what policy you want. I'll either implement it
or (less likely) explain why I can't.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: The fixes-bug field
2014-01-16 21:47 ` Eric S. Raymond
@ 2014-01-17 7:32 ` Eli Zaretskii
2014-01-17 7:58 ` Paul Eggert
` (2 more replies)
0 siblings, 3 replies; 39+ messages in thread
From: Eli Zaretskii @ 2014-01-17 7:32 UTC (permalink / raw
To: esr; +Cc: monnier, emacs-devel
> Date: Thu, 16 Jan 2014 16:47:14 -0500
> From: "Eric S. Raymond" <esr@thyrsus.com>
> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
>
> Eli Zaretskii <eliz@gnu.org>:
> > I think we need to figure out these details and more or less agree on
> > them, before converting the repository (if needed). The worst thing
> > that can happen is to invest all that effort, only to find out later
> > that adding more "fixes bug NNN" commits don't work well, or that
> > there's a much more easy/elegant way of doing that.
>
> You guys figure out what policy you want. I'll either implement it
> or (less likely) explain why I can't.
I don't know enough about git to make useful suggestions, sorry.
I also don't quite understand what you mean by "policy". With my
understanding of "policy", I thought that part was already clear: we
want a committer to be able to say "this changeset is related to bug
#XYZZY", and have that info recorded in the history in a way that
would later support queries of the type "which commit(s) are related
to bug #12345?"
(Note that I say "related to" because "fixes" might be inaccurate: we
sometimes commit changes that fix only parts of a bug, or even make
the bug easier to catch. We also sometimes revert incorrect
bugfixes.)
If this information will be in the commit message (one suggestion so
far, AFAIU), we should define its precise format and location within
the commit message. We should also try to find a convenient way of
specifying the bug number from the 'git commit' command line. If git
supports some extensibility features, we should either find or write
an extension for that. If no such features are available at this
time, we could ask git developers to provide one for this purpose,
like we asked the bzr developers to develop the changelog_merge plugin
that avoids merge conflicts in ChangeLog files.
Similar issues arise with other possible implementations, like git
notes or maybe tags.
The above is my take on the "policy" part; comments are welcome. But
what I hoped to see and didn't is discussion of git features that
could be used for this functionality and comparison of their relative
merits and demerits. I don't see how we can make a decision on that
without some research in this area, and I hoped that git experts
around here will provide their knowledge and expertise to help us make
that decision. Instead, I see a lot of discussions about the
technique of converting the bugfix information, which is IMO
premature, as long as we didn't decide how to store it in git and how
to specify it at commit time.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: The fixes-bug field
2014-01-17 7:32 ` Eli Zaretskii
@ 2014-01-17 7:58 ` Paul Eggert
2014-01-17 8:04 ` Jarek Czekalski
2014-01-17 14:31 ` Stefan Monnier
2014-01-17 13:16 ` Eric S. Raymond
2014-01-17 14:26 ` Stefan Monnier
2 siblings, 2 replies; 39+ messages in thread
From: Paul Eggert @ 2014-01-17 7:58 UTC (permalink / raw
To: Eli Zaretskii, esr; +Cc: monnier, emacs-devel
Eli Zaretskii wrote:
> If this information will be in the commit message (one suggestion so
> far, AFAIU), we should define its precise format and location within
> the commit message.
Let's define the format that we're already using in ChangeLog entries.
That is, a commit message that contains the string "Bug#16372" is
related to Bug#16372. This would be simpler and more natural than
what we're doing now.
For example, with bzr, this ChangeLog entry:
2014-01-07 Paul Eggert <eggert@cs.ucla.edu>
Fix misdisplay of interlaced GIFs with libgif5 (Bug#16372).
* image.c (gif_load): libgif5 deinterlaces for us, so don't do
it again.
corresponds to this commit message in trunk bzr 115915:
Fix misdisplay of interlaced GIFs with libgif5.
* image.c (gif_load): libgif5 deinterlaces for us, so don't do
it again.
and means that the change is related to Bug#16372.
With git, I'd prefer using a commit message that matches what's in
the ChangeLog entry, as that's simpler anyway. I.e., I'd rather use
this commit message:
Fix misdisplay of interlaced GIFs with libgif5 (Bug#16372).
* image.c (gif_load): libgif5 deinterlaces for us, so don't do
it again.
This way, I could use vanilla vc-dwim to check in my changes,
rather the current song and dance where the commit message doesn't
quite match the ChangeLog entry (as the Bug# is missing)
and I run bzr with the --fixes option to communicate the Bug#.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: The fixes-bug field
2014-01-17 7:58 ` Paul Eggert
@ 2014-01-17 8:04 ` Jarek Czekalski
2014-01-17 9:21 ` Yuri Khan
2014-01-17 14:31 ` Stefan Monnier
1 sibling, 1 reply; 39+ messages in thread
From: Jarek Czekalski @ 2014-01-17 8:04 UTC (permalink / raw
To: Emacs-devel
W dniu 2014-01-17 08:58, Paul Eggert pisze:
> Fix misdisplay of interlaced GIFs with libgif5 (Bug#16372).
While this example seems perfect, please note that the following would be
not good:
Fixed Bug#16372
Because a person examining the log would see only meaningless sequence:
Fixed x
Fixed y
Fixed z
...
If you agree, it would be important to react to such commits and have some
statement about it in wiki.
Jarek
--
View this message in context: http://emacs.1067599.n5.nabble.com/The-fixes-bug-field-tp310468p310595.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: The fixes-bug field
2014-01-17 8:04 ` Jarek Czekalski
@ 2014-01-17 9:21 ` Yuri Khan
0 siblings, 0 replies; 39+ messages in thread
From: Yuri Khan @ 2014-01-17 9:21 UTC (permalink / raw
To: Jarek Czekalski; +Cc: Emacs developers
On Fri, Jan 17, 2014 at 3:04 PM, Jarek Czekalski
<jarekczek@poczta.onet.pl> wrote:
> W dniu 2014-01-17 08:58, Paul Eggert pisze:
>> Fix misdisplay of interlaced GIFs with libgif5 (Bug#16372).
>
> While this example seems perfect, please note that the following would be
> not good:
>
> Fixed Bug#16372
Indeed. The first line (summary) of a commit message must be
descriptive enough when the log is displayed in one-line format. The
rule of thumb is to treat the commit message summary as an email
subject, and the rest of the commit message as the body of an email
message accompanying a patch.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: The fixes-bug field
2014-01-17 7:32 ` Eli Zaretskii
2014-01-17 7:58 ` Paul Eggert
@ 2014-01-17 13:16 ` Eric S. Raymond
2014-01-17 13:55 ` Eli Zaretskii
2014-01-17 14:26 ` Stefan Monnier
2 siblings, 1 reply; 39+ messages in thread
From: Eric S. Raymond @ 2014-01-17 13:16 UTC (permalink / raw
To: Eli Zaretskii; +Cc: monnier, emacs-devel
Eli Zaretskii <eliz@gnu.org>:
> > You guys figure out what policy you want. I'll either implement it
> > or (less likely) explain why I can't.
>
> I don't know enough about git to make useful suggestions, sorry.
>
> I also don't quite understand what you mean by "policy".
That is, what form of machine-readable stamp you want to put on commits.
I think Paul Eggert answered this pretty well.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: The fixes-bug field
2014-01-17 13:16 ` Eric S. Raymond
@ 2014-01-17 13:55 ` Eli Zaretskii
0 siblings, 0 replies; 39+ messages in thread
From: Eli Zaretskii @ 2014-01-17 13:55 UTC (permalink / raw
To: esr; +Cc: monnier, emacs-devel
> Date: Fri, 17 Jan 2014 08:16:12 -0500
> From: "Eric S. Raymond" <esr@thyrsus.com>
> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
>
> Eli Zaretskii <eliz@gnu.org>:
> > > You guys figure out what policy you want. I'll either implement it
> > > or (less likely) explain why I can't.
> >
> > I don't know enough about git to make useful suggestions, sorry.
> >
> > I also don't quite understand what you mean by "policy".
>
> That is, what form of machine-readable stamp you want to put on commits.
This should be part of the discussion.
> I think Paul Eggert answered this pretty well.
If no one objects, neither do I.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: The fixes-bug field
2014-01-17 7:32 ` Eli Zaretskii
2014-01-17 7:58 ` Paul Eggert
2014-01-17 13:16 ` Eric S. Raymond
@ 2014-01-17 14:26 ` Stefan Monnier
2 siblings, 0 replies; 39+ messages in thread
From: Stefan Monnier @ 2014-01-17 14:26 UTC (permalink / raw
To: Eli Zaretskii; +Cc: esr, emacs-devel
> (Note that I say "related to" because "fixes" might be inaccurate: we
Very much so, indeed. The point for me is that a "bug#NNN" in the VCS
is a concise way to provide extra context about the commit, just in the
same way we use it in comments in the code.
IOW it serves so that when in a few years's time you'll be looking at
these few lines of code and wonder why on earth we did it that way, you
can go see what was the corresponding bug, which may even include
a handy test case.
Stefan
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: The fixes-bug field
2014-01-17 7:58 ` Paul Eggert
2014-01-17 8:04 ` Jarek Czekalski
@ 2014-01-17 14:31 ` Stefan Monnier
2014-01-17 15:57 ` Lars Ingebrigtsen
1 sibling, 1 reply; 39+ messages in thread
From: Stefan Monnier @ 2014-01-17 14:31 UTC (permalink / raw
To: Paul Eggert; +Cc: esr, Eli Zaretskii, emacs-devel
> With git, I'd prefer using a commit message that matches what's in
> the ChangeLog entry, as that's simpler anyway. I.e., I'd rather use
> this commit message:
> Fix misdisplay of interlaced GIFs with libgif5 (Bug#16372).
That's good enough for me, yes. Having a more strongly formalized form
(as used in Bzr) can be handy to add backlinks from the bug tracker's
web pages to related commits, tho.
Also, the first line tends to be longish already, so it might be
preferable to place it at the end instead.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: The fixes-bug field
2014-01-17 14:31 ` Stefan Monnier
@ 2014-01-17 15:57 ` Lars Ingebrigtsen
2014-01-17 16:12 ` Stefan Monnier
2014-01-18 9:19 ` Jarek Czekalski
0 siblings, 2 replies; 39+ messages in thread
From: Lars Ingebrigtsen @ 2014-01-17 15:57 UTC (permalink / raw
To: Stefan Monnier; +Cc: esr, Eli Zaretskii, Paul Eggert, emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> With git, I'd prefer using a commit message that matches what's in
>> the ChangeLog entry, as that's simpler anyway. I.e., I'd rather use
>> this commit message:
>> Fix misdisplay of interlaced GIFs with libgif5 (Bug#16372).
>
> That's good enough for me, yes. Having a more strongly formalized form
> (as used in Bzr) can be handy to add backlinks from the bug tracker's
> web pages to related commits, tho.
I'd suggest extending this to (fixes bug#16372). That way you can refer
to bugs without saying that you've fixed them. (I.e., the syntax is
(<command> bug#number [optional stuff]).)
And we can later implement a git commit hook that sends the correct
command to debbugs, so that all we have to do to fix and close a bug is
to check in and to push it.
That's what we do at work, and it works well for 97% of the use cases.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: The fixes-bug field
2014-01-17 15:57 ` Lars Ingebrigtsen
@ 2014-01-17 16:12 ` Stefan Monnier
2014-01-17 17:20 ` Lars Ingebrigtsen
2014-01-18 9:19 ` Jarek Czekalski
1 sibling, 1 reply; 39+ messages in thread
From: Stefan Monnier @ 2014-01-17 16:12 UTC (permalink / raw
To: Lars Ingebrigtsen; +Cc: esr, Eli Zaretskii, Paul Eggert, emacs-devel
> I'd suggest extending this to (fixes bug#16372). That way you can refer
> to bugs without saying that you've fixed them. (I.e., the syntax is
> (<command> bug#number [optional stuff]).)
When we started using such bug#NNN in the ChangeLog (and commit logs)
I indeed wanted to use to mean "fixes bug NNN", even hoping that we
could write some commit hook that would automatically close the bug.
But in practice, I'm often not actually sure that the patch will fix the
bug when I commit it (e.g. because the recipe given in the bug-report
is clearly a subcase of the OP's real life problem, so I can't be sure
the real life problem will be fixed as well).
IOW, in many/most situations I only find out after committing that the
patch really fixes the bug. So it would work if the "fixes bug#NNN" can
be added via something like "git notes", but it won't work well in the
commit message itself.
Stefan
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: The fixes-bug field
2014-01-17 16:12 ` Stefan Monnier
@ 2014-01-17 17:20 ` Lars Ingebrigtsen
0 siblings, 0 replies; 39+ messages in thread
From: Lars Ingebrigtsen @ 2014-01-17 17:20 UTC (permalink / raw
To: Stefan Monnier; +Cc: esr, Eli Zaretskii, Paul Eggert, emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> IOW, in many/most situations I only find out after committing that the
> patch really fixes the bug. So it would work if the "fixes bug#NNN" can
> be added via something like "git notes", but it won't work well in the
> commit message itself.
Well, I usually close the bug report after I think I've fixed the bug.
If it turns out that I'm wrong, bugs can be reopened. But in the vast
majority of the cases, I'm right. (Ahem.)
If we're unsure, there's nothing to stop us from committing something
that just mentions the bug without "fixes".
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: The fixes-bug field
2014-01-16 17:11 ` Eli Zaretskii
@ 2014-01-17 20:29 ` Eric S. Raymond
2014-01-18 7:51 ` Eli Zaretskii
0 siblings, 1 reply; 39+ messages in thread
From: Eric S. Raymond @ 2014-01-17 20:29 UTC (permalink / raw
To: Eli Zaretskii; +Cc: emacs-devel
Eli Zaretskii <eliz@gnu.org>:
> > From: esr@thyrsus.com (Eric S. Raymond)
> > Date: Thu, 16 Jan 2014 09:15:06 -0500 (EST)
> >
> > Eli Zaretskii:
> > "revisions 103939.1.41..103939.1.44 (inclusive)"
> If that doesn't give you the info you want, please tell what else do
> you need (e.g., bzr revision IDs are easy, if you need them).
High-level, what I want is a VCS-independent was to describe that range
of commits.
Unless there's an easy synoptic description of that range in English
(which would be preferable, but seems unlikely), I'll need the
committer and timestamp of 103939.1.41 and 103939.1.44 so I can
express those as action stamps.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: The fixes-bug field
2014-01-17 20:29 ` Eric S. Raymond
@ 2014-01-18 7:51 ` Eli Zaretskii
0 siblings, 0 replies; 39+ messages in thread
From: Eli Zaretskii @ 2014-01-18 7:51 UTC (permalink / raw
To: esr; +Cc: emacs-devel
> Date: Fri, 17 Jan 2014 15:29:57 -0500
> From: "Eric S. Raymond" <esr@thyrsus.com>
> Cc: emacs-devel@gnu.org
>
> Eli Zaretskii <eliz@gnu.org>:
> > > From: esr@thyrsus.com (Eric S. Raymond)
> > > Date: Thu, 16 Jan 2014 09:15:06 -0500 (EST)
> > >
> > > Eli Zaretskii:
> > > "revisions 103939.1.41..103939.1.44 (inclusive)"
> > If that doesn't give you the info you want, please tell what else do
> > you need (e.g., bzr revision IDs are easy, if you need them).
>
> High-level, what I want is a VCS-independent was to describe that range
> of commits.
>
> Unless there's an easy synoptic description of that range in English
> (which would be preferable, but seems unlikely)
Sorry, I don't understand what needs to be explained. Those are trunk
revision numbers, they are of the "dotted" NNN.X.Y form because they
came from a merge commit of another branch. That branch was Paul
Eggert's local feature branch. But the revisions are still accessible
on the trunk using those very numbers (that's why I made a point of
specifying _trunk_ revno numbers, although the commit was on the
emacs-23 branch -- I knew that trunk will live forever).
So whatever you need to know about these revisions you can see using
these numbers, for example:
bzr log -c 103939.1.41
> I'll need the committer and timestamp of 103939.1.41 and 103939.1.44
> so I can express those as action stamps.
Since both the committer and the time stamp are in the bzr revision
ID, here you go:
bzr log --include-merged --long --show-ids -r 103939.1.41..103939.1.44 | fgrep revision-id
revision-id: eggert@cs.ucla.edu-20110425213439-wok7h5v3k2w6ypke
revision-id: eggert@cs.ucla.edu-20110425194022-kykvykyv2w7o4arq
revision-id: eggert@cs.ucla.edu-20110425073357-1egaqnih5jn5juxe
revision-id: eggert@cs.ucla.edu-20110425071446-kj82psqnn82sjnsb
You want the first 2 parts of the revision IDs, before the 2nd dash.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: The fixes-bug field
2014-01-17 15:57 ` Lars Ingebrigtsen
2014-01-17 16:12 ` Stefan Monnier
@ 2014-01-18 9:19 ` Jarek Czekalski
2014-01-18 16:02 ` Lars Ingebrigtsen
1 sibling, 1 reply; 39+ messages in thread
From: Jarek Czekalski @ 2014-01-18 9:19 UTC (permalink / raw
To: emacs-devel
W dniu 2014-01-17 16:57, Lars Ingebrigtsen pisze:
> I'd suggest extending this to (fixes bug#16372). That way you can refer
> to bugs without saying that you've fixed them. (I.e., the syntax is
> (<command> bug#number [optional stuff]).)
But when you assume that "fixes" is a default command, then you don't
need to waste for that 6 precious chars in the title line.
Jarek
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: The fixes-bug field
2014-01-18 9:19 ` Jarek Czekalski
@ 2014-01-18 16:02 ` Lars Ingebrigtsen
0 siblings, 0 replies; 39+ messages in thread
From: Lars Ingebrigtsen @ 2014-01-18 16:02 UTC (permalink / raw
To: Jarek Czekalski; +Cc: emacs-devel
Jarek Czekalski <jarekczek@poczta.onet.pl> writes:
> But when you assume that "fixes" is a default command, then you don't
> need to waste for that 6 precious chars in the title line.
We don't have to put these commands in the title.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
^ permalink raw reply [flat|nested] 39+ messages in thread
end of thread, other threads:[~2014-01-18 16:02 UTC | newest]
Thread overview: 39+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-01-16 14:15 The fixes-bug field Eric S. Raymond
2014-01-16 17:11 ` Eli Zaretskii
2014-01-17 20:29 ` Eric S. Raymond
2014-01-18 7:51 ` Eli Zaretskii
-- strict thread matches above, loose matches on Subject: below --
2014-01-16 14:13 Eric S. Raymond
2014-01-16 16:13 ` Stefan Monnier
2014-01-16 16:30 ` Eric S. Raymond
2014-01-16 16:55 ` Eli Zaretskii
2014-01-16 17:54 ` Glenn Morris
2014-01-16 18:09 ` Eric S. Raymond
2014-01-16 18:38 ` Darren Hoo
2014-01-16 19:32 ` Stefan Monnier
2014-01-16 20:06 ` Glenn Morris
2014-01-16 21:30 ` Eli Zaretskii
2014-01-16 21:24 ` Eli Zaretskii
2014-01-16 18:55 ` Paul Eggert
2014-01-16 19:13 ` Glenn Morris
2014-01-16 20:25 ` Paul Eggert
2014-01-16 18:08 ` Eric S. Raymond
2014-01-16 18:36 ` Eli Zaretskii
2014-01-16 20:04 ` Eric S. Raymond
2014-01-16 21:29 ` Eli Zaretskii
2014-01-16 21:47 ` Eric S. Raymond
2014-01-17 7:32 ` Eli Zaretskii
2014-01-17 7:58 ` Paul Eggert
2014-01-17 8:04 ` Jarek Czekalski
2014-01-17 9:21 ` Yuri Khan
2014-01-17 14:31 ` Stefan Monnier
2014-01-17 15:57 ` Lars Ingebrigtsen
2014-01-17 16:12 ` Stefan Monnier
2014-01-17 17:20 ` Lars Ingebrigtsen
2014-01-18 9:19 ` Jarek Czekalski
2014-01-18 16:02 ` Lars Ingebrigtsen
2014-01-17 13:16 ` Eric S. Raymond
2014-01-17 13:55 ` Eli Zaretskii
2014-01-17 14:26 ` Stefan Monnier
2014-01-16 17:00 ` Glenn Morris
2014-01-16 17:22 ` Achim Gratz
2014-01-16 17:57 ` Glenn Morris
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.