On Wed, 21 Jul 2021 16:41:56 -0400 Christopher Speck <[email protected]> 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. _______________________________________________ Evolve-testers mailing list [email protected] https://www.mercurial-scm.org/mailman/listinfo/evolve-testers
