D7631: absorb: allowing committed changes to be absorbed into their ancestors
rdamazio (Rodrigo Damazio Bovendorp)
phabricator at mercurial-scm.org
Mon Jan 6 19:46:49 EST 2020
rdamazio added a comment.
In D7631#114393 <https://phab.mercurial-scm.org/D7631#114393>, @mharbison72 wrote:
> In D7631#112604 <https://phab.mercurial-scm.org/D7631#112604>, @rdamazio wrote:
>> In D7631#112414 <https://phab.mercurial-scm.org/D7631#112414>, @quark wrote:
>>> `--rev` seems ambiguous since there might be different kinds of revisions to specify - target and revisions to edit. Maybe something like `--source`, `--from`, `--target`?
>> Done. Used `--source` to match `rebase`.
> Is `--exact` from `hg fold` a better model? I don't feel strongly; I only mention it because `hg rebase -s` will take that revision and its descendants, so it's more like "stack" in my mind. I'm not sure how many other commands have `-s` off the top of my head, but @martinvonz
> mentioned adding that to `hg fix` (probably in IRC), and I think mentioned the word "stack" in that context. So I might not be the only one to get slightly tripped up by that.
IMHO no, needing `--exact` is actually confusing to almost every user we've talked to, and they'd instead expect that to be the default behavior, with "fold up to this commit" being the one that needs a specific flag.
>> I'm assuming no fundamental objections then? Removing the "RFC" part so it gets a proper review then.
> I like it.
> mharbison72 wrote in absorb.py:1141
> Should it abort if multiple revisions are given, instead of picking the latest?
I suspect other places may want something similar (e.g. it'd make sense in `rebase --dest`, so I changed revsingle to add the behavior.
CHANGES SINCE LAST ACTION
To: rdamazio, #hg-reviewers
Cc: mharbison72, martinvonz, pulkit, quark, mercurial-devel
More information about the Mercurial-devel