Re: rebase -p loses amended changes
- From
- J Robert Ray <jrobertray@gmail.com>
- Date
- Apr 3, 2012, 18:55 UTC
- Message-ID
- <CADb3U=4Y0njLiYC1qrYbdm+h0h8vLh78yfz_u3B6veEqCX0xCQ@mail.gmail.com>
- In-Reply-To
- <CAH3AnrpasFU2bLEZsAXRQu4U+=R_YyW+-yRXDfzy2JQpqf9dNw@mail.gmail.com>
On Sat, Mar 31, 2012 at 2:39 AM, Jon Seymour <jon.seymour@gmail.com> wrote:
Show 17 quoted lines
> On Sat, Mar 31, 2012 at 8:35 PM, Thomas Rast <trast@student.ethz.ch> wrote: >> Jon Seymour <jon.seymour@gmail.com> writes: >> >>> On Sat, Mar 31, 2012 at 9:49 AM, Thomas Rast <trast@student.ethz.ch> 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.