Dealing consistently with subrepositories

[Matt Mackall]

On Tue, 2011-04-05 at 15:13 +0200, Martin Geisler wrote:
> Matt Mackall <mpm at selenic.com> writes:
> 
> > On Tue, 2011-03-29 at 11:52 +0200, Martin Geisler wrote:
> >> Hi Olaf, hi Pradeepkumar, and hi everybody else
> >> 
> >> I talked with Olaf about making commands behave consistently with
> >> regards to subrepos. He works for my client and they are still
> >> somewhat unhappy with how everything plays together.
> >> 
> >> We tried to group the commands based on some invariants. Let us write
> >> 'foo <-> bar' if 'hg foo' should be recursive if and only iff 'hg
> >> bar' is also recursive -- it might make sense that none of them are
> >> recursive but they should agree with each other.
> >
> > I've earlier expressed a different rule:
> >
> >  status can't recurse by default until you can use the files it
> >  outputs with add, remove, commit, etc.
> >
> > This is what I'm calling 'transparency'.
> 
> Yes, that is a nice notion. But the 'transparency' rule is something I
> would use to argue that status must agree with add, remove, commit, etc.

If status shows me file sub/foo, then I should be able to add sub/foo.

Today we have third-party tools that assume this. If we change this
relationship, tools WILL break. This tells us we're breaking an implicit
contract with the user.

The converse is not true, because nothing tells a user or a tool that
foo/bar even exists. You can quietly make add accept sub/foo and nothing
will break.

It's not about IF status should be recursive, but WHEN. And the answer
is LAST. If you want to change all the commands at once, I guess that
satisfies my requirement, but doesn't strike me as good engineering.

Here's another way to think about transparency: status let's you 'see'
things, so you now expect to be able to 'touch' those things. But it's
not a symmetrical situation, as anyone who's been eaten by a grue can
attest.

-- 
Mathematics is the supreme nostalgia of our time.