'hg prune --pair -s' updates to "strange" rev
Pierre-Yves David
pierre-yves.david at ens-lyon.org
Wed May 15 16:53:01 UTC 2019
On 5/15/19 4:56 PM, Josef 'Jeff' Sipek wrote:
> I have a repo I use hg-git and evolve (30a544904) on. Today, one of the
> other team members rebased my work-in-progress commits against the latest
> master - in the git repo. After the usual pull+phase+pull+prune dance, I
> ended up with the right DAG *shape* but the wdir and bookmark ended up in a
> "strange" place.
>
> While writing up this email, I have concluded that the prune command doesn't
> do any special handling of wdir and bookmarks when invoked with -s.
If in remember correctly, it should. (but the code is old, so memory can
be faultly)
> I'd argue that if one runs 'hg prune -s' and the wdir is in the pruned
> revset or there are any bookmarks in the pruned revset, then prune should
> move them to the corresponding successor. As I found out earlier today, it
> seems to move them to the first non-pruned ancestor. (Which is a fine
> behavior when -s is *not* specified.)
>
> Am I missing something? Am I misusing 'hg prune -s'?
The logic might be confused. Do you have a simple test case we could
look at ?
> Details about the scenario I encountered earlier today:
>
> I started with a graph of 16 drafts commits (let's call them P:A) on top of
> a long history of public commits (which are part of the master branch in
> git). 15 of those (P:B) have been pushed to a git feature branch. To make
> hg-git happy, here is a feature-branch bookmark on B and a master bookmark
> on the first public commit.
>
> The team member rebased the 15 pushed commits on top of the latest master
> commit (in git) introducing two commits in the feature branch.
>
> My wdir was at B (05ab114ca563).
>
> To update my repo, I did:
>
> $ hg pull gitrepo -r master
> $ hg phase -p master # master is immutable
> $ hg pull gitrepo -r feature-branch # the rebased commits
> $ hg prune --pair -s 7222519f38d0::a459b186772a 0ee48713972a::05ab114ca563
> 13 files updated, 0 files merged, 9 files removed, 0 files unresolved
> working directory is now at c5b05fa5cff4
> 15 changesets pruned
> 1 new orphan changesets
>
> (0ee48713972a::05ab114ca563 == P::B, 7222519f38d0::a459b186772a == P'::B')
>
> At this point I got the right DAG shape, but the wdir and the feature-branch
> bookmark ended up in the wrong place:
>
> o B'
> |
> o C'
> .
> .
> o P'
> |
> o 035fe56e3cfd new master commit 1 <master hg-git bookmark> (public)
> |
> o b9cdcb1fd054 new master commit 2
> .
> .
> | o A
> | |
> | x B
> . .
> . .
> | x P
> |/
> @ c5b05fa5cff4 old master commit 1 <feature-branch hg-git bookmark> (public)
> .
> .
>
> I would expect the wdir and feature-branch bookmark to move to the
> corresponding successor (a459b186772a aka B'), not to the first non-pruned
> ancestor (c5b05fa5cff4).
Your expectation are find. This looks like a bug. Can you report it on
bz.mercurial-scm.org (ideally with a repro).
--
Pierre-Yves David
More information about the Evolve-testers
mailing list