Allow git alias to override existing Git commands

Allow git alias to override existing Git commands

[Jeremy Morton]

It's recently come to my attention that the "git alias" config 
functionality ignores all aliases that would override existing Git 
commands.  This seems like a bad idea to me.

For example, I wanted to setup "git clone" to automatically act as 
"git clone --recursive".  Sure I could do it in the shell, but it's 
more of a pain - any tutorial I set up about doing it would have to 
worry about what shell the user was using - and if you're going to 
make that argument, why have "git alias" at all?  It can all be done 
from the shell.

Obviously I could also use a different alias that wasn't an existing 
Git command for this behaviour, but that would rather defeat the 
point: I want "git clone" to have different functionality.  If I 
remembered to use a different Git command, I might as well remember to 
type "git clone --recursive".  Also, if a future Git command were 
introduced with the same name as my alias, my alias's functionality 
would suddenly be ignored, giving unexpected behaviour.

The reasoning behind this that it's "to avoid confusion and troubles 
with script usage" seems to be at odds with the general Git mentality 
that the user is given lots of power, and if they screw it up it's 
basically just user error.  For example, Git doesn't *have* to allow 
you to rebase.  It's a potentially dangerous operation, so why is it 
allowed?  It might "cause confusion and troubles".

On the other hand, by disallowing the overriding of existing Git 
commands through aliases you are preventing a lot of useful 
functionality that those aliases might be used for.

So I think you should either allow Git aliases to override existing 
Git commands by default, or at least provide a config option that 
allows the user to say that this should happen.

-- 
Best regards,
Jeremy Morton (Jez)

Re: Allow git alias to override existing Git commands

[Stefan Beller]

On Tue, Nov 10, 2015 at 8:31 AM, Jeremy Morton <admin@game-point.net> wrote:
> It's recently come to my attention that the "git alias" config functionality
> ignores all aliases that would override existing Git commands.  This seems
> like a bad idea to me.

This ensures that the plumbing commands always work as expected.
As scripts *should* only use plumbing commands, the scripts should
work with high probability despite all the crazy user configuration/aliases.

>
> For example, I wanted to setup "git clone" to automatically act as "git
> clone --recursive".  Sure I could do it in the shell, but it's more of a
> pain - any tutorial I set up about doing it would have to worry about what
> shell the user was using - and if you're going to make that argument, why
> have "git alias" at all?  It can all be done from the shell.

I think the git way for your example would be to configure git to include that
option by default, something like

    git config --global submodules.recursiveClone yes

though I was skimming through the man page of git config and did not find
that option there. I guess it's missing.


>
> Obviously I could also use a different alias that wasn't an existing Git
> command for this behaviour, but that would rather defeat the point: I want
> "git clone" to have different functionality.  If I remembered to use a
> different Git command, I might as well remember to type "git clone
> --recursive".  Also, if a future Git command were introduced with the same
> name as my alias, my alias's functionality would suddenly be ignored, giving
> unexpected behaviour.
>
> The reasoning behind this that it's "to avoid confusion and troubles with
> script usage" seems to be at odds with the general Git mentality that the
> user is given lots of power, and if they screw it up it's basically just
> user error.

For scripting the plumbing commands are recommended. The plumbing commands
usually cannot be configured to do crazy stuff.

> For example, Git doesn't *have* to allow you to rebase.  It's a
> potentially dangerous operation, so why is it allowed?  It might "cause
> confusion and troubles".

Git doesn't try to hide its complexity from the users. And if a user would need
to hack their way around to get rebasing working again, might also
"cause confusion
and troubles".

>
> On the other hand, by disallowing the overriding of existing Git commands
> through aliases you are preventing a lot of useful functionality that those
> aliases might be used for.
>
> So I think you should either allow Git aliases to override existing Git
> commands by default, or at least provide a config option that allows the
> user to say that this should happen.
>
> --
> Best regards,
> Jeremy Morton (Jez)
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Allow git alias to override existing Git commands

[Jeremy Morton]

On 10/11/2015 18:12, Stefan Beller wrote:
> On Tue, Nov 10, 2015 at 8:31 AM, Jeremy Morton<admin@game-point.net>  wrote:
>> It's recently come to my attention that the "git alias" config functionality
>> ignores all aliases that would override existing Git commands.  This seems
>> like a bad idea to me.
>
> This ensures that the plumbing commands always work as expected.
> As scripts *should* only use plumbing commands, the scripts should
> work with high probability despite all the crazy user configuration/aliases.
>

