On Fri, Jan 08, 2016 at 12:09:45PM -0800, Junio C Hamano wrote: > > So the question is, is this the behavior this should have? > > The behaviour is a natural consequence of what graft and replace are > about (i.e. "telling Git what the parents of a commit are" vs > "telling Git what the contents of a commit are"), so the answer to > the "should" question is a resounding "yes". It's not only about contents, except for a very broad definition of contents that includes ancestry. From my POV, replace is more about "telling Git that this commit (and its parents) is really that one (and its parents)". Anyways, the dummy example is using different commit messages, and notes everywhere, to make what happens to commits and notes obvious. In the real world, "first" would be "real third", so the commit messages would be as expected in all cases. The question is whether users expect the note of the non-replaced commit to show up. Would they expect no note at all in the case there is a note on the replacee, but not on the replaced? Maybe the right thing to do would be for *both* notes to be concatenated? I don't know. Mike -- 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