Rebase commit is not created if it was previously created then pruned

Anton Shestakov av6 at dwimlabs.net
Thu Jul 22 18:57:30 UTC 2021


On Wed, 21 Jul 2021 16:41:56 -0400
Christopher Speck <die.drachen at gmail.com> wrote:

> I originally posted this in the Mercurial mailing list but found there’s a separate one for Evolve.
> 
> I’ve come across an issue while using the evolve extension where running a `rebase` command unexpectedly does not result in a new commit. I’m able to reproduce this in a new repository.
> 
> Mercurial: 5.8.1
> Evolve: a65d17b1b463 (stable branch from evolve repo)
> 
> The setup involved looks generally like this:
> 
> 1. Run `hg rebase —dest master —rev a:b —collapse —keep`
> 2. Prune the resulting rebased/squashed commit
> 3. Re-run the same rebase command
> 
> The result from running the rebase command again is that no new rebased commit is created. Most users will probably not run these commands themselves however I’m working with a tool that is not able to determine whether the rebase command that it’s running was run previously and pruned.

Yes, running rebase multiple times is expected to give identical results
(at least with --collapse). So a rebase of the same commits as
previously, in the same environment, would create a changeset with the
same hash, but it won't be written to storage if that changeset already
exists locally (hg assumes same hash means same content, same position
in the DAG, same metadata). So if you prune this changeset, then the
obsolescence marker is going to hide the result of the first rebase,
and consecutive rebases won't add anything new to the repo.

I assume your tool doesn't want a status message at the end of running a
rebase, so what do you propose?

Also, mind that checking if there's one more commit in the repo (hidden
or not) after a rebase is not going to be 100% guarantee that "rebase
succeeded". For example, someone may pull from your clone the
obsolescence marker that prunes this rebase result, but they won't get
the changeset itself because it's hidden. Then they can run the rebase
--collapse the same way that you did and it'll result in a new
changeset (with the same hash as you have) in their clone, and this
changeset will be hidden because of the obsmarker that they got by
pulling.

A workaround for this might be to add random noise to extras (or the
commit message) so that the hash changes with every rebase call. Not
sure if it works for your use case.



More information about the Evolve-testers mailing list