The fixes-bug field

The fixes-bug field

[Eric S. Raymond]

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

Re: The fixes-bug field

[Eli Zaretskii]

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

Re: The fixes-bug field

[Eric S. Raymond]

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>

Re: The fixes-bug field

[Eli Zaretskii]

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

The fixes-bug field

[Eric S. Raymond]

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

Re: The fixes-bug field

[Stefan Monnier]

> 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

Re: The fixes-bug field

[Eric S. Raymond]

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>

Re: The fixes-bug field

[Eli Zaretskii]

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

Re: The fixes-bug field

[Glenn Morris]

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.

Re: The fixes-bug field

[Eric S. Raymond]

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>

Re: The fixes-bug field

[Darren Hoo]

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.

Re: The fixes-bug field

[Stefan Monnier]

> 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

Re: The fixes-bug field

[Glenn Morris]

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

Re: The fixes-bug field

[Eli Zaretskii]

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

Re: The fixes-bug field

[Eli Zaretskii]

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

Re: The fixes-bug field

[Paul Eggert]

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.

Re: The fixes-bug field

[Glenn Morris]

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

Re: The fixes-bug field

[Paul Eggert]

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.

Re: The fixes-bug field

[Eric S. Raymond]

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>

Re: The fixes-bug field

[Eli Zaretskii]

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

Re: The fixes-bug field

[Eric S. Raymond]

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>

Re: The fixes-bug field

[Eli Zaretskii]

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

Re: The fixes-bug field

[Eric S. Raymond]

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>

Re: The fixes-bug field

[Eli Zaretskii]

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

Re: The fixes-bug field

[Paul Eggert]

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

Re: The fixes-bug field

[Jarek Czekalski]

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.

Re: The fixes-bug field

[Yuri Khan]

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.

Re: The fixes-bug field

[Stefan Monnier]

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

Re: The fixes-bug field

[Lars Ingebrigtsen]

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/

Re: The fixes-bug field

[Stefan Monnier]

> 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

Re: The fixes-bug field

[Lars Ingebrigtsen]

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/

Re: The fixes-bug field

[Jarek Czekalski]

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

Re: The fixes-bug field

[Lars Ingebrigtsen]

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/

Re: The fixes-bug field

[Eric S. Raymond]

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>

Re: The fixes-bug field

[Eli Zaretskii]

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

Re: The fixes-bug field

[Stefan Monnier]

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

Re: The fixes-bug field

[Glenn Morris]

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.

Re: The fixes-bug field

[Achim Gratz]

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

Re: The fixes-bug field

[Glenn Morris]

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