On 06/03/2018 12:45, Sergey Organov wrote: > > > > 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.
Just to say I agree with this, `if U1' == U2' then proceed else stop` seems as a good sanity check.
