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

Martin Geisler mg at lazybytes.net
Sat Oct 22 16:18:26 CDT 2011


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 of 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.

> It turns out for us that most of the time changes in the super-repo
> and changes in the sub-repo are independent (Which should be the case
> as long as you are not changing the API of whatever is contained in
> the subrepo's.)

So then the new behavior should work well for you: if you accidentally
commit at the top-level, you'll get an abort. You can then go into the
subrepos and commit them with a proper commit message.

> And so every so often we need to tie together the super-repo and
> sub-repo revisions. At that time it would be nice to do a special
> commit which updates the .hgsubstate.

That is just a normal commit in the super-repo.

> (Unfortunately we didn't set things up originally with a thin wrapper
> super repository and all sub repositories at the main level. If we
> had, then of course we could have controlled the tying together by
> only committing the wrapper super repository whenever we needed to.)
>
> Also is there a command to check the integrity of the repo .hgsubstate
> to confirm that all the subrepo revisions actually exist. Sort of like
> a "hg verify --subrepos" ? Ie if a user does a rebase in a subrepo and
> the version in .hgsubstate no longer exists then we can get a warning
> about it?

Ehm, no -- you would have heard of such a command by now if it existed
and it would be mentioned in 'hg help subrepos' and/or 'hg help verify'.

-- 
Martin Geisler

Mercurial links: http://mercurial.ch/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20111022/8a0417b2/attachment.pgp>


More information about the Mercurial-devel mailing list