Re: The fixes-bug field

[Eli Zaretskii]

> Date: Thu, 16 Jan 2014 16:47:14 -0500
> From: "Eric S. Raymond" <address@hidden>
> Cc: address@hidden, address@hidden
> 
> Eli Zaretskii <address@hidden>:
> > 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.