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

Martin Geisler mg at aragost.com
Fri Oct 21 02:53:37 CDT 2011

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

aragost Trifork
Professional Mercurial support

More information about the Mercurial-devel mailing list