[PATCH 1 of 1] subrepo: check for dirty warns on missing revision instead of abort
mpm at selenic.com
Fri May 13 11:49:47 CDT 2011
On Fri, 2011-05-13 at 14:43 +0200, Friedrich Kastner-Masilko wrote:
> Zitat von Matt Mackall <mpm at selenic.com>:
> > This patch seems unnecessarily complex. Does this do what you want?
> > diff -r 9bbac962f4dd mercurial/subrepo.py
> > --- a/mercurial/subrepo.py Thu May 12 20:27:35 2011 +0200
> > +++ b/mercurial/subrepo.py Thu May 12 18:27:46 2011 -0500
> > @@ -408,7 +408,7 @@
> > if r == '' and not ignoreupdate: # no state recorded
> > return True
> > w = self._repo[None]
> > - if w.p1() != self._repo[r] and not ignoreupdate:
> > + if r != w.p1().node() and not ignoreupdate:
> > # different version checked out
> > return True
> > return w.dirty() # working directory changed
> Hm. While it certainly looks much more elegant, it is not the same
> behaviour. The problem I have with this is the lack of warning on "hg
> With my patch, doing an "hg up" after the subrepo stripping will
> result in a warning, telling the user that something is wrong. Your
> patch is not showing this warning, it just quietly updates the
> superrepo to the specified revision.
> IMO this is bad in situations like so:
> @ 3: content C, subrepo-hash B
> o 2: content B, subrepo-hash B
> o 1: content A, subrepo-hash A
> Let's say the user is at 3, like depicted above. If he now strips away
> hash B in the subrepo, a "hg up 2" will bring his superrepo to parent
> 2, but will not inform him of the missing states in the subrepo with
> your patch. If the user now does a "hg st", he will get the warning,
> although the previous update succeeded.
Ok, I've tweaked my test to change up -C to plain old up. And indeed,
the subrepo is not updated.
This is correct behavior. It is exactly analogous to how update works
without subrepos. If you have a dirty file (or subdirectory) and you
update, you don't get a warning or an abort, your changes get carried
along with the update. From 'hg help update':
The following rules apply when the working directory contains uncommitted
1. If neither -c/--check nor -C/--clean is specified, and if the requested
changeset is an ancestor or descendant of the working directory's
parent, the uncommitted changes are merged into the requested changeset
and the merged result is left uncommitted.
The wisdom of this behavior (inherited from CVS) is perhaps
questionable, but it's definitely not something we'll consider changing
at this late date.
Mathematics is the supreme nostalgia of our time.
More information about the Mercurial-devel