Jeff King <peff@xxxxxxxx> 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. > >> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html