Re: [PATCH/RFC] git.c: support "!!" aliases that do not move cwd

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Oct 7, 2016 at 7:47 PM, Matthieu Moy
<Matthieu.Moy@xxxxxxxxxxxxxxx> wrote:
> Duy Nguyen <pclouds@xxxxxxxxx> writes:
>
>> On Fri, Oct 7, 2016 at 6:20 PM, Johannes Schindelin
>> <Johannes.Schindelin@xxxxxx> wrote:
>>> Hi Junio,
>>>
>>> On Thu, 6 Oct 2016, Junio C Hamano wrote:
>>>
>>>> Nguyễn Thái Ngọc Duy  <pclouds@xxxxxxxxx> 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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]