I just disagree with this.  If a user chooses to override their Git 
commands, it's their problem.  Why should Git care about this?  It 
should provide the user with the option to do this, and if the user 
ruins scripts because of their aliases, it is not Git's problem.  What 
you are doing is taking away power from users to use git aliases to 
their full potential.

-- 
Best regards,
Jeremy Morton (Jez)

Re: Allow git alias to override existing Git commands

[Stefan Beller]

On Tue, Nov 10, 2015 at 12:04 PM, Jeremy Morton <admin@game-point.net> wrote:
> On 10/11/2015 18:12, Stefan Beller wrote:
>>
>> On Tue, Nov 10, 2015 at 8:31 AM, Jeremy Morton<admin@game-point.net>
>> wrote:
>>>
>>> It's recently come to my attention that the "git alias" config
>>> functionality
>>> ignores all aliases that would override existing Git commands.  This
>>> seems
>>> like a bad idea to me.
>>
>>
>> This ensures that the plumbing commands always work as expected.
>> As scripts *should* only use plumbing commands, the scripts should
>> work with high probability despite all the crazy user
>> configuration/aliases.
>>
>
> I just disagree with this.  If a user chooses to override their Git
> commands, it's their problem.  Why should Git care about this?

Because we still have some Git commands (i.e. git submodule) as scripts,
which would break if the user aliases plumbing commands. This is unexpected,
so should be avoided. Maybe we could allow aliasing porcelain commands though,
but that is extra effort, which nobody looked into yet.

> It should
> provide the user with the option to do this, and if the user ruins scripts
> because of their aliases, it is not Git's problem.  What you are doing is
> taking away power from users to use git aliases to their full potential.

Yeah, no user asked for that power I guess, you're the first. :)

As from your initial email, I think before trying to overriding 'clone'
to 'clone --recurse' you'd rather want to have a globally configured
option to recurse by default on invocation of 'clone'.
That sounds saner to me at least.

Stefan

Re: Allow git alias to override existing Git commands

[Sitaram Chamarty]

On 11/11/15 01:34, Jeremy Morton wrote:
> On 10/11/2015 18:12, Stefan Beller wrote:
>> On Tue, Nov 10, 2015 at 8:31 AM, Jeremy Morton<admin@game-point.net>  wrote:
>>> It's recently come to my attention that the "git alias" config functionality
>>> ignores all aliases that would override existing Git commands.  This seems
>>> like a bad idea to me.
>>
>> This ensures that the plumbing commands always work as expected.
>> As scripts *should* only use plumbing commands, the scripts should
>> work with high probability despite all the crazy user configuration/aliases.
>>
> 
> I just disagree with this.  If a user chooses to override their Git
> commands, it's their problem.  Why should Git care about this?  It
> should provide the user with the option to do this, and if the user
> ruins scripts because of their aliases, it is not Git's problem.  What
> you are doing is taking away power from users to use git aliases to
> their full potential.

A lot of things in Unix do follow that "give you rope to hang yourself"
philosophy.  I used to (and to *some* extent still do) think like that,
but some years of supporting normal users trying to do stuff has taught
me it's not always that simple.

I can easily see someone blogging some cool way to do something, and a
less savvy user uses that in his gitconfig, and gets burned later
(possibly much later, enough that he does not easily make the
connection!)

So for the record, I am definitely against this kind of change.

But if I were in your place, and really *needed* this, here's what I
would do:

    #!/bin/bash

    # this file is named 'git' and placed in a directory that is earlier in $PATH
    # than the real 'git' binary (typically $HOME/bin).  This allows you to
    # override git sub-commands by adding stuff like this to your ~/.gitconfig
    # (notice the "o-" prefix):
    #
    #   [alias]
    #       o-clone = clone --recursive

    GIT=/bin/git    # the real 'git' binary

    cmd="$1"
    shift

    if $GIT config --get alias.o-$cmd >/dev/null
    then
        $GIT o-$cmd "$@"
    else
        $GIT $cmd "$@"
    fi

Re: Allow git alias to override existing Git commands

[Jeremy Morton]

