Dealing consistently with subrepositories

[Martin Geisler]

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.

This defines a number of equivalence classes and I think we came up with
(Olaf, please correct me if I'm wrong):

* outgoing <-> push

  It is normally the case that 'hg outgoing' shows what the next 'hg
  pull will do.

* incoming <-> pull

  While they need not necessarily mirror push and outgoing, incoming and
  pull should agree with each other.

* commit <-> status <-> diff

  I want to be able to see a preview of the next commit with the status
  command, and if a file is shown as modified by status, then it should
  also show up in diff (modulo permission changes).

* commit <-> update

  Should agree for consistency so that you get back what you commit.

* status <-> add <-> addremove

  It is normally so that 'hg add' changes all '?' to 'A' in status,
  similarly for 'hg addremove'.

* status <-> summary

  I think of 'hg summary' as a condensed version of 'hg status'.


Now, we want 'hg push' to recurse because of safety so that you don't
push a main repo that referes to a local changeset in a subrepo. So we
can group the commands like this:

* Must recurse: update!, commit!, status+, diff+, add+, addremove-,
  summary-, push!, outgoing+

* Could recurse: pull-, incoming+

* Should not recurse: ?

I marked commands with '!' if they recurse by default, with '+' if they
support --subrepos, and with '-' if they don't support --subrepos.

The idea is to add a setting like ui.consistent-subrepos that when
enabled makes all the commands behave like above. For some commands such
as status this just means that --subrepos becomes a default option. My
client would then enable that option in their system config so that
everybody sees a more consistent subrepo behavior.

What do people think of this grouping? Does it make sense or would you
group things differently?

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://aragost.com/en/services/mercurial/blog/