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). What isn't clear to me, in this thought experiment, is how you might attempt to solve the case where there were syntactic (as opposed to semantic) conflicts between the merge of A and B originally. You have no idea, at that point, how the user originally resolved the conflicts to produce M, thus no idea how to calculate D or even if there was a non-trivial D. In this circumstance, you stop and warn the user about the merge conflict, but you have no good way (??) to warn them about the potential loss of the amendment, D, since at this point you have no clue whether there was such an amendment and you don't want to worry them about conditions that usually do not occur (amended merges, I would have thought, are quite rare). ??: does git rerere help at all, in this case, I wonder? Certainly, there is no harm, I think, adding a note to the documentation of --preserve-merges that states something like: --preserve-merges does not attempt to preserve the resolution of merge conflicts or the amendment of merge commits ???; any histories containing such changes cannot be reliably recreated by git rebase. ??? - except to the extent allowed by git rerere? jon. -- 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