On 11/11/2015 04:48, Sitaram Chamarty wrote:
> A lot of things in Unix do follow that "give you rope to hang yourself"
> philosophy.  I used to (and to *some* extent still do) think like that,
> but some years of supporting normal users trying to do stuff has taught
> me it's not always that simple.
>
> I can easily see someone blogging some cool way to do something, and a
> less savvy user uses that in his gitconfig, and gets burned later
> (possibly much later, enough that he does not easily make the
> connection!)

We're not talking about "normal users" here, that's what Google Chrome 
is for.  We're talking about Git users using the commandline client. 
They ought to know what they're doing and if they don't, they're 
screwed anyway because there are quite a few gotchas with Git.

-- 
Best regards,
Jeremy Morton (Jez)

Re: Allow git alias to override existing Git commands

[Sitaram Chamarty]

On 11/11/15 14:58, Jeremy Morton wrote:
> On 11/11/2015 04:48, Sitaram Chamarty wrote:
>> A lot of things in Unix do follow that "give you rope to hang yourself"
>> philosophy.  I used to (and to *some* extent still do) think like that,
>> but some years of supporting normal users trying to do stuff has taught
>> me it's not always that simple.
>>
>> I can easily see someone blogging some cool way to do something, and a
>> less savvy user uses that in his gitconfig, and gets burned later
>> (possibly much later, enough that he does not easily make the
>> connection!)
> 
> We're not talking about "normal users" here, that's what Google Chrome
> is for.  We're talking about Git users using the commandline client.
> They ought to know what they're doing and if they don't, they're
> screwed anyway because there are quite a few gotchas with Git.

I can only repeat what I said before: it's not all black and white.

Reducing the opportunity to make mistakes is useful for everyone, even
expetrs.  Especially stuff that you may have setup aeons ago and hits
you only aeons later when something (supposedly unrelated) somewhere
else changes and you didn't remember and you tear your hair out.

It happens to everyone.  The only experts I know who have never torn
their hair out over something silly they forgot (could be anything) are
the ones who were already bald :)

Re: Allow git alias to override existing Git commands

[Jeremy Morton]

On 11/11/2015 09:51, Sitaram Chamarty wrote:
> I can only repeat what I said before: it's not all black and white.
>
> Reducing the opportunity to make mistakes is useful for everyone, even
> expetrs.  Especially stuff that you may have setup aeons ago and hits
> you only aeons later when something (supposedly unrelated) somewhere
> else changes and you didn't remember and you tear your hair out.

Not when it reduces useful functionality for experts, it's not.

-- 
Best regards,
Jeremy Morton (Jez)

Re: Allow git alias to override existing Git commands

[Sitaram Chamarty]

On 11/11/15 15:42, Jeremy Morton wrote:
> On 11/11/2015 09:51, Sitaram Chamarty wrote:
>> I can only repeat what I said before: it's not all black and white.
>>
>> Reducing the opportunity to make mistakes is useful for everyone, even
>> expetrs.  Especially stuff that you may have setup aeons ago and hits
>> you only aeons later when something (supposedly unrelated) somewhere
>> else changes and you didn't remember and you tear your hair out.
> 
> Not when it reduces useful functionality for experts, it's not.

Speaking of... did you try the script I sent in an earlier mail?

Putting it in /usr/local/bin (on Fedora.  YMMV) seems to work fine,
since that appears earlier than /bin where the real git lives.

Re: Allow git alias to override existing Git commands

[Stefan Beller]

On Wed, Nov 11, 2015 at 1:28 AM, Jeremy Morton <admin@game-point.net> wrote:
> On 11/11/2015 04:48, Sitaram Chamarty wrote:
>>
>> A lot of things in Unix do follow that "give you rope to hang yourself"
>> philosophy.  I used to (and to *some* extent still do) think like that,
>> but some years of supporting normal users trying to do stuff has taught
>> me it's not always that simple.
>>
>> I can easily see someone blogging some cool way to do something, and a
>> less savvy user uses that in his gitconfig, and gets burned later
>> (possibly much later, enough that he does not easily make the
>> connection!)
>
>
> We're not talking about "normal users" here, that's what Google Chrome is
> for.  We're talking about Git users using the commandline client. They ought
> to know what they're doing and if they don't, they're screwed anyway because
> there are quite a few gotchas with Git.
>

