lothiraldan added a comment.

  In https://phab.mercurial-scm.org/D1082#18693, @quark wrote:
  
  > 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.
  
  
  Yes agreed, sorry if I was not clear, I think it's a good behavior for most 
users.
  
  > 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.
  
  I'm still concerned about possible obsmarkers explosion as we move to more 
and more auto-stabilizing commands in core. For leaving a trace of the problem, 
if we use auto-stabilizing commands on every changeset on the stack (rewrite 
the first changeset, all parent get stabilized, rewrite the second changeset, 
all parents get stabilized, etc..), we will end up creating N²/2 obsmarkers 
with a stack of N:
  
    stack of 4 changeset: 8 obs-markers,
    stack of 10 changesets: 50 obs-markers,
    stack of 30 changesets: 450 obs-markers,
  
  I'm not saying that everyone has a 30 changesets stack but even with a small 
stack going back and forth in the stack while making editions would rapidly 
grow the number of obsmarkers created which will cause scalability issues when 
exchanging markers.
  
  There is a couple of interesting lead to solve this, maybe we could do 
something special when more than X (configurable) obs-markers are created. 
Probably avoid the stabilization and point to some documentation or commands 
(like restack).

REPOSITORY
  rHG Mercurial

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

To: quark, #hg-reviewers
Cc: lothiraldan, martinvonz, dlax, mercurial-devel
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Reply via email to