RE: [feature request] git add completion should exclude staged content

From: Marc Khouzam <marc.khouzam@ericsson.com>
Date: Jan 30, 2013, 18:55 UTC
Message-ID: <E59706EF8DB1D147B15BECA3322E4BDC097E39@eusaamb103.ericsson.se>
In-Reply-To: <51096543.9050100@gmail.com>

Show 44 quoted lines

> -----Original Message-----
> From: git-owner@vger.kernel.org 
> [mailto:git-owner@vger.kernel.org] On Behalf Of Manlio Perillo
> Sent: Wednesday, January 30, 2013 1:24 PM
> To: Marc Khouzam
> Cc: 'Junio C Hamano'; 'Michael J Gruber'; 'wookietreiber'; 
> 'git@vger.kernel.org'
> Subject: Re: [feature request] git add completion should 
> exclude staged content
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Il 30/01/2013 15:06, Marc Khouzam ha scritto:
> > [...]
> >> I will try to update the patch, with your latest suggestions (avoid
> >> tricky POSIX shell syntax, and CDPATH issue - if I remember 
> >> correctly),
> >> and with an update for the t/t9902-completion.sh test (that I 
> >> completely
> >> missed).
> > 
> > Hi Manlio,
> > 
> 
> Hi.
> 
> > I'm trying to update git-completion.tcsh to work properly with
> > your nice new completion feature.  But I'm having trouble with 
> > the missing '/' at the end of directories.
> > 
> > The new logic in git-completion.bash tells bash that 'filenames'
> > completion is ongoing so bash will add a '/' after directories.
> > Sadly, tcsh won't do that, so it would be simpler if
> > git-completion.bash added the '/' itself.  I looked at the 
> > git-completion.bash script changes and I noticed that for 
> > bash version < 4, you have to add the '/' yourself.
> 
> The compatible version is not only required for Bash; you can 
> use it for
> other shells.
> 
> Try to redefine the __git_index_file_list_filter function to use the
> version that adds a slash to directory names.

I hadn't thought of that! Although I would prefer not to have special cases like that, it does work well. Thanks!

Show 40 quoted lines

> > I also noticed the following comment:
> > 
> >  # XXX if we append a slash to directory names when using
> >  # `compopt -o filenames`, Bash will append another slash.
> >  # This is pretty stupid, and this the reason why we have to
> >  # define a compatible version for this function.
> > 
> > So I gather you would rather add a '/' all the time to deal
> > with older bash version transparently.  This would be great
> > for tcsh also.  I'm trying to figure out
> > when bash mis-behaves when you add the '/' all the time?
> > When I try it (I have bash 4.1.5(1)-release) I didn't run
> > into the double slash problem you mention in the comment.
> > 
> 
> I'm using the same version: 4.1.5(1), on Debian stable.
> 
> > I'm hoping we can straighten this out and have
> > git-completion.bash add the '/' all the time.
> > 
> > Could you explain when the problem happens?
> > 
> 
> Bash 4.1.5(1) always adds an additional slash for directories.
> I have tested it right now: change the filter function to use the
> compatible version:
> 
> __git_index_file_list_filter ()
> {
> 	# Default to Bash >= 4.x
> 	__git_index_file_list_filter_compat
> }
> 
> 
> Then running `git add <TAB>` inside the git repository, I get 
> this file
> completion list:
> 
> $ git add <TAB>
> contrib//

Ok, I see.  The double-slash is visible in the completion list
but it does not appear on the command-line when bash automatically
adds it.  So if you typed 
  git add contri<tab>
you will properly get
  git add contrib/
That is the case I was looking at.
I understand why you cannot put that second slash in the code now.

Thanks

Show 22 quoted lines

> 
> 
> > Thanks
> > 
> 
> 
> Thanks to you
> 
> Manlio
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAlEJZUMACgkQscQJ24LbaUQUGACgkMG/bZrJKBzlZ8toEQwmggQX
> m9kAn2ATJbSp87kOkoCCc00eHmh71r3y
> =D9iu
> -----END PGP SIGNATURE-----
> --
> 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
>