Just because you're an expert, doesn't mean you don't appreciate working without
safety net.

There are tons of people out there, who use Git for $REASONS (their
boss told them so,
it's cooler than $OTHERVCS, the project uses Git), without having the
time to take
a deep dive into Git. "It should just work".

So I haven't tried Sitaram's script, but it looks like it can get your job done?

Re: Allow git alias to override existing Git commands

[Jens Lehmann]

Am 10.11.2015 um 19:12 schrieb Stefan Beller:
> On Tue, Nov 10, 2015 at 8:31 AM, Jeremy Morton <admin@game-point.net> wrote:
>> It's recently come to my attention that the "git alias" config functionality
>> ignores all aliases that would override existing Git commands.  This seems
>> like a bad idea to me.
>
> This ensures that the plumbing commands always work as expected.
> As scripts *should* only use plumbing commands, the scripts should
> work with high probability despite all the crazy user configuration/aliases.

Exactly.

>> For example, I wanted to setup "git clone" to automatically act as "git
>> clone --recursive".  Sure I could do it in the shell, but it's more of a
>> pain - any tutorial I set up about doing it would have to worry about what
>> shell the user was using - and if you're going to make that argument, why
>> have "git alias" at all?  It can all be done from the shell.
>
> I think the git way for your example would be to configure git to include that
> option by default, something like
>
>      git config --global submodules.recursiveClone yes
>
> though I was skimming through the man page of git config and did not find
> that option there. I guess it's missing.

We thought about adding such a config option, but I believe that would
fall a bit short. If I want to have recursive clone I also want to init
all those submodules appearing in later fetches too (otherwise the end
result would depend on whether you cloned before or after a submodule
was added upstream, which is confusing). Extra points for populating
the submodule in my work tree when switching to a commit containing
the new submodule.

So what about a "submodule.autoupdate" config option? If set to true,
all submodules not marked "update=none" would automatically be fetched
and inited by fetch (and thus clone too) and then checked out (with my
recursive update changes) in every work tree manipulating command
(again including clone).

Users who only want the submodules to be present in the work tree but
not automagically updated could set "submodule.autoupdate=clone" to
avoid the extra cost of updating the work tree every time they switch
between commits. Now that Heiko's config-from-commit changes are in
master, someone could easily add that to fetch and clone as the first
step. We could also teach clone to make "submodule.autoupdate=true"
imply --recursive and execute the "git submodule" command to update
the work tree as a first step until the recursive checkout patches
are ready.

Does that make sense?

Re: Allow git alias to override existing Git commands

[Stefan Beller]

On Tue, Nov 10, 2015 at 1:57 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote:
> Am 10.11.2015 um 19:12 schrieb Stefan Beller:
>>
>> On Tue, Nov 10, 2015 at 8:31 AM, Jeremy Morton <admin@game-point.net>
>> wrote:
>>>
>>> It's recently come to my attention that the "git alias" config
>>> functionality
>>> ignores all aliases that would override existing Git commands.  This
>>> seems
>>> like a bad idea to me.
>>
>>
>> This ensures that the plumbing commands always work as expected.
>> As scripts *should* only use plumbing commands, the scripts should
>> work with high probability despite all the crazy user
>> configuration/aliases.
>
>
> Exactly.
>
>>> For example, I wanted to setup "git clone" to automatically act as "git
>>> clone --recursive".  Sure I could do it in the shell, but it's more of a
>>> pain - any tutorial I set up about doing it would have to worry about
>>> what
>>> shell the user was using - and if you're going to make that argument, why
>>> have "git alias" at all?  It can all be done from the shell.
>>
>>
>> I think the git way for your example would be to configure git to include
>> that
>> option by default, something like
>>
>>      git config --global submodules.recursiveClone yes
>>
>> though I was skimming through the man page of git config and did not find
>> that option there. I guess it's missing.
>
>
> We thought about adding such a config option, but I believe that would
> fall a bit short. If I want to have recursive clone I also want to init
> all those submodules appearing in later fetches too (otherwise the end
> result would depend on whether you cloned before or after a submodule
> was added upstream, which is confusing). Extra points for populating
> the submodule in my work tree when switching to a commit containing
> the new submodule.
>
> So what about a "submodule.autoupdate" config option? If set to true,
> all submodules not marked "update=none" would automatically be fetched
> and inited by fetch (and thus clone too) and then checked out (with my
> recursive update changes) in every work tree manipulating command
> (again including clone).
>
> Users who only want the submodules to be present in the work tree but
> not automagically updated could set "submodule.autoupdate=clone" to
> avoid the extra cost of updating the work tree every time they switch
> between commits. Now that Heiko's config-from-commit changes are in
> master, someone could easily add that to fetch and clone as the first
> step. We could also teach clone to make "submodule.autoupdate=true"
> imply --recursive and execute the "git submodule" command to update
> the work tree as a first step until the recursive checkout patches
> are ready.
>
> Does that make sense?

I guess.

So the repo tool has the concepts of groups. I plan to add that to git
eventually, too.
i.e. with comma separated list that looks like:

    git clone --submodule-groups=default,x86builds,new-phone-codename

Having a new option there there I would also set the

    submodule.autoupdate=all

implicitly which then enables --recurse-submodules on all supported commands.

By introducing such a new submodule groups option we don't need to tell
the users about all the new submodule options, but they can still take
advantage of them,
I'd assume.

Does that make sense, too?

Re: Allow git alias to override existing Git commands

[Jens Lehmann]

Am 10.11.2015 um 23:49 schrieb Stefan Beller:
> On Tue, Nov 10, 2015 at 1:57 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote:
>> Am 10.11.2015 um 19:12 schrieb Stefan Beller:
>>> On Tue, Nov 10, 2015 at 8:31 AM, Jeremy Morton <admin@game-point.net>
>>>> For example, I wanted to setup "git clone" to automatically act as "git
>>>> clone --recursive".  Sure I could do it in the shell, but it's more of a
>>>> pain - any tutorial I set up about doing it would have to worry about
>>>> what
>>>> shell the user was using - and if you're going to make that argument, why
>>>> have "git alias" at all?  It can all be done from the shell.
>>>
>>>
>>> I think the git way for your example would be to configure git to include
>>> that
>>> option by default, something like
>>>
>>>       git config --global submodules.recursiveClone yes
>>>
>>> though I was skimming through the man page of git config and did not find
>>> that option there. I guess it's missing.
>>
>>
>> We thought about adding such a config option, but I believe that would
>> fall a bit short. If I want to have recursive clone I also want to init
>> all those submodules appearing in later fetches too (otherwise the end
>> result would depend on whether you cloned before or after a submodule
>> was added upstream, which is confusing). Extra points for populating
>> the submodule in my work tree when switching to a commit containing
>> the new submodule.
>>
>> So what about a "submodule.autoupdate" config option? If set to true,
>> all submodules not marked "update=none" would automatically be fetched
>> and inited by fetch (and thus clone too) and then checked out (with my
>> recursive update changes) in every work tree manipulating command
>> (again including clone).
>>
>> Users who only want the submodules to be present in the work tree but
>> not automagically updated could set "submodule.autoupdate=clone" to
>> avoid the extra cost of updating the work tree every time they switch
>> between commits. Now that Heiko's config-from-commit changes are in
>> master, someone could easily add that to fetch and clone as the first
>> step. We could also teach clone to make "submodule.autoupdate=true"
>> imply --recursive and execute the "git submodule" command to update
>> the work tree as a first step until the recursive checkout patches
>> are ready.
>>
>> Does that make sense?
>
> I guess.
>
> So the repo tool has the concepts of groups. I plan to add that to git
> eventually, too.
> i.e. with comma separated list that looks like:
>
>      git clone --submodule-groups=default,x86builds,new-phone-codename
>
> Having a new option there there I would also set the
>
>      submodule.autoupdate=all
>
> implicitly which then enables --recurse-submodules on all supported commands.

And then only submodules contained in these groups would be cloned,
automatically initialized (including those being added to a group by
upstream in the future) and their work trees updated every time the
superproject commit changes? And all submodules that aren't part in
any of these groups would be skipped and neither downloaded nor
updated? Sounds good.

But I'd rather use

     submodule.autoupdate=groups

for that use case. I expect "all" to really mean all submodules,
not only those contained in the selected groups.

> By introducing such a new submodule groups option we don't need to tell
> the users about all the new submodule options, but they can still take
> advantage of them,
> I'd assume.
>
> Does that make sense, too?

Yup.