On Sat, Apr 20, 2013 at 03:18:38PM -0700, Jonathan Nieder wrote:
> The "sometimes you just want to pass a command to 'exec'" use case
> does not convince me. I equally well might want to run "git" after
> another command, or run "git" if and only if a repository exists
> there, or do any number of other things.
Sure. I don't claim that it solves every problem, just that I have
wanted it in that situation before.
> So we're left with "--git-dir does not automatically append .git when
> appropriate" as the problem being solved, which is a real problem.
> Maybe that is worth fixing more directly?
I'm a little hesitant, because --git-dir is _not_ "pretend like I am in
directory X". Even though people may use it that way for bare
repositories, it explicitly does not change your working tree.
I'm not sure what rule you are proposing. If it is:
1. When we get "--git-dir=a/b", look in "a/b/.git" (assuming a/b is
not a repo itself).
2. When we get "--git-dir=a/b", do the usual repo search from a/b,
finding the first of "a/b", "a/b/.git", "a/.git".
The second one is what makes me nervous, as it seems too much like
"pretend that we are in a/b". But the first one seems kind of hack-ish.
I suppose it is similar to the enter_repo rule used to find remotes,
though, so at least there is some precedence.
> It might also be convenient to be able to do something like
>
> git --git-dir=~/src/git log -- Documentation/
>
> which this -C option makes easy. *checks* Actually it works without,
> but for subtle reasons.
I'm not sure what subtle reason that is. It does not seem to work for
me:
$ (cd git && git log -- Documentation | wc -l)
99152
$ git --git-dir=git log -- Documentation | wc -l
fatal: Not a git repository: 'git'
0
A more interesting subtlety is this:
$ git --git-dir=git/.git log -- Documentation | wc -l
99152
$ git --git-dir=git/.git log Documentation | wc -l
fatal: ambiguous argument 'Documentation': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
0
> All that said, I don't mind -C terribly as long as it can maintain
> itself, which means including thorough documentation that covers the
> purpose and how pathname parameters and envvars interact with the new
> option and including tests under t/ to ensure it continues to work
> correctly in the future.
Yeah, I pretty much feel the same way. "git -C" is a concept that has
occurred to me several times over the years, and I always dismissed it
as "bah, you can do the same thing easily with one line of shell". It
makes sense to me because of the precedence in other programs and I
would probably use it, but I could also live without it. I do not mind
it if it is not a maintenance burden.
-Peff
--
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