[PATCH] subrepo: avoids empty commit when .hgsubstate is dirty (issue2403)

Erik Zielke ez at aragost.com
Fri Dec 17 04:53:40 CST 2010


fre, 17 12 2010 kl. 11:18 +0100, skrev Mads Kiilerich: 
> On 12/17/2010 09:48 AM, Erik Zielke wrote:
> > fre, 17 12 2010 kl. 03:38 +0100, skrev Mads Kiilerich:
> >> Is that correct and intended?
> >>
> >
> > No, its not, should I just resend the patch with fixes or is the
> > procedure different when a patch is queued?
> 
> http://selenic.com/repo/hg/rev/f02d7a562a21 is now cut in stone and 
> hashes, so unless it is backed out we will need a patch on top of that.
> 

Okay. Should just have read up on how it was with the different
repositories.

> It seems to me like a proper fix requires some refactoring of the commit 
> function. We basically don't know the state of the outer repo before we 
> have done the recursive commit, so we have to do the recursive commit 
> before we can create the commit context (which we however use for the 
> recursive commit).
> 

So you think that it should just be backed out for now and then prevent
such empty commits somewhat differently, right?


Although something like the following will fix the issue you pointed
out:

                     for newstate in state:
                         if state[newstate][1] != pstate[newstate]:
                             changed = True
-                if changed:
-                    subrepo.writestate(self, state)
-                elif (changes[0] == ['.hgsubstate'] and changes[1] ==
[] and
+                subrepo.writestate(self, state)
+                if (not changed and changes[0] == ['.hgsubstate']
+                    and changes[1] == [] and
                      changes[2] == []):
                     return None

> IMHO that is yet another reason why commit shouldn't be recursive. Just 
> trying harder will however make that reason go away ;-)
> 
> /Mads




More information about the Mercurial-devel mailing list