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

[Angel Ezquerra]

On Fri, Oct 21, 2011 at 9:53 AM, Martin Geisler <mg at aragost.com> wrote:
> Angel Ezquerra <angel.ezquerra at gmail.com> writes:
>
>> On Fri, Oct 21, 2011 at 12:33 AM, Martin Geisler <mg at lazybytes.net> wrote:
>>> # HG changeset patch
>>> # User Martin Geisler <mg at lazybytes.net>
>>> # Date 1319149988 -7200
>>> # Branch stable
>>> # Node ID 8c3a6c9007041b90ec7ed7dc8c77d95e5185acb6
>>> # Parent  1ae824142c0157f350e1e01cf3e23fbf01a1f722
>>> subrepos: abort commit by default if a subrepo is dirty
>>>
>>> This changeset flips the default value of ui.commitsubrepos setting
>>> from True to False and adds a --subrepos flag to commit.
>>>
>>> The commit, status, and diff commands behave like this with regard to
>>> recusion and the ui.commitsubrepos setting:
>>>
>>>          | recurses      | recurses
>>>          | by default    | with --subrepos
>>>  --------+---------------+----------------
>>>  commit: | commitsubrepo | True
>>>  status: | False         | True
>>>  diff:   | False         | True
>>>
>>> By changing the default from True to False, the table becomes
>>> consistent in the two columns:
>>>
>>> * without --subrepos on the command line, commit will abort if a
>>>  subrepo is dirty and status/diff wont show changes inside subrepos.
>>>
>>> * with --subrepos, all three commands will recurse.
>>>
>>> A --subrepos flag on the command line overrides the config settin.g
>>
>> 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.

Cheers,

Angel