D1082: split: new extension to split changesets

quark (Jun Wu) phabricator at mercurial-scm.org
Mon Oct 16 14:54:13 EDT 2017


quark added a comment.


  In https://phab.mercurial-scm.org/D1082#18648, @lothiraldan wrote:
  
  > It will be great to have split in core, even if it's only as an experimental experiment for now.
  >
  > I like the UX improvements, but could we add a config knob to disable the auto-rebase for power-users? I agree that generating orphans is maybe not the best UX for users, so I think having it on by default could be an improvement.
  
  
  I believe most users want auto-rebase by default. Auto-rebase is the default at FB for months and people like it.
  
  I agree power users may want a different default. In that case, you can set alias `split = split --no-rebase`.
  
  > But, I often am in the middle of a too big stack and auto-rebasing would break my flow of fixing commits from bottom to top without mentioning the number of obs-markers it would generate.

INLINE COMMENTS

> martinvonz wrote in test-split.t:487-493
> Leaving these two behind seems reasonable. It would also be reasonable to evolve/stabilize them. Either way, it's different from what "hg rebase" does. Do we eventually want them to behave the same? If so, are we okay with a small BC break here (either in split or in rebase)?

I don't understand why you think "it's different from what "hg rebase" does". The `--rebase` flag does not suggest what rebase source or destination it uses. So it's up to the `split` implementation to do a reasonable thing. It can do `-r SMART_REVSET -d ...` instead of `-s SINGLE_REV -d ...`. I can revise the help text to clarify.

I think we wanted to implement "Option 2 (skip troublemakers)" as the default behavior in https://www.mercurial-scm.org/wiki/CEDRebase according to previous sprint discussion. That said, I don't think that should block this patch.

REPOSITORY
  rHG Mercurial

REVISION DETAIL
  https://phab.mercurial-scm.org/D1082

To: quark, #hg-reviewers
Cc: lothiraldan, martinvonz, dlax, mercurial-devel


More information about the Mercurial-devel mailing list