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 <[email protected]> wrote: > 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
