[PATCH 1 of 1] Enable commit to disallow recursive submodule commits

[Matt Mackall]

On Wed, 2010-04-21 at 21:02 -0500, Michael Ekstrand wrote:
> # HG changeset patch
> # User Michael Ekstrand <michael at elehack.net>
> # Date 1271900106 18000
> # Node ID 64e512e0de2d91c6d7dc1975992ccb4b6f0ec46b
> # Parent  3213e8947975d7a8b44f6a11d063eb949fcb6bb5
> Enable commit to disallow recursive submodule commits
> 
> This patch adds support to commit for a 'commit.recursive' option, defaulting
> to true, which controls whether or not commit recursively commits submodules.

Sorry, I don't like this.

Recursive commit is just how Mercurial works, with or without subrepos.
You should be no more suprised when Mercurial commits files in a
subdirectory than when it commits a subrepo. Commits are by design
snapshots of an entire project state, and that definitely includes
subrepo state. Adding a (misnamed) flag to grossly change Mercurial's
philosophy is not appealing. Also, it'd need to be turned off in plain
mode for GUI integration, and that'd make it pretty much pointless. Nor
am I much interested in command line options, etc.

Now I understand that there is currently no easy way to know when a
subrepo is dirty, and there's probably no warning in the commit editor
that you're about to commit subrepos, and so most people are in fact
surprised. But that's not because of the recursion, it's because we're
simply not reporting it yet.

Let's focus on that instead. For starters, we need hg summary to tell us
about dirty subrepos (easy). And for commit to warn us about subrepos
it's committing (also easy). Then we need to figure out how to report
subrepos in status in a way that doesn't confuse all the GUI tools that
use it. That's a bit harder.

-- 
http://selenic.com : development and support for Mercurial and Linux