Re: [PATCH] -C/--chdir command line option

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 20, 2008, 04:55 UTC
Message-ID: <7vr66b50gy.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20081019141634.GA8997@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 9 quoted lines

> On Sun, Oct 19, 2008 at 03:47:04PM +0200, Maciej Pasternacki wrote:
>
>> As for -C being superfluous: --git-dir and --work-tree seem to support  
>> weird usage patterns (like work tree separate from git-dir), but it seems 
>
> Hmm. Yeah, thinking about it more, -C is not really superfluous with
> respect to those options. You don't want to say "here is the work-tree,
> and here is the git-dir". You want to say "find the work-tree and
> git-dir for me using the usual rules, as if I were in this directory."

I think that interpretation of -C, if the option existed, makes sense, but I do not understand why the tool that drives git refuses to chdir to the repository for itself in the first place.

The only excuse I remember seeing in the thread was that "make has '-C' option, so let's have it, because it is similar", which does not justfiy addition of that option to git at all to me.

With "make", the -C option can be justified as a necessary tool to write a recursive Makefile that can be sanely and easily processed without actually executing any commands (iow, imaging implementing "make" that allows you to write "cd there && $(MAKE)" in the toplevel Makefile and tells the users what would happen in "there" when run as "make -n").

And even in "make" context, not all implementations have it. I think it is only GNU and fairly recent BSDs.