Re: rebase -p loses amended changes

From: Thomas Rast <trast@student.ethz.ch>
Date: Mar 31, 2012, 09:35 UTC
Message-ID: <87fwcpun95.fsf@thomas.inf.ethz.ch>
In-Reply-To: <CAH3Anrqorf481jw6GdHqOPg9WC0rD-OraOHZ7twWRF4+oJ9X4A@mail.gmail.com>

Jon Seymour <jon.seymour@gmail.com> writes:

Show 14 quoted lines

> On Sat, Mar 31, 2012 at 9:49 AM, Thomas Rast <trast@student.ethz.ch> wrote:
>> J Robert Ray <jrobertray@gmail.com> writes:
>>
>>> If a merge is amended to add changes to a file unaffected by the
>>> merge, these changes are lost after a rebase. Attached is a script to
>>> demonstrate the problem.
>>
>> That's pretty much expected. rebase -p attempts to (conflicts will
>> happen again) replay the merge.  I don't think anybody's come up with a
>> clear idea of how to apply the conflicted or evil parts of the merge
>> mechanically.
>
> 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.

> If not, perhaps git could be a little bit noisy about the circumstance
> at the point of the --amend commit?

That could still be done of course.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch