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

[Jason Harris]

On Oct 24, 2011, at 2:34 AM, Martin Geisler wrote:

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

Exactly! But this is standard behavior. Many many hg users do this *all* the
time. Hunk level commits and so on (which is a big requested feature for MacHg),
the record extension etc. is for exactly this kind of manipulation but
intensified even more so. Some people think this is the boogy man. But I think
that opinion is just plain foolish. Partial / selective commits are incredibly
useful and allow one to group commits into coherent changesets. Moreover the
consequence of a stuff up is just part of normal development, eg let's say I
miss committing something that was critical to the functioning I was testing,
then the consequence is likely to be exactly the same as some normal bug which
occurred as part of the standard development progress in the first place. Ie the
consequences of missing committing something is just the normal standard
consequences of having bugs in ones code... And well people in development deal
with this all the time.)


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

It leads to "loose coupling" between the parent repo and the sub-repos. This is
*exactly* isomorphic to the recommended practices on the wiki. (ie having a thin
super repo which couples the subrepo's.)

Right so my original question was i, "Is there an option to control this?" Your
answer is thus basically "Sorry, there is no option to control this at this
time. Nor is one planned at this time."

Hmmm... I might look into this then... What would be a good extension name here?
hgloosesubrepos? hgthinsubrepos? Any other suggestions from the cheap-seats? :)


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

Because mistakes happen and our developers (who are not Mercurial guru's)  have
nuked our repo a number of times doing this.  Normally rebasing is really really
safe. (I can't remember the last time I have nuked a repo by a rebase.) However,
our parent repo has been nuked a number of times now...


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

Sure, I can, but really it is nice to at least ask the question on the developer
lists.  First of all, this raises the whole discussion and now you (and possibly
others) see a viewpoint that you hadn't originally thought about.  Second,
people might say, ohh I have this or that extension / script / snippet which you
might find useful.  Thirdly, you or the other main sup-repo people might say,
ohh yeah I had thought about that but now that you asked about it I'll go ahead
and add that, or expose this or that, etc.

(Or at least I do this all the time with MacHg, Eg if I have some feature I have
been thinking about at the back of my mind and several people ask me for it (or
ask for something which in essence is equivalent or a specific case of what I am
thinking about), I will generally add it, if it doesn't contravene stuff...)

I think the barrier to asking a question should be a quick google search, look
around at some documentation and then ask the question... / raise the discussion
point.

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

Cool.

(Thanks for your responses Martin & Matt... :) )

Thanks,
   Jas