All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Duy Nguyen <pclouds@gmail.com>
Cc: Git Mailing List <git@vger.kernel.org>, doron.behar@gmail.com
Subject: Re: [PATCH 1/2] parse-options: expand $HOME on filename options
Date: Thu, 22 Feb 2018 14:38:39 +0100	[thread overview]
Message-ID: <87606pf8kg.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <CACsJy8BsUsT6iO9_68+rHnZG5B-tcaXZAXR88nh8DgR65zvVKw@mail.gmail.com>


On Thu, Feb 22 2018, Duy Nguyen jotted:

> On Thu, Feb 15, 2018 at 5:46 AM, Ævar Arnfjörð Bjarmason
> <avarab@gmail.com> wrote:
>> In general I'm mildly negative on adding this, for every user like Doron
>> who'll be less confused by a hack like this, you'll have other users
>> who'll be confused about git inexplicably working with ~ in the middle
>> of strings, even though;
>>
>>     $ echo git init --template ~/path
>>     git init --template /home/avar/path
>>     $ echo git init --template=~/path
>>     git init --template=~/path
>
> If you have a directory named '~', I expect you are already used to
> prefixing it with './' because '~' will be expanded in many places
> where you might want to avoid.

Indeed. I've never had this use-case, just saying if it's being changed
it makes sense to have a small test for it somewhere.

>> I think it makes more sense to just leave such expansion to the shell,
>> and not try to magically expand it after the fact, since it's both
>> confusing (user: why does this work with git and not this other
>> program?), and as shown above changes existing semantics.
>>
>> We'll also be setting ourselves up for more disappointed users who'll
>> notice that e.g. `git clone file://~/path` doesn't work, but `git clone
>> file://$HOME/path` does, requiring more hacks to expand ~ in more
>> codepaths. Will they also expact `git log -G~` to find references to
>> their homedir in their dotfiles.git?
>>
>> I think this way lies madness, and it's better to just avoid it.
>
> Well. That's a bit extreme, I think if we add this then we handle case
> by case in future when it makes sense, not blindly expanding '~'
> everywhere.
>
> The problem I have with this --template=~/path is tab-completion
> actually completes the path, which (mis)leads me to think the command
> will accept '~/' too. But this looks like a bug in git-completion.bash
> though, it's a bit eager in completing stuff (or maybe it completes
> "--template ~/path" and "--template=~/path" the same way).

Ah I see, so you're doing "git init --template=~/<TAB>".

> I don't feel strongly about this. I'm OK with dropping these patches
> if people think it's not a good idea (then I will try to fix
> git-completion.bash not to complete '~' in this case).

I don't feel strongly about it either, just mildly negative on
introducing magic that gives you different behavior than shells do by
default.

I wonder if the consistency with the tab completion wouldn't be better
done by teaching the tab completion to just expand --template=~/<TAB> to
e.g. --template=/home/duy/.

On my (Debian) system doing e.g.:

    echo $HOME/bin/<TAB>

Will expand to:

    echo /home/avar/bin/

Maybe we could intercept that in the completion and ~ to the value of
$HOME. It would give completion that did the right thing, without the
expectation that ~ is going to be magic in some places and not others.

>> But I think that if we're going to keep it it needs some tests & docs to
>> point confused users to.

  reply	other threads:[~2018-02-22 13:38 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-14 10:10 [BUG] git init doesn't respect `--template` like configuration variable init.templateDir and $GIT_TEMPLATE_DIR Doron Behar
2018-02-14 10:51 ` [PATCH 1/2] parse-options: expand $HOME on filename options Nguyễn Thái Ngọc Duy
2018-02-14 10:51   ` [PATCH 2/2] init-db: change --template type to OPTION_FILENAME Nguyễn Thái Ngọc Duy
2018-02-14 14:08     ` Jeff King
2018-02-14 14:05   ` [PATCH 1/2] parse-options: expand $HOME on filename options Jeff King
2018-02-14 18:24     ` Junio C Hamano
2018-02-14 22:46   ` Ævar Arnfjörð Bjarmason
2018-02-15 18:36     ` Junio C Hamano
2018-02-22  9:26     ` Duy Nguyen
2018-02-22 13:38       ` Ævar Arnfjörð Bjarmason [this message]
2018-02-23 10:11         ` Duy Nguyen

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=87606pf8kg.fsf@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=doron.behar@gmail.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.