Dealing consistently with subrepositories
mpm at selenic.com
Wed Mar 30 09:02:15 CDT 2011
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'. A command is transparent to
subrepos when you can use it without awareness that subrepos exist. So
when I can transparently use add on sub/a, then it's ok for status to
transparently list sub/a.
There's a lot of middle ground between 'functional' and 'transparent',
but it's important to keep in mind that transparency is the end goal and
not paint ourselves into a corner. So for any proposed change, I'm
always going to want a story that explains how it gets us closer to
> 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.
I have no idea how you intend to give a consistent, easily read,
recursive version of any of incoming, outgoing, or log. And making this
'transparent' is quite a bit trickier.
> * 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'.
Well, not really.
> 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.
Haha, not a chance.
First, there's like a year's worth of work between the current behavior
and what you're aiming for. Second, you'll probably be continually
changing parts of the behavior across this year, so it'll in fact be
"highly inconsistent". Given that during this year, you'll probably be
telling anyone who will listen "oh, you'd better turn on this flag",
this will set up a lot of users for disappointment. And third, once we
reach the goal, we'll want it to be the default.
But I might let you name it ui.experimental-subrepo-behavior.
Mathematics is the supreme nostalgia of our time.
More information about the Mercurial-devel