From: Michael J Gruber <git@drmicha.warpmail.net>
Date: Mon, 20 Oct 2008 12:57:45 GMT
Subject: Re: [PATCH] -C/--chdir command line option
Message-ID: <48FC8049.2080107@drmicha.warpmail.net>
In-Reply-To: <7vr66b50gy.fsf@gitster.siamese.dyndns.org>

Junio C Hamano venit, vidit, dixit 20.10.2008 06:55:
> Jeff King <peff@peff.net> writes:
> 
>> 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.

I want to have '-j2' ;)

Seriously:

git -C elsewhere command opts

is shorther and more direct than

(cd elsewhere && git command opts)

which is the true equivalent, or

pushd elsewhere; git command opts; popd

And much shorter than using --git-dir and --work-tree, which are
semi-broken right now.

I just think it's very useful to be able to peek into a repo somewhere
else quickly; or for transferral of objects between unrelated objects
(run rev-parse elsewhere etc.).

Michael