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