'hg prune --pair -s' updates to "strange" rev

Josef 'Jeff' Sipek jeffpc at josefsipek.net
Wed May 15 14:56:05 UTC 2019


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.

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'?


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).

Thanks,

Jeff.

-- 
Bad pun of the week: The formula 1 control computer suffered from a race
condition


More information about the Evolve-testers mailing list