Of the mail on this topic, I think Jeremy's has addressed most of the
interesting points. So here are my further thoughts:
On Thu, Oct 27, 2005 at 02:22:31PM -0700, Jeremy Fitzhardinge wrote:
> There's a good reason for defaulting to the top of the repo: there's no
> other pathname syntax to refer to it. If you want to find the status of
> '.', then 'hg status .' is an economical way to get the output you
> want. But at present, if you want to get the status of the whole repo
> regardless of your cwd, there's no clean way to do it; you have to
> determine the path to the top of the repo, and then do 'hg status' on
> it. Adding a new piece of pathname syntax for referring to the top of
> the repo doesn't seem like a good idea.
Ok, I like this point. The '.' approach is arguably the cleanest and
most flexible. People who don't like waiting for 'hg status' to stat
their whole tree can quickly learn to use '.'.
> Also, there's an inconsistency in hg's behaviour at the moment: 'hg
> commit' will commit everything in the whole repo, regardless of your
> cwd; 'hg commit .' will commit things in the current directory. I would
> argue that commit is right, and the other commands should operate similarly.
I tend to think commit is right too, mostly because tree-wide atomic
commits are central to what a 'changeset' is: grouping -all- relevant
file-level changes together. The system thus encourages checking in a
complete change. Making the rest of the system consistent with commit
is a decent argument.
> That said, this kind of UI change is annoying to do; changing the
> behaviour will bite people (unless everyone agrees that the change is an
> unalloyed improvement). I'm not a fan of config or command line
> options, but this seems like the sort of user preference which needs one.
Actually, it's exactly the sort of user preference which causes things
to break unexpectedly. And thus it's best avoided. I'd rather have hg
bite everyone one more time by making the change while we're pre-1.0
than have people get repeatedly bit by a config option going forward.
> CVS always works from '.', but that's because there's no real notion of
> the "top" of a CVS tree; CVS effectively works on a directory by
> directory basis. SVN copies CVS's behaviour, I think for the same
> reason. It seems that most of the SCMs which have a notion of a top
> working directory will use that directory as the default.
Also a good argument. Mercurial fundamentally sees everything at a
tree-wide level. Emulating the weaknesses of CVS' recursive repository
scheme doesn't buy us much.
So, if anyone has strong objections to:
hg status -> tree-wide
hg status . -> current directory and below (current hg status)
hg diff -> tree-wide
hg diff . -> current directory and below (current hg status)
..now's a good time to speak up.
In addition to Benoit's patch, we'll probably need to add a test case
and then double-check all the docs.
--
Mathematics is the supreme nostalgia of our time.
|
