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.

  rHG Mercurial



To: rdamazio, #hg-reviewers
Cc: mharbison72, martinvonz, pulkit, quark, mercurial-devel

More information about the Mercurial-devel mailing list