On Sat, Mar 31, 2012 at 2:39 AM, Jon Seymour <jon.seymour@xxxxxxxxx> wrote: > On Sat, Mar 31, 2012 at 8:35 PM, Thomas Rast <trast@xxxxxxxxxxxxxxx> wrote: >> Jon Seymour <jon.seymour@xxxxxxxxx> writes: >> >>> On Sat, Mar 31, 2012 at 9:49 AM, Thomas Rast <trast@xxxxxxxxxxxxxxx> wrote: >>> >>> I wonder if there are any really good justifications for changing the >>> content, as distinct from the comments of a merge during an amendment? >> >> Semantic conflicts do not necessarily show up as >> conflicts-to-be-resolved. The canonical example is when you change the >> signature of a function on one side of the merge, and introduce new >> callers on the other side. The merge must then patch all new callers >> too. > > Fair enough - I was thinking that you could these with a commit after > the merge, but I can see that's not the right thing to do, from a > correctness point of view. I thought there would be more concern about the silent data loss. Instead of throwing away the amended changes I would prefer the rebase to at least fail, if not have the problem require manual conflict resolution. A warning at the time of the amend could confuse or scare users. But a mention of this problem in the rebase docs would help. -- 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