From: Michael J Gruber <git@drmicha.warpmail.net>
To: Nguyen Thai Ngoc Duy <pclouds@gmail.com>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: GIT_DIR vs. --git-dir
Date: Mon, 24 Sep 2012 14:56:45 +0200 [thread overview]
Message-ID: <5060588D.3080202@drmicha.warpmail.net> (raw)
In-Reply-To: <CACsJy8ChOd-684V8Dsbwf2nOsW8UMnYn_vo5MAZ6ixyq_QvMkw@mail.gmail.com>
Nguyen Thai Ngoc Duy venit, vidit, dixit 24.09.2012 11:53:
> 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.
> 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
next prev parent reply other threads:[~2012-09-24 12:57 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-24 7:19 GIT_DIR vs. --git-dir Michael J Gruber
2012-09-24 7:41 ` Nguyen Thai Ngoc Duy
2012-09-24 7:57 ` Michael J Gruber
2012-09-24 9:53 ` Nguyen Thai Ngoc Duy
2012-09-24 12:56 ` Michael J Gruber [this message]
2012-09-24 12:57 ` [RFC/PATCH] git: expand user path in --git-dir Michael J Gruber
2012-09-24 14:52 ` Jeff King
2012-09-24 14:57 ` Michael J Gruber
2012-09-24 17:30 ` Junio C Hamano
2012-09-25 5:33 ` Jan Engelhardt
2012-09-25 7:27 ` Michael J Gruber
2012-09-24 13:37 ` GIT_DIR vs. --git-dir Andreas Schwab
2012-09-24 14:36 ` Junio C Hamano
2012-09-24 14:51 ` Michael J Gruber
2012-09-24 14:49 ` Jeff King
2012-09-24 14:54 ` Michael J Gruber
2012-09-24 15:42 ` Andreas Schwab
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5060588D.3080202@drmicha.warpmail.net \
--to=git@drmicha.warpmail.net \
--cc=git@vger.kernel.org \
--cc=pclouds@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).