Merging dirty subrepos into target revision on update

Matt Mackall mpm at selenic.com
Tue Dec 14 15:28:27 CST 2010


On Tue, 2010-12-14 at 15:14 +0100, Martin Geisler wrote:
> Hello,
> 
> My client has asked me to fix an issue with updates to dirty subrepos.
> Imagine a main repo and a subrepo where three changesets are paired like
> this:
> 
>   m0 --> s0
>   m1 --> s1
>   m2 --> s2
> 
> So the main and subrepo went in lock step.
> 
> Mercurial currently behaves like this when you do 'hg update m2':
> 
>   (m1, s1) --> (m2, s2)
> 
> This is all fine. However, if the subrepo is updated to a differnet
> version, then we get the same result:
> 
>   (m1, s0) --> (m2', s2)
> 
> Actually, the m2' state has a dirty .hgsubstate file, namely the one
> containing s1 from m1. This is the cause of
> 
>   http://mercurial.selenic.com/bts/issue2403
> 
> Where a subsequent commit will make an empty commit in the main repo
> because it is tricked by the "dirty" .hgsubstate file.
> 
> However, my client doesn't care about that -- they are more interested
> in keeping the subrepo as-is. In particular, if the history was
> 
>   m0 --> s0
>   m1 --> s0
>   m2 --> s1
>   m3 --> s1
>   m4 --> s1
>   m5 --> s1
> 
> then they expect 'hg update m5' to do
> 
>   (m3, s0) --> (m5, s0)

This seems correct.

> where the subrepo is kept in its dirty state. This is consistent with
> how we merge other dirty files into the target revision when updating.
> One would need a 'hg update -C m5' to make the transition
> 
>   (m3, s0) --> (m5, s1)

Also good.


-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list