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 _______________________________________________ Evolve-testers mailing list [email protected] https://www.mercurial-scm.org/mailman/listinfo/evolve-testers
