martinvonz added inline comments. INLINE COMMENTS
> rebase.py:1115 > + # /| | # because it re-introduces obsoleted content. If we choose > + # A B D # A as merge base, it works as expected - C' may be empty. > + if all(b != nullrev for b in bases): And if there are more ancestors of B, will the "rebasing %d:%s may include unwanted changes" warning appear? Regardless, if B adds file B and the merge in C involves removing file B, then the total diff will be empty. Does that mean that C' will be empty? It should be reverting B', right? (The same thing applies if it's not a whole file that gets added/removed, of course.) I think I'd prefer to be conservative here and error out until we have a safe answer to these merges that won't risk resulting in surprising contents. In this particular case, the user can work around it by first rebasing "B+C" only (but that may be tricky to realize). > test-rebase-obsolete.t:1180 > + > EOS > + $ hg rebase -r A+B+D -d Z --config experimental.rebaseskipobsolete=0 > + rebasing 0:426bada5c675 "A" (A) Why do we want/need rebaseskipobsolete? I was expecting to see a test case like then one in the documentation you added i rebase.py. REPOSITORY rHG Mercurial REVISION DETAIL https://phab.mercurial-scm.org/D340 To: quark, #hg-reviewers Cc: martinvonz, mercurial-devel _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
