Jon Seymour <jon.seymour@xxxxxxxxx> writes:
> On Sat, Mar 31, 2012 at 9:49 AM, Thomas Rast <trast@xxxxxxxxxxxxxxx> wrote:
>> J Robert Ray <jrobertray@xxxxxxxxx> 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
--
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