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

Martin Geisler mg at aragost.com
Mon Oct 24 02:34:18 CDT 2011

Jason Harris <jason at jasonfharris.com> writes:

> On Oct 22, 2011, at 4:18 PM, Martin Geisler wrote:
>>> 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.
> That's the problem. I want it to be a non-normal commit.

Okay -- so you want to 'hg commit --exclude sub' for all the subrepos.
That's how you can avoid updating the .hgsubstate file for a given
subrepo today and it matches how you exclude normal file changes.

Like Matt says, this will lead to commits that contain untested code,
just like when you do a partial commit with 'hg commit foo'. But if you
find yourself doing this often, then it should be simple enough to write
an extension that will let you do 'hg commit --exclude-subrepos'.

> Eg the normal workflow we want is people pull some repository and sub
> repositories. Then they work on these repos like normal. Ie they
> rebase stuff, moving things around as the develop some changes, etc.
> like they normally would. They then want to tie the revisions together
> at that one place when they know that it is coherent to do so, and
> then push.
> WIthout such an option it would be possible to Eg: commit a subrepo,
> then commit the parent repo. Do a rebase / strip in the sub repo. Do
> more work in the subrepo. Commit the subrepo. Do some work in the
> parent commit that. etc. And try and push that. And well they have
> pushed a nuked repo that does not have integrity since one of the
> substrates pointed to by the parent doesn't exist.
> Ie it's more common to do rebasing and moving things around in the
> various repo's and only require tying together of the repo's even so
> often. (since they are subrepo's...)

I see -- but why do people make these top-level commits then? If they're
stripping and rebasing in the subrepos, then they're far into
advanced-workflow-land and should know better than to do top-level
commits with dangling .hgsubstate pointers.

> This is basically the same as having the overarching thin repository
> and doing a commit there. Ie with the thin overarching super repo, the
> user can control when to tie the repo revisions together.

Ah, so you have significant files in the top-level repo that you want to
commit as well? That's just not going to work with current strip/rebase.

>>> Also is there a command to check the integrity of the repo
>>> .hgsubstate to confirm that all the subrepo revisions actually
>>> exist.
>> 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'.
> I didn't think I had missed something like this but wanted to check.

Okay, fair enough! I just figured that a guy like you that read the
devel list and can read the source should be able to notice such a
command by himself.

> It could be buried or accessed through some debug xyz or something. It
> seems like a fairly important command to verify the integrity of a
> repo with subrepo's.

I fully agree -- verifying subrepos would be an appropriate thing for
verify to do.

Martin Geisler

aragost Trifork
Professional Mercurial support

More information about the Mercurial-devel mailing list