Re: Using Origin hashes to improve rebase behavior

Jeff King [off-list ref] writes:

OK. That's certainly the conservative answer, and where we should start.
But I wonder in practice how many times we'll hit all the criteria just
right for this feature to kick in (i.e., a cherry pick or rebase with no
conflicts, followed by one that would cause a conflict). But I think
there's nothing to do but implement and see how it works.

After thinking about this a bit more, the whole idea of "is this
cherry-picked/rebased/whatever commit the same as the one before" is
really the same as the notes-rewriting case (i.e., copying notes on
commit A when it is rebased into A'). Which makes me excited about using
notes for this, because the rules that you do figure out to work in
practice will be good rules for notes rewriting in general.

quoted

The problem with an external annotation is that if developers are sharing
feature branches, as a branch maintainer I want to know whether commits coming
from those feature branches are already in the branch I'm maintaining.

In that case, I would suggest putting it in git-notes and sharing the
notes with each other. The notes code should happily merge them all
together, and then everyone gets to see everybody else's
cherry-pick/rebase annotations.

The more I've talked this over with my friend, the more we discover how
difficult this is to get right in certain situations, and also how rare the
actual use cases that require storage within the commit message are -- but at
the same time, how valuable that information is when those cases occur!

This may be a bit more than I can chew right now, so thank you for bringing to
my attention the depth of this problem.  That's exactly why I posted here
before beginning to punch out code that might solve just the naive cases. :)

Thanks, John