[PATCH] subrepos: abort commit by default if a subrepo is dirty

Matt Mackall mpm at selenic.com
Sat Oct 22 17:58:55 CDT 2011


On Sat, 2011-10-22 at 17:11 -0500, Jason Harris wrote:
> On Oct 22, 2011, at 4:18 PM, Martin Geisler wrote:
> 
> > Jason Harris <jason at jasonfharris.com> writes:
> > 
> >> On Oct 21, 2011, at 3:34 AM, Angel Ezquerra wrote:
> >> 
> >>> On Fri, Oct 21, 2011 at 9:53 AM, Martin Geisler <mg at aragost.com> wrote:
> >>>> Angel Ezquerra <angel.ezquerra at gmail.com> writes:
> >>>> 
> >>>>> This may be a dumb question, but will clean but modified subrepos
> >>>>> (i.e. those were the current revision has been changed) still be
> >>>>> committed when commitsubrepo is set to False?
> >>>> 
> >>>> That's actually a great question... The answer is that subrepos that
> >>>> have changed revision *will* be committed when commitsubrepos=False.
> >>>> 
> >>>> I must admit that I did not expect this, but now that I think about
> >>>> it, it seems nice: commitsubrepos=False prevents you from
> >>>> accidentally reusing a top-level commit message in subrepos. But
> >>>> you're still allowed to arrange the subrepos like you want (update
> >>>> to new versions) and then make a big top-level commit to bind
> >>>> everything together.
> >>>> 
> >>>> --
> >>>> Martin Geisler
> >>> 
> >>> I'm glad that is the case! In my opinion this is the right behavior.
> >>> The new behaviour is great because it avoids modifying the subrepos
> >>> (by creating _new_ commits, often with a nonsensical commit message)
> >>> unless you explicitly tell mercurial to do so.
> >>> 
> >>> But changing the subrepo revision does not modify the subrepo itself.
> >>> You are basically modifying the .hgsubstate file, which is part of the
> >>> parent repo.
> >>> 
> >>> So in my opinion this makes a lot of sense.
> >> 
> >> 
> >> Is there an option to control this? It would be really nice to turn
> >> this off in our workflow. If we could then people could still rebase in
> >> unpushed subrepo's etc, without nuking the repo by accident.
> > 
> > I'm not sure what you ask to control. There is indeed an (old) option to
> > control the recursive behavior of commit and there is a new --subrepos
> > flag that overrides the option to make commit recurse.
> 
> I want an option so that if the subrepos have been changed and committed then
> committing in the parent repo will *not* change the .hgsubstate.

This option is better known as "turn off version control fundamentals"
and has rather dim prospects.

If project X has subrepo Y that it's not actually tightly coupled to on
a revision by revision basis, then the right way to do it is to make Y a
sibling of X (with a new parent W) rather than a child:

 http://mercurial.selenic.com/wiki/Subrepository#Recommendations

-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list