'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