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

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

 




Quoting Duy Nguyen <pclouds@xxxxxxxxx>:

On Fri, Oct 7, 2016 at 10:55 PM, Jakub Narębski <jnareb@xxxxxxxxx> wrote:
W dniu 07.10.2016 o 16:19, Johannes Schindelin pisze:
On Fri, 7 Oct 2016, Jakub Narębski wrote:

Note that we would have to teach git completion about new syntax;
or new configuration variable if we go that route.

Why would we? Git's completion does not expand aliases, it only completes
the aliases' names, not their values.

Because Git completion finds out which _options_ and _arguments_
to complete for an alias based on its expansion.

Yes, this is nice bit of trickery...

It's c63437c (bash: improve aliased command recognition - 2010-02-23)
isn't it? This may favor j6t's approach [1] because retrieving alias
attributes is much easier.

[1]
https://public-inbox.org/git/20161006190720.4ecf3ptl6msztoya@xxxxxxxxxxxxxxxxxxxxx/T/#mb1d7b8f31d595b05105b8ea2137756761e13dbf4
--
Duy

The completion script is concerned in three ways:

  1. it has to get the names of all aliases, to offer them along with
     git commands for 'git <TAB>' or 'git help <TAB>',

  2. it has to get the command executed in place of the alias, and

  3. strip everything that can't be a git command, so it can offer the
     right options for the aliased command.


The '!!' syntax is the easiest, I think it will just work even with
the current completion code, no changes necessary.

The '(nocd)' form is still easy, we only have to add this '(nocd)' to
that list of stripped words for (3), but no further changes necessary
for (1) and (2).

'alias.d2u.command' is tricky.  Both (1) and (2) require adjustments,
preferably in a way that doesn't involve additional git processes, at
least for (1), as it is executed often, for every 'git <TAB>', for the
sake of users on platforms with not particularly stellar fork()+exec()
performance.  I think it would be possible to have only one 'git
config --get-regexp' and a little bit of post processing in each case,
but I didn't think too hard about possible pitfalls, especially when
dealing with ambiguity when both 'alias.d2u' and 'alias.d2u.command'
are set.  And I won't think any more about it until a conclusion is
reached that we'll go this route :)





[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]