Re: [PATCH 3/3] Allow whole-tree operations to be started from a subdirectory

[Steven Grimm <koreth@midwinter.com>]

Josef Weidendorfer wrote:
> Why not add a general "--top" option to the "git" wrapper,
> to temporarily let git change to the toplevel while running
> the command?
>   

If I can add a config entry so --top is the default, then that's 
acceptable, but IMO it should be the default and we should, at most, 
spit out a warning if a command is run in a subdirectory and there's a 
chance of confusion.

When I run one of the commands that currently can't run in a 
subdirectory and it spits out its error message, I NEVER react to that 
by saying, "Oops, forgot I was in a subdirectory, guess I didn't want to 
run that after all." (Have any of you said that, even once?) I react by 
grimacing and typing "cd" so the command will do what I told it to do. I 
have done that every single time I've gotten the in-a-subdirectory 
error. And muttering under my breath something along the lines of, "The 
code knows everything it needs to know to do what I just told it to, but 
it's making me take seconds to do by hand what it could have done on its 
own in nanoseconds."

Which is why I think the commands should just cd to the top directory as 
needed. Doing otherwise is just making the user do pointless busywork. 
IMO any command that, if run in a subdirectory, currently does nothing 
but spit out a "hey, you can't run me in a subdirectory!" error is not 
doing what the user wanted. The user never runs one of those commands 
hoping to see an error message or to test whether he's in the top-level 
directory. I can't think of any situation in which I'd want to see that 
error instead of the --top behavior.

It is entirely possible that automatically changing to the top directory 
will also do something other than what the user wanted some percentage 
of the time, but that percentage will be far, far lower than 100, which 
is what it is now. And I posit that the number of users confused or 
frustrated by the whole-tree operations after the first time they see it 
happen (after which it won't be unexpected) will be far smaller than the 
number frustrated by the current pointless error message on a regular basis.

> The wish to allow git-fetch from subdirectories is the
> inconvenience to have to cd up, and later down. This is
> avoided by running "git --top fetch", and theses people
> should be happy.
>
> Yet, if the command outputs some relative paths, the
> user is very well aware that these paths are from the
> toplevel, as he explicitly specified "--top".
>   

That would be covered just as well by outputting a status message before 
any relative paths, e.g.

Updating /home/john/git-repo ...
Conflict: src/foo.c

(Not that that's real git output, but you get the idea.) It could be 
suppressed when the command is run from the top-level directory, though 
I think it'd be better to just always output it for consistency's sake.

-Steve