Re: [PATCH] Teach git to change to a given directory using -C option

From: Jeff King <peff@peff.net>
Date: Apr 21, 2013, 03:58 UTC
Message-ID: <20130421035857.GC18890@sigill.intra.peff.net>
In-Reply-To: <20130420221752.GA9980@elie.Belkin>

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.

Show 6 quoted lines

> 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

Show 5 quoted lines

> 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