Re: GIT_DIR vs. --git-dir

From: Michael J Gruber <git@drmicha.warpmail.net>
Date: Sep 24, 2012, 12:56 UTC
Message-ID: <5060588D.3080202@drmicha.warpmail.net>
In-Reply-To: <CACsJy8ChOd-684V8Dsbwf2nOsW8UMnYn_vo5MAZ6ixyq_QvMkw@mail.gmail.com>

Nguyen Thai Ngoc Duy venit, vidit, dixit 24.09.2012 11:53:

Show 8 quoted lines

> On Mon, Sep 24, 2012 at 2:57 PM, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>> It might be difficult to implement, but I'm sorry I can't follow the
>> argumentation above at all; it's not based on what we do in other places
>> and other cases.
> 
> My point is, what's so special about --git-dir? what about
> --work-tree, or "commit -F path"? It's hard to draw a line there.

Sure those should follow, especially work-tree.

Show 5 quoted lines

> Config files are a special case, because git is the only one that
> reads the file. "~" expansion depends on shell setting. If users turn
> it off, they may be surprised that "~foo" is turned to /home/foo while
> they really mean "~foo". Warning is the only sensible thing we could
> do.

But that argument applies to config files in exactly the same way as it applies to command line arguments. Git is the only one reading them. So why not leave it up to Git to decide about expansion?

On the other hand: If Git expanding arguments is surprising, why is it unsurprising if Git expands config values?

You know the implementation, so there are no surprises for you. But once in a while we can pretend to design Git for those who just use it.

Michael