durin42 added a comment.
In https://phab.mercurial-scm.org/D1047#17714, @quark wrote: > In https://phab.mercurial-scm.org/D1047#17692, @durin42 wrote: > > > Counterproposal: > > > > `hg rebase --auto <REVSET>` > > > > or > > > > `hg rebase --auto -r <REVSET>` > > > > rather than introducing a new concept of a stack. I know Facebook has this concept internally, but for core hg we don't have the notion of a stack outside `mq` and `show`: the former is heavily deprecated, and the latter is experimental and still subject to change. Also, I feel like 'automatic rebase' is a pretty good description of what's actually happening to resolve the trivial orphans-only trouble cases. Thoughts? > > > > I'd be happy to spend a bit of time writing up a commit for rebase--auto if people want to play with it. > > > I'm unconvinced that `--auto` should be bound to the concept of stabilization. I think it should be made more flexible. ex. some users may ask "why --auto does not rebase my commits to master"? That's a good point. In a perfect world you'd do something like "rebase to my successor, unless my successor is an ancestor of the otherwise-default-destination, in which case rebase to there." > Currently, rebase has a non-configurable `_destrebase` revset that is used when `-d` is not specified. It's basically useless. And we even have `commands.rebase.requiredest` to disable it. > > I think we can have proper ways to make it possible that the "default" behavior is useful and does the "--auto" thing, while still being flexible. > > What I'm thinking about is a config section like: > > [revsetalias:rebase.dest] # revsetalias that is only used in rebase destination scope > auto = if(SRC is orphan and obsoleted,first(max((successors(max(roots(ALLSRC) & ::SRC)^)-obsolete())::)+max(::((roots(ALLSRC) & ::SRC)^)-obsolete())))) > # missing bit: express "ifempty(x, trueset, falseset)" in revset language I like where your head is at, but I think I'd probably do `[command] rebase.dest.auto` to be in line with our current direction on commands. The only concern I have is that this is pretty complicated to express in a revset, but if we can figure it out that's almost certainly the way to go... > Benefit: > > 1. Users can run `hg rebase -r 'draft()' -d auto`, which seems to be convenient enough. > 2. Sysadmins can override the config so it also works for rebasing to `master`. More flexible. > > In addition, we can have something like: > > [commands] # ignored by HGPLAIN rebase.defaultsrcdest = "not public()", auto # used when both src and dest are not provided rebase.defaultdest = auto # used when src is provided, but not dest rebase.defaultsrc = ("not public()" & ::.)+(.::) # used when src is not provided, but dest is provided > > Then users can just run `hg rebase` without arguments. Overall, I like the (configurable) `rebase --dest auto`, and I think that configurable destination shorthand(s) is meritorious even if it doesn't obviate an eventual `hg restack` or `hg stabilize` (though I think it does, at least for the basic case of having some non-divergent orphans, at least well enough we could start enabling more of the obsolete/rebase/histedit/amend stuff out of the box.) REPOSITORY rHG Mercurial REVISION DETAIL https://phab.mercurial-scm.org/D1047 To: quark, #hg-reviewers Cc: durin42, martinvonz, lothiraldan, dlax, mercurial-devel _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
