From: J Robert Ray Date: Tue, 03 Apr 2012 18:55:26 GMT Subject: Re: rebase -p loses amended changes Message-ID: In-Reply-To: On Sat, Mar 31, 2012 at 2:39 AM, Jon Seymour wrote: > On Sat, Mar 31, 2012 at 8:35 PM, Thomas Rast wrote: >> Jon Seymour writes: >> >>> On Sat, Mar 31, 2012 at 9:49 AM, Thomas Rast 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.