Dealing consistently with subrepositories

[Martin Geisler]

Matt Mackall <mpm at selenic.com> writes:

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

Yes, that is one half of what we mean by consistency.

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

Aha... I was indeed questioning *if* it should be made recursive at all.

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

Sure, I'm not talking about any order for the changes, I'm just trying
to figure out if we can make subrepos consistent at all, for example by
making some groups of commands non-recursive.

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

Hehe :) In this case with add and status, then I do feel that they
should be consistent: if I do

  hg add sub/dir/

then I do want the files under that directory to show up with

  hg status

afterwards. It is no good that add work and status doesn't -- maybe for
scripts, but I want to make it good for humans too :)

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://mercurial.aragost.com/kick-start/