[PATCH] localrepo: abort commit if a subrepo is modified and ui.commitsubs=no

[Aaron Cohen]

On Sun, Feb 13, 2011 at 9:09 PM, Mads Kiilerich <mads at kiilerich.com> wrote:
> Patrick Mezard wrote, On 02/12/2011 06:00 PM:
>
> But do this setting really belong as a config setting? It is a setting that
> all users of a given subrepo should agree on, so it seems like it would be
> better to store it for example in .hgsub .
>
>
> Actually I like this setting so much that I would like to have it set to
> False by default.
>
> I still haven't seen any good subrepo use cases where recursive commit was
> an advantage. I can only see the benefit of recursive commit (and
> "invisible" subrepos in general) if subrepos are used as bad workarounds for
> the lack of narrow and shallow clones in Mercurial. I hope we eventually
> will get a real and good solution to the need for flexible cloning and don't
> have to optimize subrepos for that use case.


Hmm, we've just converted our subversion repo which was the dreaded
"lots-of-projects-in-one-repo" into a basically empty top-level hg
repo with tons of subrepos. Our typical use-case is to commit in the
top level on commits that cross multiple project.

In particular, if you don't commit on the top level, you run into an
inconvenience of subrepos not being pulled until .hgsubstate changes:

Inconvenient scenario:
1) Work on subrepo1 on desktop machine
2) At the end of the day, run hg pull --update on your laptop at the
toplevel attempting to get your work
3) Go home, realize your subrepo1 commits aren't available because the
toplevel wasn't commited and you don't have access to your repo
anymore

I will admit, it is kind of disconcerting that hg status requires a
-S, so hg commit will do more work than hg status claims by default.

Another problem we just ran into with recursive commit, is that
"--newbranch" doesn't seem to be preserved in the recursive commit
invocations. We're trying to decide whether we consider that a problem
or not still.

So, in the end that's kind of a rambling statement, but we do like
using commit recursively at the top level on cross-cutting commits,
and it provides some good comfort at the end of the day when we're
getting ready to unplug and go home.

--Aaron