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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html