May 28, 2014
Participants: Christian Couder, Jason Cooper, Jiri Kosina, Johan Herland, Li Zefan, Neil Brown, and Theodore Ts'o.
People tagged: Junio Hamano.
Takashi Iwai
would like a per-git-commit metadata collection or link, but such that it
can be added after the commit.
The idea is to allow post-commit information ("it fixed the regression" or
"it caused a regression fixed by this other commit") for the benefit
of git bisect and the like.
Takashi mentioned git notes as being related to his request,
but
said
that workflows for publishing and importing git notes changes
are not well established, perhaps because Linus is not happy with their
usage.
(Christian Couder
argued that it is easy to share git notes, providing the relevant refspecs.)
Neil Brown
liked Takashi's idea, suggesting that it could be used to help
git bisect by identifying commits needed to make a given
bisection point operate correctly, avoiding false git bisect
failures due to broken commits.
Jiri Kosina
suggested storing the fixup commit in a separate branch that
git bisect would know (possibly via scripting assists)
to automatically apply to a given known-bad commit.
Neil
agreed that this could work, but argued that having to do the scripting
was a barrier to this working, preferring that this happen automatically.
Li Zefan
agreed with Takashi's and Neil's points about the benefits of full
automation of associations between fixes and the corresponding buggy
commits.
Jason Cooper
discussed the Fixes:, Link:, and
Coverletter: metadata he has been placing in commits.
Jason avoids the need to tag a commit after the fact by instead tagging
the later commit that fixes the problem,
which
Li Zefan and
Takashi Iwai
pointed out does not help with other use cases.
Christian Couder
has been working on a git interpret-trailers and
git replace commands that are designed to help when
a git bisect encounters buggy commits,
which he expanded on
here.
Takashi Iwai
liked Christian's approach to git bisect, but noted that
bisection is but one use case and also questioned whether Christian's
approach would really work on complex trees like that of the Linux
kernel, where a great many people would need to publish git replace
branches in order for the scheme to work.
Christian
noted
that his approach does handle the additional use cases pointed out by
Li Zefan and
Takashi Iwai.
Christian also stated that an upcoming --edit option should
make git replace easier to use.
Jason Cooper
was uncomfortable with git replace, expressing the hope that this
feature is disabled by default.
Jason also asked if PGP signature verification would fail if there were
git replace tags in the history, and, if so, whether the
failure was cryptographic or logical in nature.
Christian's
answer was that git replace refs are neither fetched nor
pushed by default, so normally the only such refs in your tree would be
those that you put there.
Hooks could also be used to check for git replace refs.
One workflow would be to use one git repository for normal development,
and another for bisection, so that the git replace refs
would appear only in the second tree.
Christian also pointed out that it is possible to globally disable
replacement refs in a given git tree, if desired.
Finally, Christian does not expect replacement refs to result in
PGP-signature failure.
Christian Couder relayed off-list email from Junio Hamano and Johan Herland, in which they argued that:
git replace is too heavy-handed for usage
in a tree intended for general consumption.
git notes, though handy for some things, makes
it hard to merge different lines of notes history.
Junio encouraged further work on the various Fixes:
approaches along with further improvements to Christian's
git interpret-trailers tool.
Junio also suggested that git bisect be improved to
automatically use the Fixes: information, pointing out
Jiri Kosina's suggestion.
Takashi Iwai
liked this approach, but is concerned that a maintainer might forget
to add the needed Fixes: tags, asking how this omission could
be repaired after the fact.
Johan Herland
agreed that additional mechanisms were required, suggesting
git notes while acknowledging its shortcomings.