* Re: [PATCH/RFC] git.c: support "!!" aliases that do not move cwd
2016-10-07 12:27 ` Duy Nguyen
@ 2016-10-07 12:47 ` Matthieu Moy
2016-10-07 13:07 ` Duy Nguyen
2016-10-07 14:12 ` Johannes Schindelin
2016-10-07 14:11 ` Johannes Schindelin
2016-10-07 17:42 ` Johannes Sixt
2 siblings, 2 replies; 34+ messages in thread
From: Matthieu Moy @ 2016-10-07 12:47 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Johannes Schindelin, Junio C Hamano, Git Mailing List
Duy Nguyen <pclouds@gmail.com> writes:
> On Fri, Oct 7, 2016 at 6:20 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>> Hi Junio,
>>
>> On Thu, 6 Oct 2016, Junio C Hamano wrote:
>>
>>> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>>>
>>> > Throwing something at the mailing list to see if anybody is
>>> > interested.
>>> >
>>> > Current '!' aliases move cwd to $GIT_WORK_TREE first, which could
>>> > make
>>> > handling path arguments hard because they are relative to the
>>> > original
>>> > cwd. We set GIT_PREFIX to work around it, but I still think it's
>>> > more
>>> > natural to keep cwd where it is.
>>> >
>>> > We have a way to do that now after 441981b (git: simplify
>>> > environment
>>> > save/restore logic - 2016-01-26). It's just a matter of choosing
>>> > the
>>> > right syntax. I'm going with '!!'. I'm not very happy with it.
>>> > But I
>>> > do like this type of alias.
>>>
>>> I do not know why you are not happy with the syntax, but I
>>> personally think it brilliant, both the idea and the preliminary
>>> clean-up that made this possible with a simple patch like this.
>>
>> I guess he is not happy with it because "!!" is quite unintuitive a
>> construct. I know that *I* would have been puzzled by it, asking
>> "What the
>> heck does this do?".
>
> Yep. And I wouldn't want to set a tradition for the next alias type
> '!!!'. There's no good choice to represent a new alias type with a
> leading symbol. This just occurred to me, however, what do you think
> about a new config group for it? With can have something like
> externalAlias.* (or some other name) that lives in parallel with
> alias.*. Then we don't need '!' (or '!!') at all.
Another possibility: !(nocd), which leaves room
for !(keyword1,keyword2,...) if needed later. Also, it is consistent
with the :(word) syntax of pathspecs.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH/RFC] git.c: support "!!" aliases that do not move cwd
2016-10-07 12:47 ` Matthieu Moy
@ 2016-10-07 13:07 ` Duy Nguyen
2016-10-07 14:12 ` Johannes Schindelin
1 sibling, 0 replies; 34+ messages in thread
From: Duy Nguyen @ 2016-10-07 13:07 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Johannes Schindelin, Junio C Hamano, Git Mailing List
On Fri, Oct 7, 2016 at 7:47 PM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Duy Nguyen <pclouds@gmail.com> writes:
>
>> On Fri, Oct 7, 2016 at 6:20 PM, Johannes Schindelin
>> <Johannes.Schindelin@gmx.de> wrote:
>>> Hi Junio,
>>>
>>> On Thu, 6 Oct 2016, Junio C Hamano wrote:
>>>
>>>> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>>>>
>>>> > Throwing something at the mailing list to see if anybody is
>>>> > interested.
>>>> >
>>>> > Current '!' aliases move cwd to $GIT_WORK_TREE first, which could
>>>> > make
>>>> > handling path arguments hard because they are relative to the
>>>> > original
>>>> > cwd. We set GIT_PREFIX to work around it, but I still think it's
>>>> > more
>>>> > natural to keep cwd where it is.
>>>> >
>>>> > We have a way to do that now after 441981b (git: simplify
>>>> > environment
>>>> > save/restore logic - 2016-01-26). It's just a matter of choosing
>>>> > the
>>>> > right syntax. I'm going with '!!'. I'm not very happy with it.
>>>> > But I
>>>> > do like this type of alias.
>>>>
>>>> I do not know why you are not happy with the syntax, but I
>>>> personally think it brilliant, both the idea and the preliminary
>>>> clean-up that made this possible with a simple patch like this.
>>>
>>> I guess he is not happy with it because "!!" is quite unintuitive a
>>> construct. I know that *I* would have been puzzled by it, asking
>>> "What the
>>> heck does this do?".
>>
>> Yep. And I wouldn't want to set a tradition for the next alias type
>> '!!!'. There's no good choice to represent a new alias type with a
>> leading symbol. This just occurred to me, however, what do you think
>> about a new config group for it? With can have something like
>> externalAlias.* (or some other name) that lives in parallel with
>> alias.*. Then we don't need '!' (or '!!') at all.
>
> Another possibility: !(nocd), which leaves room
> for !(keyword1,keyword2,...) if needed later. Also, it is consistent
> with the :(word) syntax of pathspecs.
This seems to solve my problem nicely.
--
Duy
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH/RFC] git.c: support "!!" aliases that do not move cwd
2016-10-07 12:47 ` Matthieu Moy
2016-10-07 13:07 ` Duy Nguyen
@ 2016-10-07 14:12 ` Johannes Schindelin
2016-10-07 14:31 ` Matthieu Moy
1 sibling, 1 reply; 34+ messages in thread
From: Johannes Schindelin @ 2016-10-07 14:12 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Duy Nguyen, Junio C Hamano, Git Mailing List
[-- Attachment #1: Type: text/plain, Size: 2251 bytes --]
Hi Matthieu,
On Fri, 7 Oct 2016, Matthieu Moy wrote:
> Duy Nguyen <pclouds@gmail.com> writes:
>
> > On Fri, Oct 7, 2016 at 6:20 PM, Johannes Schindelin
> > <Johannes.Schindelin@gmx.de> wrote:
> >> Hi Junio,
> >>
> >> On Thu, 6 Oct 2016, Junio C Hamano wrote:
> >>
> >>> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> >>>
> >>> > Throwing something at the mailing list to see if anybody is
> >>> > interested.
> >>> >
> >>> > Current '!' aliases move cwd to $GIT_WORK_TREE first, which could
> >>> > make
> >>> > handling path arguments hard because they are relative to the
> >>> > original
> >>> > cwd. We set GIT_PREFIX to work around it, but I still think it's
> >>> > more
> >>> > natural to keep cwd where it is.
> >>> >
> >>> > We have a way to do that now after 441981b (git: simplify
> >>> > environment
> >>> > save/restore logic - 2016-01-26). It's just a matter of choosing
> >>> > the
> >>> > right syntax. I'm going with '!!'. I'm not very happy with it.
> >>> > But I
> >>> > do like this type of alias.
> >>>
> >>> I do not know why you are not happy with the syntax, but I
> >>> personally think it brilliant, both the idea and the preliminary
> >>> clean-up that made this possible with a simple patch like this.
> >>
> >> I guess he is not happy with it because "!!" is quite unintuitive a
> >> construct. I know that *I* would have been puzzled by it, asking
> >> "What the
> >> heck does this do?".
> >
> > Yep. And I wouldn't want to set a tradition for the next alias type
> > '!!!'. There's no good choice to represent a new alias type with a
> > leading symbol. This just occurred to me, however, what do you think
> > about a new config group for it? With can have something like
> > externalAlias.* (or some other name) that lives in parallel with
> > alias.*. Then we don't need '!' (or '!!') at all.
>
> Another possibility: !(nocd), which leaves room
> for !(keyword1,keyword2,...) if needed later. Also, it is consistent
> with the :(word) syntax of pathspecs.
But is this backwards-compatible? Don't we execute everything that comes
after the exclamation mark as a command-line via shell, where the
parentheses mean "open a subshell"?
Ciao,
Dscho
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH/RFC] git.c: support "!!" aliases that do not move cwd
2016-10-07 14:12 ` Johannes Schindelin
@ 2016-10-07 14:31 ` Matthieu Moy
0 siblings, 0 replies; 34+ messages in thread
From: Matthieu Moy @ 2016-10-07 14:31 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Duy Nguyen, Junio C Hamano, Git Mailing List
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi Matthieu,
>
> On Fri, 7 Oct 2016, Matthieu Moy wrote:
>
>> Another possibility: !(nocd), which leaves room
>> for !(keyword1,keyword2,...) if needed later. Also, it is consistent
>> with the :(word) syntax of pathspecs.
>
> But is this backwards-compatible? Don't we execute everything that comes
> after the exclamation mark as a command-line via shell, where the
> parentheses mean "open a subshell"?
Good point. I can imagine someone already having
[alias]
foo = !(cd bar && $something) && $something_else
Your proposed (keyword)! is better.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH/RFC] git.c: support "!!" aliases that do not move cwd
2016-10-07 12:27 ` Duy Nguyen
2016-10-07 12:47 ` Matthieu Moy
@ 2016-10-07 14:11 ` Johannes Schindelin
2016-10-07 14:20 ` Jeff King
2016-10-07 17:42 ` Johannes Sixt
2 siblings, 1 reply; 34+ messages in thread
From: Johannes Schindelin @ 2016-10-07 14:11 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Junio C Hamano, Git Mailing List
[-- Attachment #1: Type: text/plain, Size: 2448 bytes --]
Hi Duy,
On Fri, 7 Oct 2016, Duy Nguyen wrote:
> On Fri, Oct 7, 2016 at 6:20 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >
> > On Thu, 6 Oct 2016, Junio C Hamano wrote:
> >
> >> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> >>
> >> > Throwing something at the mailing list to see if anybody is
> >> > interested.
> >> >
> >> > Current '!' aliases move cwd to $GIT_WORK_TREE first, which could make
> >> > handling path arguments hard because they are relative to the original
> >> > cwd. We set GIT_PREFIX to work around it, but I still think it's more
> >> > natural to keep cwd where it is.
> >> >
> >> > We have a way to do that now after 441981b (git: simplify environment
> >> > save/restore logic - 2016-01-26). It's just a matter of choosing the
> >> > right syntax. I'm going with '!!'. I'm not very happy with it. But I
> >> > do like this type of alias.
> >>
> >> I do not know why you are not happy with the syntax, but I
> >> personally think it brilliant, both the idea and the preliminary
> >> clean-up that made this possible with a simple patch like this.
> >
> > I guess he is not happy with it because "!!" is quite unintuitive a
> > construct. I know that *I* would have been puzzled by it, asking "What the
> > heck does this do?".
>
> Yep. And I wouldn't want to set a tradition for the next alias type
> '!!!'. There's no good choice to represent a new alias type with a
> leading symbol. This just occurred to me, however, what do you think
> about a new config group for it? With can have something like
> externalAlias.* (or some other name) that lives in parallel with
> alias.*. Then we don't need '!' (or '!!') at all.
But what would the precedence be? externalAlias.xyz wins over alias.xyz?
And we still would need '!' support: tons of people (including myself)
rely on it.
Possibly a better idea would be to use *another* special symbol, one that
makes intuitive sense as a modifier, such as:
[alias]
# This works as before
xyz = !pwd
# As does this
stat = -p status
# This, however, is different:
duy = (nocd)!pwd
This is backwards compatible as "(" is not a part of any Git command, nor
of a valid alias, nor is it commonly used as part of a git-*
executable/script.
It is also kind of a bit more intuitive, I'd wager, and it is also
extensible to future options we may want to introduce.
Ciao,
Dscho
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH/RFC] git.c: support "!!" aliases that do not move cwd
2016-10-07 14:11 ` Johannes Schindelin
@ 2016-10-07 14:20 ` Jeff King
0 siblings, 0 replies; 34+ messages in thread
From: Jeff King @ 2016-10-07 14:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Duy Nguyen, Junio C Hamano, Git Mailing List
On Fri, Oct 07, 2016 at 04:11:34PM +0200, Johannes Schindelin wrote:
> Possibly a better idea would be to use *another* special symbol, one that
> makes intuitive sense as a modifier, such as:
>
> [alias]
> # This works as before
> xyz = !pwd
> # As does this
> stat = -p status
> # This, however, is different:
> duy = (nocd)!pwd
>
> This is backwards compatible as "(" is not a part of any Git command, nor
> of a valid alias, nor is it commonly used as part of a git-*
> executable/script.
>
> It is also kind of a bit more intuitive, I'd wager, and it is also
> extensible to future options we may want to introduce.
I like this much better (like you, I am concerned about things like
"!(foo)" as conflicting with the shell). And I think your "(nocd)!pwd"
example is quite readable.
-Peff
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH/RFC] git.c: support "!!" aliases that do not move cwd
2016-10-07 12:27 ` Duy Nguyen
2016-10-07 12:47 ` Matthieu Moy
2016-10-07 14:11 ` Johannes Schindelin
@ 2016-10-07 17:42 ` Johannes Sixt
2016-10-07 17:50 ` Jeff King
2 siblings, 1 reply; 34+ messages in thread
From: Johannes Sixt @ 2016-10-07 17:42 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Johannes Schindelin, Junio C Hamano, Git Mailing List
Am 07.10.2016 um 14:27 schrieb Duy Nguyen:
> On Fri, Oct 7, 2016 at 6:20 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>> Hi Junio,
>>
>> On Thu, 6 Oct 2016, Junio C Hamano wrote:
>>
>>> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>>>
>>>> Throwing something at the mailing list to see if anybody is
>>>> interested.
>>>>
>>>> Current '!' aliases move cwd to $GIT_WORK_TREE first, which could make
>>>> handling path arguments hard because they are relative to the original
>>>> cwd. We set GIT_PREFIX to work around it, but I still think it's more
>>>> natural to keep cwd where it is.
>>>>
>>>> We have a way to do that now after 441981b (git: simplify environment
>>>> save/restore logic - 2016-01-26). It's just a matter of choosing the
>>>> right syntax. I'm going with '!!'. I'm not very happy with it. But I
>>>> do like this type of alias.
>>>
>>> I do not know why you are not happy with the syntax, but I
>>> personally think it brilliant, both the idea and the preliminary
>>> clean-up that made this possible with a simple patch like this.
>>
>> I guess he is not happy with it because "!!" is quite unintuitive a
>> construct. I know that *I* would have been puzzled by it, asking "What the
>> heck does this do?".
>
> Yep. And I wouldn't want to set a tradition for the next alias type
> '!!!'. There's no good choice to represent a new alias type with a
> leading symbol. This just occurred to me, however, what do you think
> about a new config group for it? With can have something like
> externalAlias.* (or some other name) that lives in parallel with
> alias.*. Then we don't need '!' (or '!!') at all.
Maybe it's time to aim for
git config alias.d2u.shell \
'f() { git ls-files "$@" | xargs dos2unix; }; f'
git config alias.d2u.cdup false
git d2u *.c # yada!
-- Hannes
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH/RFC] git.c: support "!!" aliases that do not move cwd
2016-10-07 17:42 ` Johannes Sixt
@ 2016-10-07 17:50 ` Jeff King
2016-10-08 8:36 ` Johannes Schindelin
0 siblings, 1 reply; 34+ messages in thread
From: Jeff King @ 2016-10-07 17:50 UTC (permalink / raw)
To: Johannes Sixt
Cc: Duy Nguyen, Johannes Schindelin, Junio C Hamano, Git Mailing List
On Fri, Oct 07, 2016 at 07:42:35PM +0200, Johannes Sixt wrote:
> Maybe it's time to aim for
>
> git config alias.d2u.shell \
> 'f() { git ls-files "$@" | xargs dos2unix; }; f'
> git config alias.d2u.cdup false
> git d2u *.c # yada!
That would be nice. It would also allow "alias.foo_bar.shell"; right now
"alias.foo_bar" is forbidden because of the config syntax, which does
not allow underscores outside of the "subsection" name.
-Peff
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH/RFC] git.c: support "!!" aliases that do not move cwd
2016-10-07 17:50 ` Jeff King
@ 2016-10-08 8:36 ` Johannes Schindelin
2016-10-09 6:01 ` Jeff King
0 siblings, 1 reply; 34+ messages in thread
From: Johannes Schindelin @ 2016-10-08 8:36 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Sixt, Duy Nguyen, Junio C Hamano, Git Mailing List
Hi Peff & Hannes,
On Fri, 7 Oct 2016, Jeff King wrote:
> On Fri, Oct 07, 2016 at 07:42:35PM +0200, Johannes Sixt wrote:
>
> > Maybe it's time to aim for
> >
> > git config alias.d2u.shell \
> > 'f() { git ls-files "$@" | xargs dos2unix; }; f'
> > git config alias.d2u.cdup false
> > git d2u *.c # yada!
>
> That would be nice. It would also allow "alias.foo_bar.shell"; right now
> "alias.foo_bar" is forbidden because of the config syntax, which does
> not allow underscores outside of the "subsection" name.
So what about this?
[alias]
d2u = !dos2unix
[alias "d2u"]
shell = 'f() { git ls-files "$@" | xargs dos2unix; }; f'
exec = C:/cygwin64/bin/dos2unix.exe
You introduce all kinds of ambiguities here that did not exist before...
Ciao,
Dscho
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH/RFC] git.c: support "!!" aliases that do not move cwd
2016-10-08 8:36 ` Johannes Schindelin
@ 2016-10-09 6:01 ` Jeff King
2016-10-09 6:08 ` Jeff King
2016-10-09 11:32 ` Duy Nguyen
0 siblings, 2 replies; 34+ messages in thread
From: Jeff King @ 2016-10-09 6:01 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Johannes Sixt, Duy Nguyen, Junio C Hamano, Git Mailing List
On Sat, Oct 08, 2016 at 10:36:13AM +0200, Johannes Schindelin wrote:
> > > Maybe it's time to aim for
> > >
> > > git config alias.d2u.shell \
> > > 'f() { git ls-files "$@" | xargs dos2unix; }; f'
> > > git config alias.d2u.cdup false
> > > git d2u *.c # yada!
> >
> > That would be nice. It would also allow "alias.foo_bar.shell"; right now
> > "alias.foo_bar" is forbidden because of the config syntax, which does
> > not allow underscores outside of the "subsection" name.
>
> So what about this?
>
> [alias]
> d2u = !dos2unix
> [alias "d2u"]
> shell = 'f() { git ls-files "$@" | xargs dos2unix; }; f'
> exec = C:/cygwin64/bin/dos2unix.exe
>
> You introduce all kinds of ambiguities here that did not exist before...
If you mean ambiguity between the old "alias.X" and the new "alias.X.*",
then yes, I think that's an unavoidable part of the transition. IMHO,
the new should take precedence over the old, and people will gradually
move from one to the other.
If you mean the ambiguity between alias.X.shell and alias.X.exec in your
example, the problem is that you have keys with overlapping meanings.
One solution is "don't do that" (so have a key like "cmd", and another
to select "shell or git-cmd", etc). Another is to define some rule, like
"last one wins" (so "exec" overrides "shell" in your example).
I'd prefer the "don't do that" path. The config you showed is
nonsensical, and it doesn't really matter that much how we behave. But
it is better still if we have a config scheme that makes it hard to
write nonsensical things in the first place.
-Peff
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH/RFC] git.c: support "!!" aliases that do not move cwd
2016-10-09 6:01 ` Jeff King
@ 2016-10-09 6:08 ` Jeff King
2016-10-09 11:32 ` Duy Nguyen
1 sibling, 0 replies; 34+ messages in thread
From: Jeff King @ 2016-10-09 6:08 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Johannes Sixt, Duy Nguyen, Junio C Hamano, Git Mailing List
On Sun, Oct 09, 2016 at 02:01:49AM -0400, Jeff King wrote:
> > So what about this?
> >
> > [alias]
> > d2u = !dos2unix
> > [alias "d2u"]
> > shell = 'f() { git ls-files "$@" | xargs dos2unix; }; f'
> > exec = C:/cygwin64/bin/dos2unix.exe
> >
> > You introduce all kinds of ambiguities here that did not exist before...
>
> If you mean ambiguity between the old "alias.X" and the new "alias.X.*",
> then yes, I think that's an unavoidable part of the transition. IMHO,
> the new should take precedence over the old, and people will gradually
> move from one to the other.
>
> If you mean the ambiguity between alias.X.shell and alias.X.exec in your
> example, the problem is that you have keys with overlapping meanings.
> One solution is "don't do that" (so have a key like "cmd", and another
> to select "shell or git-cmd", etc). Another is to define some rule, like
> "last one wins" (so "exec" overrides "shell" in your example).
>
> I'd prefer the "don't do that" path. The config you showed is
> nonsensical, and it doesn't really matter that much how we behave. But
> it is better still if we have a config scheme that makes it hard to
> write nonsensical things in the first place.
Just to be clear on my "don't do that", I don't mean "the user should
not do that", but "do not design a config scheme with keys that have
overlapping meanings".
-Peff
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH/RFC] git.c: support "!!" aliases that do not move cwd
2016-10-09 6:01 ` Jeff King
2016-10-09 6:08 ` Jeff King
@ 2016-10-09 11:32 ` Duy Nguyen
2016-10-09 20:58 ` Jeff King
1 sibling, 1 reply; 34+ messages in thread
From: Duy Nguyen @ 2016-10-09 11:32 UTC (permalink / raw)
To: Jeff King
Cc: Johannes Schindelin, Johannes Sixt, Junio C Hamano, Git Mailing List
On Sun, Oct 9, 2016 at 1:01 PM, Jeff King <peff@peff.net> wrote:
> On Sat, Oct 08, 2016 at 10:36:13AM +0200, Johannes Schindelin wrote:
>
>> > > Maybe it's time to aim for
>> > >
>> > > git config alias.d2u.shell \
>> > > 'f() { git ls-files "$@" | xargs dos2unix; }; f'
>> > > git config alias.d2u.cdup false
>> > > git d2u *.c # yada!
>> >
>> > That would be nice. It would also allow "alias.foo_bar.shell"; right now
>> > "alias.foo_bar" is forbidden because of the config syntax, which does
>> > not allow underscores outside of the "subsection" name.
>>
>> So what about this?
>>
>> [alias]
>> d2u = !dos2unix
>> [alias "d2u"]
>> shell = 'f() { git ls-files "$@" | xargs dos2unix; }; f'
>> exec = C:/cygwin64/bin/dos2unix.exe
>>
>> You introduce all kinds of ambiguities here that did not exist before...
>
> If you mean ambiguity between the old "alias.X" and the new "alias.X.*",
> then yes, I think that's an unavoidable part of the transition. IMHO,
> the new should take precedence over the old, and people will gradually
> move from one to the other.
Do we really need to treat this differently than
[alias]
d2u = !dos2unix
d2u = C:/cygwin/bin/dos3unix.exe
?
Another similar case is one d2u (could be either old syntax or new) is
defined in ~/.gitconfig and the other d2u in $GIT_DIR/config. In
either case, the "latest" d2u definition wins.
> If you mean the ambiguity between alias.X.shell and alias.X.exec in your
> example, the problem is that you have keys with overlapping meanings.
> One solution is "don't do that" (so have a key like "cmd", and another
> to select "shell or git-cmd", etc). Another is to define some rule, like
> "last one wins" (so "exec" overrides "shell" in your example).
>
> I'd prefer the "don't do that" path. The config you showed is
> nonsensical, and it doesn't really matter that much how we behave. But
> it is better still if we have a config scheme that makes it hard to
> write nonsensical things in the first place.
Any suggestion? I suppose we can have _one_ key for the command. How
to execute that command (exec, shell, nocd...) are boolean options.
People can still write conflicting things. We have been nice so far,
always dying when the user specify conflicting command line options.
We could do the same here, I guess.
--
Duy
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH/RFC] git.c: support "!!" aliases that do not move cwd
2016-10-09 11:32 ` Duy Nguyen
@ 2016-10-09 20:58 ` Jeff King
2016-10-10 17:52 ` Junio C Hamano
2016-10-11 9:44 ` Johannes Schindelin
0 siblings, 2 replies; 34+ messages in thread
From: Jeff King @ 2016-10-09 20:58 UTC (permalink / raw)
To: Duy Nguyen
Cc: Johannes Schindelin, Johannes Sixt, Junio C Hamano, Git Mailing List
On Sun, Oct 09, 2016 at 06:32:38PM +0700, Duy Nguyen wrote:
> > If you mean ambiguity between the old "alias.X" and the new "alias.X.*",
> > then yes, I think that's an unavoidable part of the transition. IMHO,
> > the new should take precedence over the old, and people will gradually
> > move from one to the other.
>
> Do we really need to treat this differently than
>
> [alias]
> d2u = !dos2unix
> d2u = C:/cygwin/bin/dos3unix.exe
>
> ?
>
> Another similar case is one d2u (could be either old syntax or new) is
> defined in ~/.gitconfig and the other d2u in $GIT_DIR/config. In
> either case, the "latest" d2u definition wins.
Yeah, that's reasonable, too. So:
[alias]
d2u = "!dos2unix"
acts exactly as if:
[alias "d2u"]
command = dos2unix
type = shell
was specified at that point, which is easy to understand.
> > If you mean the ambiguity between alias.X.shell and alias.X.exec in your
> > example, the problem is that you have keys with overlapping meanings.
> > One solution is "don't do that" (so have a key like "cmd", and another
> > to select "shell or git-cmd", etc). Another is to define some rule, like
> > "last one wins" (so "exec" overrides "shell" in your example).
> [...]
>
> Any suggestion? I suppose we can have _one_ key for the command. How
> to execute that command (exec, shell, nocd...) are boolean options.
> People can still write conflicting things. We have been nice so far,
> always dying when the user specify conflicting command line options.
> We could do the same here, I guess.
Having separate exec/shell boolean options just punts the overlap from
the command key to those keys. If you have two mutually exclusive
options, I think the best thing is a single option, like:
type = <shell | exec | whatever>
and then it is obvious that a second appearance of "type" overrides an
earlier one, by our usual "last one wins" convention. As opposed to:
shell = true
exec = true
where you have to understand the meaning of each option to know that
"exec" overrides "shell".
-Peff
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH/RFC] git.c: support "!!" aliases that do not move cwd
2016-10-09 20:58 ` Jeff King
@ 2016-10-10 17:52 ` Junio C Hamano
2016-10-10 18:21 ` Jeff King
2016-10-11 9:44 ` Johannes Schindelin
1 sibling, 1 reply; 34+ messages in thread
From: Junio C Hamano @ 2016-10-10 17:52 UTC (permalink / raw)
To: Jeff King
Cc: Duy Nguyen, Johannes Schindelin, Johannes Sixt, Git Mailing List
Jeff King <peff@peff.net> writes:
> Having separate exec/shell boolean options just punts the overlap from
> the command key to those keys. If you have two mutually exclusive
> options, I think the best thing is a single option, like:
>
> type = <shell | exec | whatever>
>
> and then it is obvious that a second appearance of "type" overrides an
> earlier one, by our usual "last one wins" convention. As opposed to:
>
> shell = true
> exec = true
>
> where you have to understand the meaning of each option to know that
> "exec" overrides "shell".
Good.
Duy's "do we want to chdir or stay?" would be an orthogonal axis to
"what does the command line look like?" and "how is the command line
run?" so it adds one member to the "alias.<string>.*" family of
variables, I guess.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH/RFC] git.c: support "!!" aliases that do not move cwd
2016-10-10 17:52 ` Junio C Hamano
@ 2016-10-10 18:21 ` Jeff King
2016-10-10 19:07 ` Junio C Hamano
0 siblings, 1 reply; 34+ messages in thread
From: Jeff King @ 2016-10-10 18:21 UTC (permalink / raw)
To: Junio C Hamano
Cc: Duy Nguyen, Johannes Schindelin, Johannes Sixt, Git Mailing List
On Mon, Oct 10, 2016 at 10:52:26AM -0700, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > Having separate exec/shell boolean options just punts the overlap from
> > the command key to those keys. If you have two mutually exclusive
> > options, I think the best thing is a single option, like:
> >
> > type = <shell | exec | whatever>
> >
> > and then it is obvious that a second appearance of "type" overrides an
> > earlier one, by our usual "last one wins" convention. As opposed to:
> >
> > shell = true
> > exec = true
> >
> > where you have to understand the meaning of each option to know that
> > "exec" overrides "shell".
>
> Good.
>
> Duy's "do we want to chdir or stay?" would be an orthogonal axis to
> "what does the command line look like?" and "how is the command line
> run?" so it adds one member to the "alias.<string>.*" family of
> variables, I guess.
Yeah, exactly. There may be other orthogonal axes to add, too, but I do
not have any in mind myself. My main motive in switching to the
"alias.$cmd.key" syntax is that it fixes the ancient mistake of putting
arbitrary content into the key (just like pager.*, as we've discussed
elsewhere).
-Peff
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH/RFC] git.c: support "!!" aliases that do not move cwd
2016-10-10 18:21 ` Jeff King
@ 2016-10-10 19:07 ` Junio C Hamano
0 siblings, 0 replies; 34+ messages in thread
From: Junio C Hamano @ 2016-10-10 19:07 UTC (permalink / raw)
To: Jeff King
Cc: Duy Nguyen, Johannes Schindelin, Johannes Sixt, Git Mailing List
Jeff King <peff@peff.net> writes:
> ... My main motive in switching to the
> "alias.$cmd.key" syntax is that it fixes the ancient mistake of putting
> arbitrary content into the key (just like pager.*, as we've discussed
> elsewhere).
Yup, we are on the same page. It's not too grave a mistake (we said
"these are command names and do not have to be able to contain
random letters" and deliberately did without the usual three-level
hierarchy; I think the reasoning is even more valid for pager.*),
but it does imply case insensitivity not to use three-level names,
and I think it is a good move.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH/RFC] git.c: support "!!" aliases that do not move cwd
2016-10-09 20:58 ` Jeff King
2016-10-10 17:52 ` Junio C Hamano
@ 2016-10-11 9:44 ` Johannes Schindelin
2016-10-11 10:53 ` Duy Nguyen
2016-10-11 15:01 ` Jeff King
1 sibling, 2 replies; 34+ messages in thread
From: Johannes Schindelin @ 2016-10-11 9:44 UTC (permalink / raw)
To: Jeff King; +Cc: Duy Nguyen, Johannes Sixt, Junio C Hamano, Git Mailing List
Hi,
On Sun, 9 Oct 2016, Jeff King wrote:
> On Sun, Oct 09, 2016 at 06:32:38PM +0700, Duy Nguyen wrote:
>
> > > If you mean ambiguity between the old "alias.X" and the new "alias.X.*",
> > > then yes, I think that's an unavoidable part of the transition. IMHO,
> > > the new should take precedence over the old, and people will gradually
> > > move from one to the other.
> >
> > Do we really need to treat this differently than
> >
> > [alias]
> > d2u = !dos2unix
> > d2u = C:/cygwin/bin/dos3unix.exe
> >
> > ?
> >
> > Another similar case is one d2u (could be either old syntax or new) is
> > defined in ~/.gitconfig and the other d2u in $GIT_DIR/config. In
> > either case, the "latest" d2u definition wins.
>
> Yeah, that's reasonable, too. So:
>
> [alias]
> d2u = "!dos2unix"
>
> acts exactly as if:
>
> [alias "d2u"]
> command = dos2unix
> type = shell
>
> was specified at that point, which is easy to understand.
It is easy to understand, and even easier to get wrong or out of sync. I
really liked the ease of *one* `git config` call to add new aliases. Not
sure that I like the need for more such calls just to add *one* alias (one
config call for "shell", one for "don't cd up", etc).
Ciao,
Dscho
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH/RFC] git.c: support "!!" aliases that do not move cwd
2016-10-11 9:44 ` Johannes Schindelin
@ 2016-10-11 10:53 ` Duy Nguyen
2016-10-11 11:28 ` Johannes Schindelin
2016-10-11 15:01 ` Jeff King
1 sibling, 1 reply; 34+ messages in thread
From: Duy Nguyen @ 2016-10-11 10:53 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Jeff King, Johannes Sixt, Junio C Hamano, Git Mailing List
On Tue, Oct 11, 2016 at 4:44 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Sun, 9 Oct 2016, Jeff King wrote:
>
>> On Sun, Oct 09, 2016 at 06:32:38PM +0700, Duy Nguyen wrote:
>>
>> > > If you mean ambiguity between the old "alias.X" and the new "alias.X.*",
>> > > then yes, I think that's an unavoidable part of the transition. IMHO,
>> > > the new should take precedence over the old, and people will gradually
>> > > move from one to the other.
>> >
>> > Do we really need to treat this differently than
>> >
>> > [alias]
>> > d2u = !dos2unix
>> > d2u = C:/cygwin/bin/dos3unix.exe
>> >
>> > ?
>> >
>> > Another similar case is one d2u (could be either old syntax or new) is
>> > defined in ~/.gitconfig and the other d2u in $GIT_DIR/config. In
>> > either case, the "latest" d2u definition wins.
>>
>> Yeah, that's reasonable, too. So:
>>
>> [alias]
>> d2u = "!dos2unix"
>>
>> acts exactly as if:
>>
>> [alias "d2u"]
>> command = dos2unix
>> type = shell
>>
>> was specified at that point, which is easy to understand.
>
> It is easy to understand, and even easier to get wrong or out of sync. I
> really liked the ease of *one* `git config` call to add new aliases.
I was about to bring this up. Although to me, "git config --global
alias.foo bar" is more convenient, but not using it is not exactly
easy to get wrong or out of sync. For adding alias.$name.* I was
thinking about "git config --global --edit", not executing "git
config" multiple times.
> Not sure that I like the need for more such calls just to add *one* alias (one
> config call for "shell", one for "don't cd up", etc).
We could add git-alias if more alias types pop up (and in my opinion
git-alias is the right call, we've been abusing git-config for alias
manipulation for a long time).
--
Duy
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH/RFC] git.c: support "!!" aliases that do not move cwd
2016-10-11 10:53 ` Duy Nguyen
@ 2016-10-11 11:28 ` Johannes Schindelin
0 siblings, 0 replies; 34+ messages in thread
From: Johannes Schindelin @ 2016-10-11 11:28 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Jeff King, Johannes Sixt, Junio C Hamano, Git Mailing List
Hi Duy,
On Tue, 11 Oct 2016, Duy Nguyen wrote:
> On Tue, Oct 11, 2016 at 4:44 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >
> > On Sun, 9 Oct 2016, Jeff King wrote:
> >
> >> On Sun, Oct 09, 2016 at 06:32:38PM +0700, Duy Nguyen wrote:
> >>
> >> > > If you mean ambiguity between the old "alias.X" and the new "alias.X.*",
> >> > > then yes, I think that's an unavoidable part of the transition. IMHO,
> >> > > the new should take precedence over the old, and people will gradually
> >> > > move from one to the other.
> >> >
> >> > Do we really need to treat this differently than
> >> >
> >> > [alias]
> >> > d2u = !dos2unix
> >> > d2u = C:/cygwin/bin/dos3unix.exe
> >> >
> >> > ?
> >> >
> >> > Another similar case is one d2u (could be either old syntax or new) is
> >> > defined in ~/.gitconfig and the other d2u in $GIT_DIR/config. In
> >> > either case, the "latest" d2u definition wins.
> >>
> >> Yeah, that's reasonable, too. So:
> >>
> >> [alias]
> >> d2u = "!dos2unix"
> >>
> >> acts exactly as if:
> >>
> >> [alias "d2u"]
> >> command = dos2unix
> >> type = shell
> >>
> >> was specified at that point, which is easy to understand.
> >
> > It is easy to understand, and even easier to get wrong or out of sync. I
> > really liked the ease of *one* `git config` call to add new aliases.
>
> I was about to bring this up. Although to me, "git config --global
> alias.foo bar" is more convenient, but not using it is not exactly
> easy to get wrong or out of sync. For adding alias.$name.* I was
> thinking about "git config --global --edit", not executing "git
> config" multiple times.
Right, but many of my aliases get set by scripts, so your `--edit` idea
won't work for me.
> > Not sure that I like the need for more such calls just to add *one* alias (one
> > config call for "shell", one for "don't cd up", etc).
>
> We could add git-alias if more alias types pop up (and in my opinion
> git-alias is the right call, we've been abusing git-config for alias
> manipulation for a long time).
Maybe.
It is also possible that this issue is a good indicator that we are
complicating things [*1*] more than necessary...
Ciao,
Dscho
Footnote *1*:
http://thedailywtf.com/articles/The_Complicator_0x27_s_Gloves
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH/RFC] git.c: support "!!" aliases that do not move cwd
2016-10-11 9:44 ` Johannes Schindelin
2016-10-11 10:53 ` Duy Nguyen
@ 2016-10-11 15:01 ` Jeff King
2016-10-26 13:23 ` Duy Nguyen
1 sibling, 1 reply; 34+ messages in thread
From: Jeff King @ 2016-10-11 15:01 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Duy Nguyen, Johannes Sixt, Junio C Hamano, Git Mailing List
On Tue, Oct 11, 2016 at 11:44:50AM +0200, Johannes Schindelin wrote:
> > Yeah, that's reasonable, too. So:
> >
> > [alias]
> > d2u = "!dos2unix"
> >
> > acts exactly as if:
> >
> > [alias "d2u"]
> > command = dos2unix
> > type = shell
> >
> > was specified at that point, which is easy to understand.
>
> It is easy to understand, and even easier to get wrong or out of sync. I
> really liked the ease of *one* `git config` call to add new aliases. Not
> sure that I like the need for more such calls just to add *one* alias (one
> config call for "shell", one for "don't cd up", etc).
Could we simply support alias.d2u indefinitely, and you could use
whichever format you felt like (the shorter, more limited one if you
wanted, or the more verbose but flexible one)?
-Peff
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH/RFC] git.c: support "!!" aliases that do not move cwd
2016-10-11 15:01 ` Jeff King
@ 2016-10-26 13:23 ` Duy Nguyen
2016-10-26 16:08 ` Junio C Hamano
0 siblings, 1 reply; 34+ messages in thread
From: Duy Nguyen @ 2016-10-26 13:23 UTC (permalink / raw)
To: Jeff King
Cc: Johannes Schindelin, Johannes Sixt, Junio C Hamano, Git Mailing List
On Tue, Oct 11, 2016 at 10:01 PM, Jeff King <peff@peff.net> wrote:
> On Tue, Oct 11, 2016 at 11:44:50AM +0200, Johannes Schindelin wrote:
>
>> > Yeah, that's reasonable, too. So:
>> >
>> > [alias]
>> > d2u = "!dos2unix"
>> >
>> > acts exactly as if:
>> >
>> > [alias "d2u"]
>> > command = dos2unix
>> > type = shell
>> >
>> > was specified at that point, which is easy to understand.
>>
>> It is easy to understand, and even easier to get wrong or out of sync. I
>> really liked the ease of *one* `git config` call to add new aliases. Not
>> sure that I like the need for more such calls just to add *one* alias (one
>> config call for "shell", one for "don't cd up", etc).
>
> Could we simply support alias.d2u indefinitely, and you could use
> whichever format you felt like (the shorter, more limited one if you
> wanted, or the more verbose but flexible one)?
Before this thread goes completely dead... Since there's a lot more
work involved with the new alias.<name>.<property> approach (short
term would be git completion support, longer term would be the ability
to manipulate a config group more conveniently), I'm going with the
"(properties)!command" approach. But even then a new series is not
going to pop up, like, in the next two months.
I don't object the alias.<name>.<property> approach though. It's
definitely a cleaner one in my opinion. It just needs people who can
spend time to follow up until the end. But if someone decides to do
that now, I'll drop the "(properties)!command" and try to support
him/her.
--
Duy
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH/RFC] git.c: support "!!" aliases that do not move cwd
2016-10-26 13:23 ` Duy Nguyen
@ 2016-10-26 16:08 ` Junio C Hamano
0 siblings, 0 replies; 34+ messages in thread
From: Junio C Hamano @ 2016-10-26 16:08 UTC (permalink / raw)
To: Duy Nguyen
Cc: Jeff King, Johannes Schindelin, Johannes Sixt, Git Mailing List
Duy Nguyen <pclouds@gmail.com> writes:
> I don't object the alias.<name>.<property> approach though. It's
> definitely a cleaner one in my opinion. It just needs people who can
> spend time to follow up until the end. But if someone decides to do
> that now, I'll drop the "(properties)!command" and try to support
> him/her.
I don't object to either approach, but what I would love to see
people avoid is to end up with both.
Thanks.
^ permalink raw reply [flat|nested] 34+ messages in thread