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

Christopher Speck die.drachen at gmail.com
Thu Aug 19 04:23:26 UTC 2021


Hello, thank you for the reply.

The tool I'm working on isn't getting tripped up by additional output but
is getting tripped up in that it's trying to identify the new rebased
commit. It's doing this by retrieving the changeset hash for tip after
running the rebase command. However in this scenario running rebase doesn't
result in any new visible changesets, leaving the tip marker unmoved.

The commit message cannot be modified to include additional noise for the
case I'm working on. I'm not familiar with extras, but that might be a way
to work around this. Does that require any further extension to be enabled
beyond evolve? I tried `hg help --keyword extras` and it indicates a
`commitextras` extension allows this.

Thanks

Christopher Speck

On Thu, Jul 22, 2021 at 2:57 PM Anton Shestakov <av6 at dwimlabs.net> wrote:

> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/evolve-testers/attachments/20210819/05854bc7/attachment.html>


More information about the Evolve-testers mailing list