This is an archive of the discontinued Mercurial Phabricator instance.

rebase: drop support for rebaseskipobsolete config
Needs RevisionPublic

Authored by martinvonz on Mar 25 2021, 7:35 PM.

Details

Reviewers
marmoute
Group Reviewers
hg-reviewers
Summary

hg rebase has been able to skip obsolete commits since 92409f8dff5d
(rebase: don't rebase obsolete commit whose successor is already
rebased, 2015-09-14). That commit introduced the
experimental.rebaseskipobsolete config and set it to false by
default to start with. Then it has been enabled by default since
a47881680402 (rebase: turn rebaseskipobsolete on by default,
2016-03-09).

It seems to me that all use cases for turning off the config are
covered by hg rebase --keep, hg graft, or hg touch. The use
cases I can think of are:

  1. Create a temporary copy of a set of commits for some experimentation (use hg rebase --keep or hg graft).
  2. Revive a pruned commit (use hg touch, possibly followed by hg rebase if you want to move it elsewhere).

Also, it is a config option after all, which means that it is not
intended for one-off hg rebase commands (then it would have been a
command-line flag). So, let's drop support for this config since it
seems unused. It will make my work on making rewriteutil.precheck()
check for divergence slightly simpler.

Diff Detail

Repository
rHG Mercurial
Branch
default
Lint
No Linters Available
Unit
No Unit Test Coverage

Event Timeline

martinvonz created this revision.Mar 25 2021, 7:35 PM

I am +1 on this. I remember there was a discussion on IRC around it but not sure what the end result of that was. @marmoute does having experimental.rebaseskipobsolete serves any purpose?

marmoute requested changes to this revision.Apr 8 2021, 1:15 PM

I am +1 on this. I remember there was a discussion on IRC around it but not sure what the end result of that was. @marmoute does having experimental.rebaseskipobsolete serves any purpose?

Ha yes, thanks for the ping. The short version of my opinion is that experience has shown over and over that having a way to says "select exactly what I requested without tempering with it" are useful. Therefore, we should not drop the flag currently allowing to do that without at least introducing another one.

Neither hg rebase is quite powerfull tool and neither rebase --keep, hg graft or hg touch (?) can really do the same thing. So they don't seem like proper alternative to a simple "do-what-I-said" config/flag.

This revision now requires changes to proceed.Apr 8 2021, 1:15 PM

I am +1 on this. I remember there was a discussion on IRC around it but not sure what the end result of that was. @marmoute does having experimental.rebaseskipobsolete serves any purpose?

Ha yes, thanks for the ping. The short version of my opinion is that experience has shown over and over that having a way to says "select exactly what I requested without tempering with it" are useful. Therefore, we should not drop the flag currently allowing to do that without at least introducing another one.
Neither hg rebase is quite powerfull tool and neither rebase --keep, hg graft or hg touch (?) can really do the same thing. So they don't seem like proper alternative to a simple "do-what-I-said" config/flag.

Probably we need a --exact or something similar which also does not skip commits which are already in destination and create empty commits for them too.