Hi Phillip, Phillip Wood <phillip.wood@xxxxxxxxxxxx> writes: > On 03/03/18 00:29, Igor Djordjevic wrote: >> Hi Phillip, [...] >> >> The only thing I wonder of here is how would we check if the >> "rebased" merge M' was "clean", or should we stop for user amendment? >> With that other approach Sergey described, we have U1'==U2' to test with. > > I think (though I haven't rigorously proved to myself) that in the > absence of conflicts this scheme has well defined semantics (the merges > can be commuted), so the result should be predicable from the users > point of view so maybe it could just offer an option to stop. Yes, hopefully it's predictable, but is it the intended one? We don't know, so there is still some level of uncertainty. When in doubt, I try to find similar cases. There are two I'm aware of: 1. "git merge" just commits the result when there are no conflicts. However, it supposedly has been run by the user just now, and thus user can amend what he gets. That's effectively a stop for amendment from our POV. 2. When rebasing, "rerere", when fires, stages the changes, and rebasing stops for amendment. For me "rerere" behavior is rather annoying (I've never in fact amended what it prepared), but I always assumed there are good reasons it behaves this way. Overall, to be consistent, it seems we do need to stop at U1' != U2', at least by default. Additional options could be supported then to specify user intentions, both on the command level and in the todo list, provided it proves to be useful. -- Sergey
