On Tue, Apr 3, 2012 at 5:43 PM, Jon Seymour <jon.seymour@xxxxxxxxx> wrote: > On Wed, Apr 4, 2012 at 4:55 AM, J Robert Ray <jrobertray@xxxxxxxxx> wrote: >> 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: > orrectness 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. > > It'd be quite expensive to attempt to detect cases where this might be > a problem, but let's articulate, as a thought experiment, what such a > solution might look like - I am not suggesting that it is a good idea, > but the thought experiment might be illustrative. > > Suppose you have a merge of a A and B that produces M, which is then > amended as M'. > > During rebase, you redo the merge A and B. If there are no conflicts, > then compare M with M' to produce D. You now have enough information > to reproduce the amended commit M' during a rebase (merge Ar and,Br > then apply D). How does M' know it is an amended version of M? When you amended the commit M you threw away this linkage. If you created M' as a new commit D instead, then I would agree that you have enough information to do what you seek. In fact, I'm pretty sure git does this already. Phil -- 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