Re: [ANN] Pro Git Reedited 2nd Edition

[Manlio Perillo]

On Sun, Jul 24, 2016 at 6:07 AM, Jon Forrest  wrote:
> This an announcement of Pro Git Reedited 2nd Edition, which is
> a substantial edit of Chacon and Straub's Pro Git 2nd Edition.
> I spent a lot of time tightening it up and maybe clearing
> up some explanations.
>
> The pdf is downloadable at:
> https://drive.google.com/open?id=0B-Llso12P94-Ujg5Z1dhWUhhMm8
>

Thanks for your work.

I have noted a problem when reading the PDF with Chromium: the
anchors/links do not work.

I don't know if this is an issue with the conversion to PDF or an
issue with Chromium.


Manlio
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Git-p4 fails with NameError with python 2.7.2

[Manlio Perillo]

On Tue, Oct 20, 2015 at 6:00 PM, Junio C Hamano  wrote:
>
> Luke Diamand  writes:
>
> > On 20 October 2015 at 11:34, Etienne Girard  
> > wrote:
> >> Hello,
> >>
> >> Git-p4 fail when I try to rebase with the error: "NameError: global
> >> name 'ctypes' is not defined". The error occurs when I use python
> >> 2.7.2 that is installed by default on my company's computers (it goes
> >> without saying that everything works fine with python 2.7.10).
> >>
> >> I'm a beginner in python, but simply importing ctypes at the beginning
> >> of the script does the trick. I was wondering if submitting a patch
> >> for this issue is worth the trouble, when a satisfying solution is not
> >> using a 4 years old version of python.
> >
> > If you're able to submit a patch that would be great!
>
> Lars's 4d25dc44 (git-p4: check free space during streaming,
> 2015-09-26) introduced two references to ctypes.* and there is no
> 'import ctypes' anywhere in the script.
>
> I do not follow Python development, but does the above mean that
> with recent 2.x you can say ctypes without first saying "import
> ctypes"?


No.
You need to import the ctypes  module.

However in Python it is possible to "inject" the ctypes module (and
any other name) in the builtin namespace.
The builtin module contains names that are accessible without importing them:
https://docs.python.org/2/library/__builtin__.html

IMHO, some code  is messing with the __builtin__ module.

Running pyflakes on git-p4.py code I get:
git-p4.py:26: 'zlib' imported but unused
git-p4.py:640: local variable 'v' is assigned to but never used
git-p4.py:2114: local variable 'rhs_index' is assigned to but never used

Running pylint I get a **lot** of warning and style issues; and the
following errors:
E:112,21: Undefined variable 'ctypes' (undefined-variable)
E:113, 8: Undefined variable 'ctypes' (undefined-variable)
E:113,51: Undefined variable 'ctypes' (undefined-variable)
E:113,94: Undefined variable 'ctypes' (undefined-variable)
E:1002,51: No value for argument 'contentFile' in method call
(no-value-for-parameter)

pyflakes is not reporting an error for ctypes.
Whatever the cause, the code must be fixed to import the ctypes module.

P.S.:
Sorry for the double message.
The first message contained an HTML part and was rejected by vger.kernel.org.


Regards  Manlio
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/11] completion: general cleanups

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 27/04/2013 12:19, Felipe Contreras ha scritto:
 Hi,
 
 Basically while trying to understand the code for path completion, I found 
 that
 a lot of code was duplicated, and for not much gain.
 
 I also noticed that doing 'git add file' doesn't add the trailing space as
 before. It's not clear if it should be possible to do that with -o filenames,
 but after all, what do -o filenames gives us? Nothing we can't do ourselves,
 apparently.
 

No, you can not do it yourself, as far as I know.

I added the `compopt -o filenames` on Junio request for something like
It  would be nice if completion for real files would behave like
builtin bash completion, if I remember correctly.

Try `git rm contrib/completion/TAB`, in the git reporitory.

Using the new feature, bash will suggest:
git-completion.bash  git-completion.tcsh  git-completion.zsh
git-prompt.sh

Old behaviour, instead, was to suggest:
contrib/completion/git-completion.bash
contrib/completion/git-completion.zsh
contrib/completion/git-completion.tcsh  contrib/completion/git-prompt.sh

I tried several things, but I was unable to emulate Bash builtin file
completion, whithout having to use `compopt -o filenames`.



As far as the double slash problem with the
__git_index_file_list_filter_bash function, please try
`git rm contribTAB`.

With current code, Bash will suggest:
blameview/ diffall/ git-shell-commands/

If you remove the __git_index_file_list_filter_bash function and use
__git_index_file_list_filter_compat instead, Bash will suggest:

blameview// diffall// git-shell-commands//

I can confirm this on my system, and it was confirmed by another user.
It only happens when you use `compopt -o filenames`. I don't know if
this is a bug or a feature, but I can try to ask to Bash mailing list,
so that we can update the comment to make more clear why a separate
function was needed.


 [...]


Regards  Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlF7t5gACgkQscQJ24LbaUSO5QCffllxM8RbGUP47kb7uL5J3drF
hkUAn26ezKptTAC412EJZnxjh7RVcdAO
=Piyz
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/11] completion: general cleanups

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 27/04/2013 21:15, Felipe Contreras ha scritto:
 [...]
 @@ -480,7 +481,7 @@ __git_complete_revlist_file ()
  # The exception is --committable, which finds the files appropriate commit.
  __git_complete_index_file ()
  {
 -   local pfx= cur_=$cur
 +   local pfx= cur_=$cur old

 case $cur_ in
 ?*/*)
 @@ -490,7 +491,8 @@ __git_complete_index_file ()
 ;;
 esac

 -   __gitcomp_nl $(__git_index_files $1 $pfx) $pfx $cur_ 
 +   compopt -o filenames +o nospace 2 /dev/null || old=1
 +   __gitcomp_nl $(__git_index_files $1 $pfx $old) $pfx 
 $cur_ 
  }

  __git_complete_file ()


 I like the idea (but I have not tested it), however compopt is called
 two times, for each completion.
 
 Why two times?

Ah, right; sorry.
I missed the fact that you are using __gitcomp_nl instead of my
__gitcomp_file.

 
 Maybe we can test for `-o filenames` support when script is loaded,
 where currently there is a Bash version check, and set a global variable?
 
 Yeah, that's the way bash-completion used to do it. But I wonder if we
 should be worrying about this at this point, even bash-completion
 dropped support for bash  4 more than two years ago, and even debian
 stable is at 4.1.
 

I'm +0.

 [...]


Regards  Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlF8MVsACgkQscQJ24LbaUSY/wCgkq8CQeVGNpZFtchiLAKXYpxS
wsAAnR0abrQzA1jW+Do7CSuJOZVMRuJu
=zPgk
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5] git-completion.bash: add support for path completion

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 21/04/2013 12:14, Felipe Contreras ha scritto:
 On Fri, Jan 11, 2013 at 12:48 PM, Manlio Perillo
 manlio.peri...@gmail.com wrote:
 The git-completion.bash script did not implemented full, git aware,
 support to complete paths, for git commands that operate on files within
 the current working directory or the index.
 
 +__git_index_file_list_filter_compat ()
 +{
 +   local path
 +
 +   while read -r path; do
 +   case $path in
 +   ?*/*) echo ${path%%/*}/ ;;
 +   *) echo $path ;;
 +   esac
 +   done
 +}
 +
 +__git_index_file_list_filter_bash ()
 +{
 +   local path
 +
 +   while read -r path; do
 +   case $path in
 +   ?*/*)
 +   # 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.
 +   echo ${path%%/*} ;;
 
 Which version of bash is that? It works perfectly fine here with or
 without the /.
 

GNU bash, version 4.1.5(1)-release (i486-pc-linux-gnu)
on a GNU Linux Debian 6

 +# __git_index_files accepts 1 or 2 arguments:
 +# 1: Options to pass to ls-files (required).
 +#Supported options are --cached, --modified, --deleted, --others,
 +#and --directory.
 +# 2: A directory path (optional).
 +#If provided, only files within the specified directory are listed.
 +#Sub directories are never recursed.  Path must have a trailing
 +#slash.
 +__git_index_files ()
 +{
 +   local dir=$(__gitdir) root=${2-.}
 +
 +   if [ -d $dir ]; then
 +   __git_ls_files_helper $root $1 | 
 __git_index_file_list_filter |
 +   sort | uniq
 +   fi
 +}
 +
 +# __git_diff_index_files accepts 1 or 2 arguments:
 +# 1) The id of a tree object.
 +# 2) A directory path (optional).
 +#If provided, only files within the specified directory are listed.
 +#Sub directories are never recursed.  Path must have a trailing
 +#slash.
 +__git_diff_index_files ()
 +{
 +   local dir=$(__gitdir) root=${2-.}
 +
 +   if [ -d $dir ]; then
 +   __git_diff_index_helper $root $1 | 
 __git_index_file_list_filter |
 +   sort | uniq
 +   fi
 +}
 
 These two are exactly the same, except one calls
 __git_ls_files_helper, and the other one __git_diff_index_helper,
 can't we make another argument that is and select one or the other
 based on that?
 

They are not exactly the same.

The first function requires, as first parameter, (space separed) options
to pass to ls-files command; the second function, instead, requires the
id of a tree object.

IMHO, using only one function may be confusing.

  __git_heads ()
  {
 local dir=$(__gitdir)
 @@ -430,6 +543,46 @@ __git_complete_revlist_file ()
  }


 +# __git_complete_index_file requires 1 argument: the options to pass to
 +# ls-file
 +__git_complete_index_file ()
 +{
 +   local pfx cur_=$cur
 +
 +   case $cur_ in
 +   ?*/*)
 +   pfx=${cur_%/*}
 +   cur_=${cur_##*/}
 +   pfx=${pfx}/
 +
 +   __gitcomp_file $(__git_index_files $1 $pfx) $pfx 
 $cur_
 +   ;;
 +   *)
 +   __gitcomp_file $(__git_index_files $1)  $cur_
 +   ;;
 +   esac
 +}
 +
 +# __git_complete_diff_index_file requires 1 argument: the id of a tree
 +# object
 +__git_complete_diff_index_file ()
 +{
 +   local pfx cur_=$cur
 +
 +   case $cur_ in
 +   ?*/*)
 +   pfx=${cur_%/*}
 +   cur_=${cur_##*/}
 +   pfx=${pfx}/
 +
 +   __gitcomp_file $(__git_diff_index_files $1 $pfx) 
 $pfx $cur_
 +   ;;
 +   *)
 +   __gitcomp_file $(__git_diff_index_files $1)  $cur_
 +   ;;
 +   esac
 +}
 
 These are also exactly the same, we could pass the argument to the
 function above.
 

See previous note.



Regards  Manlio Perillo
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlF2p+QACgkQscQJ24LbaUQVcACfeYFO8umJDbgTrXWChqqbk69E
CE4AniZFP7PQkOZCbBY+6hZ2gMpNIJTn
=HqAf
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: zsh completion broken for file completion

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 01/04/2013 11:29, Felipe Contreras ha scritto:
 
 
 On Thu, Feb 28, 2013 at 12:59 PM, Manlio Perillo
 manlio.peri...@gmail.com mailto:manlio.peri...@gmail.com wrote:
 
 
 [1] Basically, on my system I need the following change at the end of
 the file:
 
 -_git
 +autoload -U +X compinit  compinit
 +compdef _git git gitk
 
 I don't know the reason, however; and it seems that it is a problem
 only for me
 
 
 Are you sourcing this script? If so, don't; do what is suggested at the
 top: use fpath to load it automatically.
 

I'm using fpath as documented.

However I tested the script again, and now seems to work correctly.
It is possible that in the past I was using an incorrect configuration.


Thanks   Manlio Perillo
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlFa01IACgkQscQJ24LbaUQOmACghDC30GqXXPIExHOPl9HrrO1y
BYgAn2QPAYvtsSAAiPpgMnmMRI3z0LE8
=kmm0
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ZSH segmentation fault while completing git mv dir/

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 02/04/2013 16:32, Matthieu Moy ha scritto:
 Felipe Contreras felipe.contre...@gmail.com writes:
 
 And this is a workaround:

 --- a/contrib/completion/git-completion.zsh
 +++ b/contrib/completion/git-completion.zsh
 @@ -66,7 +66,7 @@ __gitcomp_file ()

 local IFS=$'\n'
 compset -P '*[=:]'
 -   compadd -Q -p ${2-} -f -- ${=1}  _ret=0
 +   compadd -Q -p ${2-} -- ${=1}  _ret=0
  }
 
 OK, not something we want to apply to git.git, but this means a
 workaround for users is to create a _git file with this content instead
 instead of copying/symlinking git-completion.zsh as _git (replace
 $GIT_ROOT_PATH with the appropriate value)

By the way: have you filled a bug report to Debian?


Regards  Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlFbRasACgkQscQJ24LbaUTDZQCfbfF5yhxCfUSaWdv0pE7++X3l
Lc0AniAw5lEL6iunM+Tw8HvYxGwjuYYh
=KpQI
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ZSH segmentation fault while completing git mv dir/

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 11/03/2013 13:30, Matthieu Moy ha scritto:
 Hi,
 
 Since the recent update to bash completion, I often get a segmentation
 fault from ZSH. This is most likely a bug in ZSH, but it would be cool
 to avoid triggering it from Git.
 
 [...]
 moy@anie:~$ zsh --version
 zsh 4.3.10 (i686-pc-linux-gnu)
 
 (this is ZSH packaged with Debian stable)
 

I have the same system, but I can't reproduce the problem.
What is the content of your .zshrc file?


Regards  Manlio Perillo
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlE99NAACgkQscQJ24LbaURIwgCbB9HmepRfvTqN2vh6H5/Ew7Mw
WQMAn3CSiFViQ7j62fuBVKg6WJK+Yg/0
=j4FV
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH] git-completion.bash: remove bashism to fix ZSH compatibility

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 11/03/2013 17:17, Junio C Hamano ha scritto:
 Matthieu Moy matthieu@imag.fr writes:
 
 The function-wide redirection used for __git_ls_files_helper and
 __git_diff_index_helper work only with bash. Using ZSH, trying to
 complete an inexistant directory gave this:

   git add no-such-dir/__git_ls_files_helper:cd:2: no such file or directory: 
 no-such-dir/

 Signed-off-by: Matthieu Moy matthieu@imag.fr
 ---
 
 This is not bash-ism but POSIX.1, even though it is not very well
 known.  I recall commenting on this exact pattern during the review.
 

Yes, I was plainning to send another patch to fix this (and your other
suggestion regarding the CDPATH environment variable, if I remember
correctly), but I was busy with other things; sorry.



 [...]


Regards  Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlE+D7QACgkQscQJ24LbaURBTgCffpMCPjmcsP53/WE/VIQ2FIIc
fiIAn3obBJ1yrHVUEmslz32ezvESCZ4G
=7nia
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH] git-completion.bash: remove bashism to fix ZSH compatibility

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 11/03/2013 18:01, Junio C Hamano ha scritto:
 [...]
 Having to restrict to the common subset means that whenever bash
 adds new and useful features that this script could take advantage
 of to improve the user experience, they cannot be employed until zsh
 catches up (and worse yet, it is outside the control of this script
 if zsh may ever catch up in the specific feature).
 

Maybe, to avoid this problem and code duplication (the main reason bash
script is sourced, as far as I can tell), it may be useful to add
additional reusable git commands, for use in shell completion?

E.g:
git suggest cmd *args

returns a line separed list of filenames affected by cmd.



Regards  Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlE+EJkACgkQscQJ24LbaURjNwCfdW73fET/n4FRGftKcSJPsK7M
nu4An1CC0dspGxLe5zqR9BdXBBDHWl/Y
=11j7
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH] git-completion.bash: remove bashism to fix ZSH compatibility

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 11/03/2013 19:09, Junio C Hamano ha scritto:
 Matthieu Moy matthieu@grenoble-inp.fr writes:
 
 Junio C Hamano gits...@pobox.com writes:

 Ahh, thanks for reminding me of this.  You are right; these two
 functions are broken when the user has CDPATH set, I think.

 Here is a reroll.

 Thanks. Even nicer that the previous since the CDPATH implied the
 subshell anyway.
 
 Actually, cd, not CDPATH, is what implies that the caller must be
 calling us in a subshell, e.g.
 
   result=$(__git_ls_files_helper dir/ args...)
 
 Otherwise the user's shell would have been taken to an unexpected
 place, with or without CDPATH.
 

Right; this is the reason I used the `{` grouping, instead of `(`.

However, since the `{` is already specified when the function is
defined, I did not add another `{}` grouping.

 [...]


Regards  Manlio Perillo
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlE+K/4ACgkQscQJ24LbaUQqvwCgmReHb4VtMJDT+tv+XF9RPmXE
DlEAnjhsgXszSBVG1iW0WCLM6212+fdA
=SYzh
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ZSH segmentation fault while completing git mv dir/

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 11/03/2013 16:37, Matthieu Moy ha scritto:
 [...]
 I could reproduce with ~/.zshrc containing just:
 
 --
 fpath=(${HOME}/usr/etc/zsh ${fpath})
 
 autoload -Uz compinit
 compinit
 
 eval `dircolors`
 zstyle ':completion:*' list-colors ${(s.:.)LS_COLORS}
 --
 
 ${HOME}/usr/etc/zsh contains two links _git and git-completion.bash
 pointing to Git's completion scripts in contrib/.
 

Using this configuration I still can't reproduce the problem, using
git v1.8.2-rc3-8-g0c91a6f.

But I'm not a zsh expert.



Regards   Manlio Perillo

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlE+MZAACgkQscQJ24LbaUSTuACfYmZV9cvroPzBUdJspw9abh24
fk8AnRTjvCEJ3m8Y2m/5jCIVVNsJAcG7
=5p6c
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: zsh completion broken for file completion

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 28/02/2013 19:43, Matthieu Moy ha scritto:
 Hi,
 
 The completion for e.g. git add filetab is broken in master. I get
 the following result:
 
 git add fo__gitcomp_file:8: command not found: compgen
 
 The guilty commit is fea16b47b60 (Fri Jan 11 19:48:43 2013, Manlio
 Perillo, git-completion.bash: add support for path completion), which
 introduces a new __gitcomp_file function that uses the bash builtin
 compgen, without redefining the function in git-completion.zsh.
 
 [...] 
 diff --git a/contrib/completion/git-completion.zsh 
 b/contrib/completion/git-completion.zsh
 index 4577502..0ba1dcf 100644
 --- a/contrib/completion/git-completion.zsh
 +++ b/contrib/completion/git-completion.zsh
 @@ -60,6 +60,15 @@ __gitcomp_nl ()
 compadd -Q -S ${4- } -p ${2-} -- ${=1}  _ret=0
  }
  
 +__gitcomp_file ()
 +{
 +   emulate -L zsh
 +
 +   local IFS=$'\n'
 +   compset -P '*[=:]'
 +   compadd -Q -p ${2-} -- ${=1}  _ret=0
 +}
 +

This patch is implemented in fea16b47b60, but only for the deprecated
zsh compatibility code inside git-completion.bash.

The reason I did not provided a patch for git-completion.zsh was because
there was a bug in this script [1].

If any changes are made to git-completion.zsh, please update
git-completion.bash, too.


[1] Basically, on my system I need the following change at the end of
the file:

-_git
+autoload -U +X compinit  compinit
+compdef _git git gitk

I don't know the reason, however; and it seems that it is a problem
only for me

 [...]


Regards  Malio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlEvqRUACgkQscQJ24LbaURASgCeILUTXAiZA6Ndf2DHByJfv4nT
2bMAn1gPqSdfIBzb0cexwYNoAuD5j2+O
=sKTR
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Handle path completion and colon for tcsh script

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 02/02/2013 21:10, Junio C Hamano ha scritto:
 Marc Khouzam marc.khou...@ericsson.com writes:
 
 Recent enhancements to git-completion.bash provide
 intelligent path completion for git commands.  Such
 completions do not add the '/' at the end of directories
 for recent versions of bash.
 ...
 Here is the update for tcsh completion which is needed to handle
 the cool new path completion feature just pushed to 'next'.

 [...]
 But I have to wonder if this is sweeping a problem under the rug.
 Shouldn't the completion for bash users end completed directory name
 with '/', even if we didn't have to worry about tcsh?
 

The problem is that when using the new
`compopt -o filenames` command, Bash assumes COMPREPLY contains a list
of filenames, and when it detects a directory name, it adds a slash.

The problem is, if the directory name *already* has a slash, Bash adds
another slash!

I don't know if this can be considered a bug or a feature.


Regards  Manlio

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlEOwaQACgkQscQJ24LbaUSjwgCfbgb1id5DcNG0Q75FWwgNPCqb
qkUAnAmMzCahB745/BWeDJTHbJFXucxs
=vf+P
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Manlio Perillo]

-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 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//


 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 30/01/2013 19:55, Marc Khouzam ha scritto:
 [...]
 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.

The zsh compatible code does something like this; this is the reason I
tried to do the same thing, in order to keep coding consistent.

 [...]

 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.

Right; that's why I wrote in the comment that Bash behaviour seems stupid.
But probably that comment should be remove or changed for the final
version of the patch; I'll leave that to a Bash expert.

 [...]


Regards  Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlEJe0kACgkQscQJ24LbaUScGgCeMDDdprJMgnYtFzqnFQamhfvU
BikAniMkwbOEVkkomOd9G0m3KY44f/9O
=c8rC
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 28/01/2013 00:00, Junio C Hamano ha scritto:
 wookietreiber kizkizzbangb...@googlemail.com writes:
 
 I have a feature request for `git add` auto completion:

 `git add` auto completion suggests all files / directories,
 filtered by nothing. I guess it would be much nicer (as in
 increasing productivity) if it would only suggest unstaged
 content, as reported by `git status`, because that would be the
 only content one would be able to add.
 
 I think that is what Manlio Perillo tried to do with the stalled
 mp/complete-paths topic that is queued in 'pu'.
 
 Manlio, any progress?

Well, I assumed that the patch was stalled due to missing review from
git completion experts...

For this reason I have not updated it with your latest suggestions,
waiting for the review (also, because now I'm busy with other projects).

For the OP: the last patch can be found in the mailing list archive,
with the subject:
[PATCH v5] git-completion.bash: add support for path completion
and date:
Fri, 11 Jan 2013 19:48:43 +0100

Can you please test it?




Regards   Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlEGRE8ACgkQscQJ24LbaUSX9ACfUMBH/X6lVH4V7FUaB2wlqj8C
eYQAnAzuYwhYhDvkW3d29IeqHsDFyWBT
=BpRi
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 28/01/2013 13:52, Michael J Gruber ha scritto:
 Manlio Perillo venit, vidit, dixit 28.01.2013 10:26:
 Il 28/01/2013 00:00, Junio C Hamano ha scritto:
 wookietreiber kizkizzbangb...@googlemail.com writes:

 I have a feature request for `git add` auto completion:

 [...]
 For the OP: the last patch can be found in the mailing list archive,
 with the subject:
  [PATCH v5] git-completion.bash: add support for path completion
 and date:
  Fri, 11 Jan 2013 19:48:43 +0100

 Can you please test it?

 
 I haven't looked at the patch, but in the example above, untracked
 files) could be added as well (unless you use -u), so maybe the scope
 should depend on the option? If the new completion code kept me from
 adding untracked files easily it wouldn't be an improvement.
 

The patch will suggest (for git add command), all the files that are
candidate to be added to the index file.

Please, test it and report any behaviour you think is incorrect.


Regards   Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlEGhPsACgkQscQJ24LbaUTYOwCdFagTRkHzUHoFwy3U+Vz6tAzE
tVIAnj8fAbyGrlNUoUgI4ZshwOtlEH8v
=jy8R
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 28/01/2013 17:22, Michael J Gruber ha scritto:
 [...]
 The patch will suggest (for git add command), all the files that are
 candidate to be added to the index file.

 Please, test it and report any behaviour you think is incorrect.
 
 OK, that seems to work and to be quite helpful.
 
 Minor nit: git add -u could use the same fileset as git commit. But
 I don't know whether completion can act upon the presence of options.

It is possible, but I have not implemented since I was not sure about it
and I wanted to avoid to make the patch more hard to review.

I will work on it after the patch is approved.

 Currently, it also includes untracked files (just like without -u) but
 omits unmodified and ignored ones, which is already quite an improvement.
 
 I won't be able to review the completion code but may contribute a few
 lines to t/t9902-completion.sh, possibly.
 

Ah, I missed this test; thanks.

The proposed patch must update it.



Regards  Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlEG2+UACgkQscQJ24LbaURstACfdNxuFvaokBSTls20bSQ7jPHA
8I0An3fX6oRKuc2lzAgPVBLjsbjbw91V
=igwr
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 28/01/2013 18:52, Junio C Hamano ha scritto:
 [...]
 
 Thanks both for commenting.  I'll find time to read it over again
 and perhaps we can merge it to 'next' and advertise it in the next
 issue of What's cooking report to ask for wider testing to move it
 forward.

Thanks.

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).



Regards  Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlEG3IcACgkQscQJ24LbaUTR/wCfSC/kHxseKAQ9rnK2ba/WwND1
cmsAn2CuHpRs2VjippTwkT5O3ul9cQKb
=5Way
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5] git-completion.bash: add support for path completion

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 11/01/2013 19:48, Manlio Perillo ha scritto:
 The git-completion.bash script did not implemented full, git aware,
 support to complete paths, for git commands that operate on files within
 the current working directory or the index.
 [...]
  
 +# Try to count non option arguments passed on the command line for the
 +# specified git command.
 +# When options are used, it is necessary to use the special -- option to
 +# tell the implementation were non option arguments begin.
 +# XXX this can not be improved, since options can appear everywhere, as
 +# an example:
 +#git mv x -n y
 +#
 +# __git_count_arguments requires 1 argument: the git command executed.
 +__git_count_arguments ()
 +{
 + local word i c=0
 +
 + # Skip git (first argument)
 + for ((i=1; i  ${#words[@]}; i++)); do
 + word=${words[i]}
 +
 + case $word in
 + --)

Sorry, I have incorrectly (again) indented the case labels.
I have now configured my editor to correctly indent this.

 + # Good; we can assume that the following are 
 only non
 + # option arguments.
 + ((c = 0))
 + ;;

Here I was thinking to do something like this (not tested):

-*)
if [ -n ${2-} ]; then
# Assume specified git command only
# accepts simple options
# (without arguments)
((c = 0))

Since git mv only accepts simple options, this will make the use of '--'
not required.

Note that I'm assuming the single '-' character is used as a non-option
argument; not sure this is the case of Git.

 [...]


Regards  Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlDxXLkACgkQscQJ24LbaUR+QQCaA4WZP5h5lktXJqSB7c494fAY
B6IAoIRWyIzBq29S7+l+TfRjbyp19HNL
=JRpR
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5] git-completion.bash: add support for path completion

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 11/01/2013 23:02, Junio C Hamano ha scritto:
 Manlio Perillo manlio.peri...@gmail.com writes:
 
 +# Process path list returned by ls-files and diff-index --name-only
 +# commands, in order to list only file names relative to a specified
 +# directory, and append a slash to directory names.
 +__git_index_file_list_filter ()
 +{
 +# Default to Bash = 4.x
 +__git_index_file_list_filter_bash
 +}
 +
 +# Execute git ls-files, returning paths relative to the directory
 +# specified in the first argument, and using the options specified in
 +# the second argument.
 +__git_ls_files_helper ()
 +{
 +# NOTE: $2 is not quoted in order to support multiple options
 +cd $1  git ls-files --exclude-standard $2
 +} 2/dev/null
 
 I think this redirection is correct but a bit tricky;

It's not tricky: it is POSIX:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_10


 it is in
 effect during the execution of the { block } (in other words, it is
 not about squelching errors during the function definition).
 

What do you mean by squelching?

Note that I originally wrote the code as

__git_ls_files_helper ()
{
# NOTE: $2 is not quoted in order to support multiple options
 { cd $1  git ls-files --exclude-standard $2 } 2/dev/null
}

but then I checked the POSIX standard, noting that it is redundant.

 -- 8 --
 #!/bin/sh
 cat t.sh \EOF 
 echo I am $1
 t () { echo Goes to stdout; echo 2 Goes to stderr; } 2/dev/null
 t
 for sh in bash dash ksh zsh
 do
   $sh t.sh $sh
 done
 -- 8 --
 

There is a missing EOF delimiter.
And I'm not sure to understand the meaning of  after EOF.

 Bash does (so do dash and real ATT ksh) grok this correctly, but
 zsh does not seem to (I tried zsh 4.3.10 and 4.3.17; also zsh
 pretending to be ksh gets this wrong as well).  Not that what ksh
 does matters, as it won't be dot-sourcing bash completion script.


I have added tcsh to the sh list, but it fails with:
Badly placed ()'s.


 It however may affect zsh, which does seem to dot-source this file.
 Perhaps zsh completion may have to be rewritten in a similar way as
 tcsh completion is done (i.e. does not dot-source this file but ask
 bash to do the heavy-lifting).
 

Ok, I was wrong on assuming all modern shells were POSIX compliant.
I will change the code to use a nested {} group.

 This function seems to be always called in an subshell (e.g. as an
 upstream of a pipeline), so the cd may be harmless, but don't you
 need to disable CDPATH while doing this?
 

I don't know.

 [..]


 +# Try to count non option arguments passed on the command line for the
 +# specified git command.
 +# When options are used, it is necessary to use the special -- option to
 +# tell the implementation were non option arguments begin.
 +# XXX this can not be improved, since options can appear everywhere, as
 +# an example:
 +#   git mv x -n y
 
 If that is the case, it is a bug in the command line parser, I
 think.  We should reject it, and the command line completer
 certainly should not encourage it.
 

$ mkdir y
$ git mv x -n y
Checking rename of 'x' to 'y/x'
Renaming x to y/x
$ git status
# On branch master
nothing to commit, working directory clean

I was assuming it to be normal, given how complex Git command line
parsing is (IMHO).


Thanks  Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlDxeMgACgkQscQJ24LbaUTmaQCeMbZ0lRJxZIx3U31gMPmcqTLp
54sAmwYrjJVuvRYcsbGaMa3rb9/EKrBU
=ky30
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

git-completion.bash should not add a space after a ref

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi.

This is not really a bug, but a small usability problem.

When completing a reference, Bash will add a space after the reference name.

As an example in:

$git show masterTAB

The problem is that an user may want to show a tree or blog object from
master:

$git show master:git.c


A possible solution is to define a new __gitcomp_nospace function and
use it where appropriate.

Probably the __gitcomp_nospace should be used when git_complete_file is
called, and __gitcomp_nl should be used when __git_complete_revlist  is
called, but I'm not sure.

P.S.:
it seems that __gitcomp_nl is **never** called with 4 arguments.



Regards  Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlDxrQ8ACgkQscQJ24LbaURHmACfRXoM+uEVDgFUtZFzUcPC5oSZ
FGsAnAxQf+SN7GrNljxU1io4IuayHmed
=JRVU
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5] git-completion.bash: add support for path completion

[Manlio Perillo]

The git-completion.bash script did not implemented full, git aware,
support to complete paths, for git commands that operate on files within
the current working directory or the index.

As an example:

git add TAB

will suggest all files in the current working directory, including
ignored files and files that have not been modified.

Support path completion, for git commands where the non-option arguments
always refer to paths within the current working directory or the index,
as follows:

* the path completion for the git rm and git ls-files
  commands will suggest all cached files.

* the path completion for the git add command will suggest all
  untracked and modified files.  Ignored files are excluded.

* the path completion for the git clean command will suggest all
  untracked files.  Ignored files are excluded.

* the path completion for the git mv command will suggest all cached
  files when expanding the first argument, and all untracked and cached
  files for subsequent arguments.  In the latter case, empty directories
  are included and ignored files are excluded.

* the path completion for the git commit command will suggest all
  files that have been modified from the HEAD, if HEAD exists, otherwise
  it will suggest all cached files.

For all affected commands, completion will always stop at directory
boundary.  Only standard ignored files are excluded, using the
--exclude-standard option of the ls-files command.

When using a recent Bash version, Git path completion will be the same
as builtin file completion, e.g.

git add contrib/

will suggest relative file names.

Signed-off-by: Manlio Perillo manlio.peri...@gmail.com
---

Changes:

* Applied Junio patch to fix completion inside a subdirectory.
* Quoted the hopefully last incorrectly unquoted variable.
* Fixed coding style (removed stdout file descriptor in shell
  redirection, since it is redundant).
* Fixed regression in path completion, when using non canonicalized
  or absolute path names.
  The problem has been solved making sure to chdir to the specified
  directory before executing ls-files and diff-index commands.

  The only issue is that there is no tilde expansion, but this is
  harmless, since default bash completion will be used (the old
  behaviour).
* Improved path completion when the new compopt builtin is available
  (Bash = 4.x).
  Now git paths completion is done in exactly the same way as Bash
  builtin filenames completion.
* Updated the zsh compatibility code to use the improved path
  completion support
* Fixed incorrect git mv arguments count used to check the first
  path to be renamed.
  When options are used (unless they are git main options), -- is
  required to separate options from non options arguments.
  It is harmless to not use --; in this case bash will suggest
  untracked files and directories for the first argument.

  XXX: should I add this implementation note in the commit message?
* Make sure to sort ls-files and diff-index filtered output before
  removing duplicate directories.
* Merged master.
 
Please note that before merging this patch in next, we need to update the
zsh and tcsh completion scripts.
I have the changes ready, but I will post them later since both scripts
needs more patches (I have posted an informal patch for zsh, and changes
to tcsh should be in pu, but I need to test them).

 contrib/completion/git-completion.bash | 250 ++---
 1 file changed, 234 insertions(+), 16 deletions(-)

diff --git a/contrib/completion/git-completion.bash 
b/contrib/completion/git-completion.bash
index a4c48e1..51b8b3b 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -13,6 +13,7 @@
 #*) .git/remotes file names
 #*) git 'subcommands'
 #*) tree paths within 'ref:path/to/file' expressions
+#*) file paths within current working directory and index
 #*) common --long-options
 #
 # To use these routines:
@@ -233,6 +234,118 @@ __gitcomp_nl ()
COMPREPLY=($(compgen -P ${2-} -S ${4- } -W $1 -- ${3-$cur}))
 }
 
+# Generates completion reply with compgen from newline-separated possible
+# completion filenames.
+# It accepts 1 to 3 arguments:
+# 1: List of possible completion filenames, separated by a single newline.
+# 2: A directory prefix to be added to each possible completion filename
+#(optional).
+# 3: Generate possible completion matches for this word (optional).
+__gitcomp_file ()
+{
+   local IFS=$'\n'
+
+   # XXX does not work when the directory prefix contains a tilde,
+   # since tilde expansion is not applied.
+   # This means that COMPREPLY will be empty and Bash default
+   # completion will be used.
+   COMPREPLY=($(compgen -P ${2-} -W $1

Re: [PATCH] git-completion.bash: Silence not a valid object errors

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 11/01/2013 09:06, Dylan Smith ha scritto:
 Trying to complete the command
 
   git show master:./file
 
 would cause a Not a valid object name error to be output on standard
 error. Silence the error so it won't appear on the command line.
 

I reported the problem a few weeks ago; thanks.

 [...]


Regards  Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlDwgCAACgkQscQJ24LbaUTAxgCfZbB8X8IaTZAcT8iTs1XIILBJ
72MAn2zlh3xbRa/wjq1WyA2yOiAlaCr7
=dMN7
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

about vim contrib support

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi.

In the contrib/vim/README file there are instructions about how to setup
git support with Vim builtin git syntax files.

However these instructions seems to be redundant, since the system
filetype.vim file already have the autocmd rules.

The only issue I found is with:

autocmd BufNewFile,BufRead .msg.[0-9]*
\ if getline(1) =~ '^From.*# This line is ignored.$' |
\   setf gitsendemail |
\ endif

It should be:

autocmd BufNewFile,BufRead [0-9]*.patch

IMHO it should contain some other checks, to make sure it is a patch
generated by git format-patch, and not, as an example, a plain patch or
a Mercurial patch.


By the way: I don't understand the purpose of gitsendemail syntax.
On my system it does not highlight the diff.

I have implemented an alternate gitpatch syntax file, attached.
What I would like to get, is to syntax highligth the commit subject
message, but I'm not a Vim expert.


Regards   Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlDuo0sACgkQscQJ24LbaUTZMQCgm7QRylhxc5v4i4tHBfUXCl8o
36IAn3t72o/+5R/x1TF7r9mu85z6wY25
=b2l0
-END PGP SIGNATURE-
 Vim syntax file
 Language: git format-patch message
 Maintainer:   Manlio Perillo
 Filenames:[0-9]*.patch (first line is From ... # This line is ignored.)
 Last Change:  2014 Gen 10

if exists(b:current_syntax)
finish
endif

syn case match

syn match   gitsendemailComment \%^From.*#.*
syn match   gitsendemailComment ^GIT:.*

if has(spell)
syn spell toplevel
endif

syn include @gitcommitMessage syntax/gitcommit.vim
syn region gitcommitMessage start=/^Subject: \@=/ end=/^$|^#\@=/ 
contains=@gitcommitMessage

hi def link gitsendemailComment Comment

let b:current_syntax = gitpatch

Re: about vim contrib support

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 10/01/2013 12:39, Jeff King ha scritto:
 On Thu, Jan 10, 2013 at 12:17:31PM +0100, Manlio Perillo wrote:
 
 In the contrib/vim/README file there are instructions about how to setup
 git support with Vim builtin git syntax files.

 However these instructions seems to be redundant, since the system
 filetype.vim file already have the autocmd rules.
 
 What version of vim do you have? As the README says, version 7.2 and on
 come with the files already, and you do not need to do anything.

Ah, right.
I missed the first lines of the README file, sorry.


 [...]
 The only issue I found is with:

 autocmd BufNewFile,BufRead .msg.[0-9]*
  \ if getline(1) =~ '^From.*# This line is ignored.$' |
  \   setf gitsendemail |
  \ endif

 It should be:

 autocmd BufNewFile,BufRead [0-9]*.patch
 
 It looks like .msg.[0-9] was originally used for send-email cover
 letters,

Ok, thanks.
I was assuming it was used for the generated patched.

 and was changed to .gitsendemail.msg.* by commit eed6ca7. I
 think your [0-9]*.patch would match something else entirely (though it
 is still broken, of course, as .msg.* does not exist anymore).
 
 [...]
 By the way: I don't understand the purpose of gitsendemail syntax.
 On my system it does not highlight the diff.
 
 As far as I can tell, it is for cover letters, not for patches. Patches
 should already be handled by existing RFC822-message highlighting.
 

.patch files are handled by diff highlight.
What I would like to do is to use gitcommit syntax highlight, in order
to also enable commit subject message hightlight.



Thanks   Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlDuqzYACgkQscQJ24LbaUQ5TgCfQPeX53KOsQDF6WJF1AaSpiRd
NpMAn0GcffJwTA/etrnOnXAQctCKAY4W
=IDVf
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

git-completion.tcsh and git-completion.zsh are broken?

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi.

I have finally resolved all the problems with my path completion in
git-completion.bash and, in order to avoid regressions, I'm checking the
git-completion.zsh and git-completion.tcsh scripts, since they use the
bash completion support.

I have installed (Debian 6.0.6):
* zsh 4.3.10 (i686-pc-linux-gnu)
* tcsh 6.17.02 (Astron) 2010-05-12 (i586-intel-linux)
  options wide,nls,dl,al,kan,rh,nd,color,filec

Note that I'm using my modified git-completion.bash script.


zsh compatibility support in git-completion.bash seems to work (I just
get a segmentation fault ...), however I have problems with the .zsh and
.tcsh scripts.


$zsh
synapsis% source contrib/completion/git-completion.zsh
(anon):6: command not found: ___main
_git:11: command not found: _default

I have disabled compinit autoload (since, I don't know how, it is able
to find the git completion script)


$tcsh
synapsis:~/projects/git/contrib/git source ~/.git-completion.tcsh
synapsis:~/projects/git/contrib/git git show HEAD:TAB

does not show the file list for the tree object in the HEAD

another problem is that a space is added after a directory name.


Another problem with zsh:

$zsh
synapsis% git show HEAD:TAB569GPXZims

I don't know where that 569GPXZims came from.


Can someone else confirm these problems?


Thanks  Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlDtwjcACgkQscQJ24LbaURpuACfVQnoBC3tzvxB0JYxQ5aL3rmN
8GEAnA7OjVtPqz+aq/PGtNtTHWgFqhKK
=3UdZ
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git-completion.tcsh and git-completion.zsh are broken?

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 09/01/2013 21:21, Marc Khouzam ha scritto:
 [...]
 
 $zsh
 synapsis% source contrib/completion/git-completion.zsh
 (anon):6: command not found: ___main
 _git:11: command not found: _default
 
 I have disabled compinit autoload (since, I don't know how, it is able
 to find the git completion script)
 

The attached patch seems to fix it.
I'm still getting segmentation faults, but only when I try to complete
git rm contrib/TAB (in the git repository).

Sorry if this is a plain patch.
The code is simply copied from the one found in git-completion.bash.


I also noted that zsh on my system have preinstalled git completion
support (enabled with autoload).
The code is not the one available in the git source tree.
I don't know if the code is from Debian or zsh.

 
 $tcsh
 synapsis:~/projects/git/contrib/git source ~/.git-completion.tcsh
 synapsis:~/projects/git/contrib/git git show HEAD:TAB
 
 does not show the file list for the tree object in the HEAD
 
 Hm.  That doesn't work for me either.  I'll look into it.
 It is not caused by your changes.
 
 another problem is that a space is added after a directory name.
 
 The lastest version of git-completion.tcsh in the pu branch should
 fix that problem.  It was committed yesterday so you may not have it.
 

Ok, thanks.



Regards  Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlDt2ZoACgkQscQJ24LbaUR/ggCfYNbRrM1HzHWYDwkejNP/hD9k
ShkAnjv3JapVXPlj59CakY4kwaE/4z5J
=qYP5
-END PGP SIGNATURE-
diff --git a/contrib/completion/git-completion.zsh b/contrib/completion/git-completion.zsh
index 4577502..4aeda2a 100644
--- a/contrib/completion/git-completion.zsh
+++ b/contrib/completion/git-completion.zsh
@@ -75,4 +75,5 @@ _git ()
 	return _ret
 }
 
-_git
+autoload -U +X compinit  compinit
+compdef _git git gitk

Re: [PATCH v4] git-completion.bash: add support for path completion

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 05/01/2013 21:23, Marc Khouzam ha scritto:
 [...]
 4- Completion choices include their entire path, which is not what bash does 
 by default.  For example:
 cd git/contrib
 ls completion/git-tab
 git-completion.bash  git-completion.tcsh  git-completion.zsh   git-prompt.sh
 but
 git rm completion/git-tab
 completion/git-completion.bash  completion/git-completion.tcsh  
 completion/git-completion.zsh   completion/git-prompt.sh
 notice the extra 'completion/' before each completion.  This can get pretty 
 large when completing with 
 many directory prefixes.  The current tcsh completion has the same problem 
 which I couldn't fix.  However, I am 
 not sure if it can be fixed for bash.
 
 I personally don't think this is regression, just an slight annoyance.
 

After some searching, I found how this is supposed to be done.
It is possible to use the -o filenames option to tell Bash completion
that the compspec generates filenames, so it can perform any
filename-specific processing.

Unfortunately this option must be passed to the complete builtin
command, and we can not do this, since the comspec not always contains
filenames.

 [...]


Regards  Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlDsXUEACgkQscQJ24LbaURMlgCdEyeSRTRktKtGuDxq4HX1meWt
IV4AmwS6wasCip+1u4vS2FwG8AlXXB7r
=pN8F
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4] git-completion.bash: add support for path completion

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 08/01/2013 19:05, John Keeping ha scritto:
 [...]

 After some searching, I found how this is supposed to be done.
 It is possible to use the -o filenames option to tell Bash completion
 that the compspec generates filenames, so it can perform any
 filename-specific processing.

 Unfortunately this option must be passed to the complete builtin
 command, and we can not do this, since the comspec not always contains
 filenames.
 
 You should also be able to pass it to 'compopt' during completion in
 order to change the behaviour for only the current completion.
 

Thanks, compopt is what I wanted.

I was reading an old Bash manual (for Bash 3.1), and compopt is only
available starting from Bash 4.0.

I will do some test, being careful to not break the code for Bash  4.0
and the other supported shells.



Regards  Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlDsZVgACgkQscQJ24LbaUQlAACdGbhOuGICCYFwkRTPJla+3JGT
EcQAoINEGvdwtOz1QFbAA4FqoI3c7VSa
=5Oqw
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4] git-completion.bash: add support for path completion

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 05/01/2013 21:23, Marc Khouzam ha scritto:
 [...]
 Below are two suggestions that are in line with this effort but that are not 
 regressions.
 
 A) It would be nice if 
 git commit -a TAB
 also completed with untracked files
 

$ git commit -a foo
fatal: Paths with -a does not make sense.

So
  git commit -a TAB

should not suggest untracked files; instead it should suggest nothing.

 [...]


Regards  Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlDq0PoACgkQscQJ24LbaUSTNwCfWt7a1Tdg9u5sd6B3FXCEFj1/
sBwAoIv4B2y4MUQgLNafY2PTWx4giSfD
=tb3O
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [BUG] git submodule update is not fail safe

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 04/01/2013 22:51, Junio C Hamano ha scritto:
 Manlio Perillo manlio.peri...@gmail.com writes:
 
 $ git submodule update --init
 ...
 Submodule 'roms/vgabios' (git://git.qemu.org/vgabios.git/) registered
 for path 'roms/vgabios'
 fatal: unable to connect to anongit.freedesktop.org:
 anongit.freedesktop.org[0: 131.252.210.161]: errno=Connection timed out

 Unable to fetch in submodule path 'pixman'

 $ git submodule update --init
 fatal: Needed a single revision
 Unable to find current revision in submodule path 'pixman'

 The problem is easy to solve: manually remove the pixman directory;
 however IMHO git submodule update should not fail this way since it may
 confuse the user.
 
 Sounds like a reasonable observation.  Jens, Heiko, comments?

I have found another, related problem.

Today I tried to update qemu submodules again, however the command
failed with an obscure error message:

$ git submodule update pixman
fatal: Needed a single revision
Unable to find current revision in submodule path 'pixman'


The pixman submodule is the one that I failed to update in the very begin.
The problem is not with the pixman or qemu repository: if I clone again
qemu (with the --recursive option), all is ok.

The problem is with the private working copy (in .git/modules/pixman)
being corrupted:

$git log
fatal: bad default revision 'HEAD'.

The HEAD file contains ref: refs/heads/master, but the refs/heads
directory is empty.


By the way: since git submodule is a porcelain command, IMHO it should
not show to the user these low level error message; at least it should
give more details.
As an example, in this case it could say something like:

  the local module pixmap seems to be corrupted.
  Run xxx to remove the module and yyy to create it again.

The ideal solution is, for submodule update, to never leave an
incomplete directory; that is: the update command should be atomic.


Regards  Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlDoMAEACgkQscQJ24LbaUQVugCggdl36Hx5JIW/hd1SVXWv+ths
zpYAnR+93BfDLaFhXEiaQvu/TickmDA0
=2Mnw
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [BUG] git submodule update is not fail safe

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 05/01/2013 15:01, Jens Lehmann ha scritto:
 [...]
 $ git submodule update --init
 fatal: Needed a single revision
 Unable to find current revision in submodule path 'pixman'

 The problem is easy to solve: manually remove the pixman directory;
 however IMHO git submodule update should not fail this way since it may
 confuse the user.

 Sounds like a reasonable observation.  Jens, Heiko, comments?
 
 The reason seems to be that clone leaves a partial initialized .git
 directory in case of connection problems. The next time submodule
 update runs it tries to revive the submodule from .git/modules/name
 but fails as there are no objects in it.
 
 [...]

 If this isn't seen as a bug in clone, we could also remove the
 .git/modules/name directory in module_clone() of git-submodule.s
 h when the clone fails. Manilo,

Its Manlio, not Manilo ;-).

 does the following patch remove the
 problems you are seeing (after removing .git/modules/pixman manually)?
 

I don't think I can test it right now, since the problem can only be
reproduced when git clone fails due to network problems.

Without the patch, if I remove the .git/modules/pixman directory,
`git submodule update --init pixamp` fails:

  Unable to find current revision in submodule path 'pixman'
  fatal: Not a git repository: pixman/../.git/modules/pixman


To reproduce the problem, however, it seems all you need to do is to
send SIGINT signal during `git submodule update` :

  $ git submodule update --init pixman
  Cloning into 'pixman'...
  remote: Counting objects: 10137, done.
  ^C

  $ git submodule update pixman
  remote: Counting objects: 10137, done.
  ^C

  $ git submodule update pixman
  fatal: Needed a single revision
  Unable to find current revision in submodule path 'pixman'


Note that I had to send SIGINT two times, in order to corrupt the module.

I suspect your patch does not fix this (since I don't get the Clone
failed error message).


I also noted that If I send SIGINT before git starts counting remote
objects, I get a different count number:


  $ git submodule update pixman
  Cloning into 'pixman'...
  ^C

  $ git submodule update pixman
  remote: Counting objects: 9757, done.
  ^C

  $ git submodule update pixman
  fatal: Needed a single revision
  Unable to find current revision in submodule path 'pixman'


Note that git is reporting 9757 remote objects, instead of 10137.


P.S.:
sorry for the mail I sent today.
It reported the exact same problem I reported yesterday: this morning I
was rather sure that I got a different error message from submodule
update...



Regards   Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlDoPZMACgkQscQJ24LbaUTfNQCdFvhSQwGlJZlvOr+TIHHyDFJY
d8AAn0zuHKjBGIcqr8RH/rftHjomvPtM
=48RN
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Feature request] make git buildable from a separate directory

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi.

Many C projects I have seen (based on autoconf, but not always - like
Nginx) allow the project to be build in a separate directory, in order
to avoid to pollute the working directory with compiled files.

Unfortunately this seems to not be possible with Git.
The Makefile seems quite complex to me, so I'm not sure to be able to
change it to do what I want, without breaking it.


Thanks  Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlDoknUACgkQscQJ24LbaUTw/QCdHbphkU3Mepo98D07yLaj3YyF
5I4Anii94QDHsC1zm2Jp1hy2X/JFa/NE
=vV1z
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] clone: support atomic operation with --separate-git-dir

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 05/01/2013 21:17, Jens Lehmann ha scritto:
 Since b57fb80a7d (init, clone: support --separate-git-dir for .git file)
 git clone supports the --separate-git-dir option to create the git dir
 outside the work tree. But when that option is used, the git dir won't be
 deleted in case the clone fails like it would be without this option. This
 makes clone lose its atomicity as in case of a failure a partly set up git
 dir is left behind. A real world example where this leads to problems is
 when git submodule update fails to clone a submodule and later calls to
 git submodule update stumble over the partially set up git dir and try
 to revive the submodule from there, which then fails with a not very user
 friendly error message.
 
 Fix that by updating the junk_git_dir variable (used to remember if and
 what git dir should be removed in case of failure) to the new value given
 with the --seperate-git-dir option. Also add a test for this to t5600 (and
 while at it fix the former last test to not cd into a directory to test
 for its existence but use test -d instead).
 
 Reported-by: Manlio Perillo manlio.peri...@gmail.com
 Signed-off-by: Jens Lehmann jens.lehm...@web.de
 ---
 [...]
 And this fixes it for me. Manlio, it'd be great if you could test
 this patch (but please not only remove .git/modules/name but also
 the submodule work tree before doing that).
 

I can confirm that the patch solves the problem I reported.


Thanks   Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlDomR4ACgkQscQJ24LbaUQszACfV42L9Xcy+mme6RY/vY+K2H4T
QDAAoIIupUSjwv6qUgzUMQV1aNplrWJD
=uN3W
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4] git-completion.bash: add support for path completion

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 05/01/2013 21:23, Marc Khouzam ha scritto:
 [...]
 I did further testing with your patch and found some less obvious
 issues.  I didn't debug the script myself as I'm not that familiar with
 it either, but I think the testcases below should help Manlio or
 someone else look into some regressions.
 
 1- Using .. or . breaks completion when after the '/':
 [...] 
 2- Maybe related to problem 1.  Using .. breaks completion in other ways:
 [...]
 3- Also probably related to problems 1 and 2.  Using absolute paths behaves 
 wierdly and 
 worse than before:

Thanks for this.

I begin to suspect that this is the reason why path completion has not
been implemented by the original author of the bash completion script.

These issues seems hard to fix.

Tomorrow I will take some time to try to fix all the reported issues.

 [...]


Regards  Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlDomskACgkQscQJ24LbaUQJdwCfX0bMq3V88soqtf+xlypZ5D4f
qwAAn3bK7UlcOK+hm+u06jmT05l1aJVf
=IWap
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[BUG] git submodule update is not fail safe

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi.

My network connection at times is rather unstable, so I can experience
all sort of network problems.

Today I tried to clone the qemu repository, and then to update all
submodules.

I'm using git from a recent master (790c83 - 14 December).

This is what happened:

$ git submodule update --init pixman
Submodule 'pixman' (git://anongit.freedesktop.org/pixman) registered for
path 'pixman'
Cloning into 'pixman'...
fatal: Unable to look up anongit.freedesktop.org (port 9418) (Name or
service not known)
Clone of 'git://anongit.freedesktop.org/pixman' into submodule path
'pixman' failed


$ git submodule update --init
Submodule 'roms/SLOF' (git://git.qemu.org/SLOF.git) registered for path
'roms/SLOF'
Submodule 'roms/ipxe' (git://git.qemu.org/ipxe.git) registered for path
'roms/ipxe'
Submodule 'roms/openbios' (git://git.qemu.org/openbios.git) registered
for path 'roms/openbios'
Submodule 'roms/qemu-palcode' (git://repo.or.cz/qemu-palcode.git)
registered for path 'roms/qemu-palcode'
Submodule 'roms/seabios' (git://git.qemu.org/seabios.git/) registered
for path 'roms/seabios'
Submodule 'roms/sgabios' (git://git.qemu.org/sgabios.git) registered for
path 'roms/sgabios'
Submodule 'roms/vgabios' (git://git.qemu.org/vgabios.git/) registered
for path 'roms/vgabios'
fatal: unable to connect to anongit.freedesktop.org:
anongit.freedesktop.org[0: 131.252.210.161]: errno=Connection timed out

Unable to fetch in submodule path 'pixman'


$ git submodule update --init
fatal: Needed a single revision
Unable to find current revision in submodule path 'pixman'


The problem is easy to solve: manually remove the pixman directory;
however IMHO git submodule update should not fail this way since it may
confuse the user.

I'm sorry for not sending a patch.



Regards   Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlDnQUUACgkQscQJ24LbaUSgVACglJjFxB51VINOCe9Z39/XEEUH
6+QAnAwdQerBSjVSS1/3eNXSBfnR0yba
=eOJT
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

recommendation for patch maintenance

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi.

I would like to have advices about some possible workflows to use when
maintaining a patch, that can evolve over the time (fixing bugs, and
applying advices from reviewers).

In my case I have a single commit to maintain.


The workflow I use now is this:

  1) create a topic branch, e.g. mp/complete-path
  2) write code
  3) commit
  4) format-patch --output=mp/complete-patch master
  5) review the patch
  6) send-email

when I need to update the patch:

  1) modify code
  2) commit --amend
  3) format-patch --subject-prefix=PATCH vn \
 --output=mp/complete-patch master
  4) edit patch to add a list of what was changed
  5) review the patch
  6) send-email


This is far from ideal, since all my local changes are lost.
Another problem is that when I found some trivial error in 5), I need to
call format-patch again, loosing the what's changed list.


A possible solution is to:

1) create a public topic branch, e.g. mp/complete-patch
2) create the associated private topic branch, e.g.
   mp/complete-patch/private
...

Changes are committed to the private branch.
When I need to update the patch:

  1) update code
  2) commit new changes; the commit message will contain the
 what's changed list to be used for the new version of the patch
  3) checkout public branch
  4) merge --squash private branch

Now I have my full history, and the what's changed list is saved in
the private commits.

(not tested)


What is the workflow you usually use?


Thanks   Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlDUde4ACgkQscQJ24LbaUSqOwCfZON5f9mdAYkvACim802JGFhP
5W8An1Y7WXgsH/Q/p1/0jVMo1dJ3HwwO
=Xydn
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Python scripts audited for minimum compatible version and checks added.

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 20/12/2012 15:13, Eric S. Raymond ha scritto:
 Signed-off-by: Eric S. Raymond e...@thyrsus.com
 ---

Just my two cents.
Isn't it better to have some core Python support inside a python/
directory in the git source tree (e.g. e simple python/git.py), and have
*all* python code import that module?

Then you can impose a reasonable version limitation (e.g. Python = 2.5)
inside that module (and/or inside its setup.py file).

Another advantage is that the python/git.py module can contain some very
base support for interfacing git plumbing commands, instead of having
all internal (and external) modules reinventing the wheel.

I'm writing an external command for Git, and I do plan to write such a
package, so that I don't have to reimplement all the base support in my
command source code.



Regards   Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlDUhzoACgkQscQJ24LbaUQFuQCfb6QgkJHdxQSEB7nLXMN8TSmI
6/IAn3svylllaIBQfZKf0lEzNBtZJQMK
=Ar20
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: recommendation for patch maintenance

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 21/12/2012 18:01, Junio C Hamano ha scritto:
 Manlio Perillo manlio.peri...@gmail.com writes:
 
 I would like to have advices about some possible workflows to use when
 maintaining a patch, that can evolve over the time (fixing bugs, and
 applying advices from reviewers).

 [...]
 when I need to update the patch:

   1) modify code
   2) commit --amend
   3) format-patch --subject-prefix=PATCH vn \
  --output=mp/complete-patch master
   4) edit patch to add a list of what was changed
   5) review the patch
   6) send-email

 This is far from ideal, since all my local changes are lost.
 
 Not offering any answer, but it is unclear to me what local changes
 you are losing here.  Care to explain?

I lose the history of all the changes I have made to produce the final
version of a patch.

Since for every new version of a patch I do a commit --amend, I can not
see, as an example, the changes I have made between x and y versions of
a patch.

Of course the commits are not really lost, but I have to search them
using the reflog.


Thanks   Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlDUnIAACgkQscQJ24LbaUTf0QCfX9WtA+/GLzVWDJFPbLMCPucJ
bKQAnj0HJuQs9SVCPV/TlDXcpGDqIqfD
=lhZ5
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4] git-completion.bash: add support for path completion

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 21/12/2012 18:59, Junio C Hamano ha scritto:
 Manlio Perillo manlio.peri...@gmail.com writes:
 
 +case $path in
 +?*/*) echo ${path%%/*}/ ;;
 +*) echo $path ;;
 
 $path unquoted???
 

Missed again, thanks.
I hope this is really the last one!

 [...]
 +__git_index_files ()
 +{
 +local dir=$(__gitdir)
 +
 +if [ -d $dir ]; then
 +# NOTE: $1 is not quoted in order to support multiple options
 
 Good thinking to document this.  Thanks.
 
 I take it that $1 never comes from the end user and it is known that
 it is correct to split them at $IFS?  That is the way I read callers
 of this function in this patch, but I am just double-checking.
 

Yes, $1 is always set internally (but I will check again)
Probably there are better solutions.


 @@ -998,7 +1093,13 @@ _git_commit ()
  
  return
  esac
 -COMPREPLY=()
 +
 +if git rev-parse --verify --quiet HEAD 1/dev/null; then
 
 s/1//;
 

What is the reason?
Coding style?

 +__git_complete_diff_index_file HEAD
 
 As this runs git diff-index without --cached, 
 
 The completion will give only for paths that have difference between
 the working tree and the HEAD.  If the user has a bogus contents
 that was git added earlier, (i.e. the index is different from
 HEAD), then realizes the mistake and fixes it in the working tree
 with his editor to match HEAD (i.e. the working tree is the same
 as HEAD):
 
   git commit the-prefix-to-that-fileTAB
 
 to complete the filename will not give that file.  I do not think it
 is a show-stopper, but it may puzzle the users when they encounter
 the situation.
 

Umh, I just checked this case.

  0) git init test
  1) Added a README file with Hello World., and committed.
  2) Modified the README file with Hello World! and executed
 git add README
  3) Modified the README file with Hello World. (the original content)
  4) $ git diff HEAD:README README
 $ git diff-index --name-only HEAD
 README

 git commit TAB shows the README file.

If I understand correctly the documentation of diff-index, it will
always compare the content of the index with HEAD.
If --cached is specified, it will ignore the stat state of the file on disk.


 I am wondering if reading from git status --porcelain might be a
 better alternative, or if it is too much trouble and slow things
 down to cover such a corner case.
 

It have considered it.

The problem is that the output of git status --porcelain is not
trivial to parse.


 @@ -1362,7 +1464,14 @@ _git_mv ()
  return
  ;;
  esac
 -COMPREPLY=()
 +
 +if [ $cword -gt 2 ]; then
 +# We need to show both cached and untracked files (including
 +# empty directories) since this may not be the last argument.
 +__git_complete_index_file --cached --others --directory
 +else
 +__git_complete_index_file --cached
 +fi
 
 Is $cword affected by the presense of -f in git mv [-f] foo bar?
 Just being curious.
 

Yes, it is affected; I missed it, thanks.
It should count only non-option arguments.


 Other than that, I do not see anything majorly wrong from the coding
 and semantics point of view in the patch.  As to the interaction
 with the rest of the completion machinery, I'll leave the review to
 the area experts CC'ed and wait for their comments.
 
 Thanks.
 

Thanks for your review.


Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlDUsjwACgkQscQJ24LbaUSGuwCffon7/VGFo98CCBsZlmOdNYYE
91oAn3X8fbr5jtzMUOZkMp9CuGWCa7Cf
=Qzsv
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: recommendation for patch maintenance

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 21/12/2012 19:17, Junio C Hamano ha scritto:
 [...]
 Of course you can plan ahead (this is what I usually do when working
 on a series that is not how about this throw-away patch I send to
 this list all the time) and name the topic topic-v1, fork the new
 round topic-v2, topic-v3, etc. and do things like
 
 $ sh -c 'git diff topic-v2~$1 topic-v3~$1' - 4
 
 (the point being that then you do ^P or whatever shell command
 history mechanism to recall that line, edit 4 to 3 and rerun the
 comparison for other corresponding ones).
 

Thanks, this seems fine.
Maybe topic-v2 -- topic/v2 (it looks better to me).

 On a related but different front, I've been thinking about improving
 the format-patch --subject-prefix mechanism to make it even easier
 to use.

 [...]

 What if we added another option, say --reroll $n (or -v$n), to let
 you write:
 
 $ git format-patch --cover-letter -v4 -o ./+mp master
 
 that produces output files named like:
 
 ./+mp/v4--cover-letter.txt
 ./+mp/v4-0001-git-completion.bash.add-support-for-pa.txt
 
 with the subject '[PATCH v4]' prefix?
 

I think it is a good idea to reduce the things one have to do by hand.
I, too, was thinking something similar, with a -v$n option.

And, from these few days I have started to follow the mailing list, it
seems that '[PATCH v$n'] is the standard practice.


By the way, I would also like to be able to set the default value for
the --output option in config file; something like:

  [format]
  output = +mp/$(git symbolic-ref --short HEAD)

where the string will be processed by the shell:

   sh -c 'printf +mp/$(git symbolic-ref --short HEAD)'

Note that printf is POSIX, and the standard suggests to use it instead
of echo:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/echo.html

I have read the affected source code, and it should not be too hard.
What do you think?

I should be able to hack the patch in the weekend, but I'm not sure it
will be accepted.

 Then you can transplant the cover letter material from the cover
 letter from the older iteration to the new cover letter in your
 editor, and sending them out will become
 
 $ git send-email ... ./+mp/v4-*.txt
 
 Hmm?

Seems good.


Regards   Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlDU1REACgkQscQJ24LbaUT5dgCgismeh+R3B26otuBIXRf/VUiq
+5gAoIR56wVfs8Vw8AAWtim4aor97MXN
=DfeG
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3] git-completion.bash: add support for path completion

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 19/12/2012 20:57, Junio C Hamano ha scritto:
 [jch: again, adding area experts to Cc]
 
 Manlio Perillo manlio.peri...@gmail.com writes:
 
 Changes from version 2:

  * Perl is no more used.
  * Fixed some coding style issues.
  * Refactorized code, to improve future path completion support for
the git reset command.
 
 Thanks.  Will replace what was queued on 'pu'.
 
 +# Process path list returned by ls-files and diff-index --name-only
 +# commands, in order to list only file names relative to a specified
 +# directory, and append a slash to directory names.
 +# It accepts 1 optional argument: a directory path.  The path must have
 +# a trailing slash.
 
 The callsites that call this function, and the way the argument is
 used, do not make it look like it is an optional argument to me.
 
 After reading later parts of the patch, I think the callers are
 wrong (see below) and you did intend to make $1 optional.
 

Thanks for the corrections.
As you can see, I'm not very expert in bash programming.
I will review the code to use proper escaping and correct optional
parameters handling, based on your review.

In this case, I incorrectly assumed that bash expands ${1} to an empty
string, in case no arguments are passed to the function.

 +__git_index_file_list_filter ()
 +{
 +local path
 +
 +while read -r path; do
 +path=${path#$1}
 
 This will work correctly only if $1 does not have any shell
 metacharacter that removes prefix of $path that matches $1 as a
 pathname expansion pattern.  As this file is for bash completion,
 using string-oriented Bash-isms like ${#1} (to get the length of the
 prefix) and ${path:$offset} (to get substring) are perfectly fine
 way to correct it.
 

Ok.

 Also, as $1 is optional, won't this barf if it is run under set -u?


Ok.
Here I should use ${1-}.

 +# __git_index_files accepts 1 or 2 arguments:
 +# 1: A string for file index status mode (c, m, d, o), as
 +#supported by git ls-files command.
 +# 2: A directory path (optional).
 +#If provided, only files within the specified directory are listed.
 +#Sub directories are never recursed.  Path must have a trailing
 +#slash.
 +__git_index_files ()
 +{
 +local dir=$(__gitdir)
 +
 +if [ -d $dir ]; then
 +git --git-dir=$dir ls-files --exclude-standard -${1} ${2} 
 |
 +__git_index_file_list_filter ${2} | uniq
 
 Even though everywhere else you seem to quote the variables with dq,
 but this ${2} is not written as ${2}, which looks odd.  Deliberate?
 

No, I simply missed it.

 If you wanted to call __git_index_file_list_filter without parameter
 when the caller did not give you the optional $2, then the above is
 not the way to write it.  It would be ${2+$2}.

Yes, this seems the better solution.

 [...]

 +# __git_diff_index_files accepts 1 or 2 arguments:
 +# 1) The id of a tree object.
 +# 2) A directory path (optional).
 +#If provided, only files within the specified directory are listed.
 +#Sub directories are never recursed.  Path must have a trailing
 +#slash.
 +__git_diff_index_files ()
 +{
 +local dir=$(__gitdir)
 +
 +if [ -d $dir ]; then
 +git --git-dir=$dir diff-index --name-only ${1} |
 +__git_index_file_list_filter ${2} | uniq
 
 This one, when the optional $2 is absent, will call 
 __git_index_file_list_filter
 with an empty string in its $1.  Intended, or is it also ${2+$2}?

No, it was not intended. But here it should probably be ${2-}.

One possible rule is:
* ${n+$n} should be used by the _git_complete_xxx_file function;
* ${n-} should be used by the _git_xxx_file functions

The alternative is for each function to use ${n-}, or {n+$n}.

But I'm not sure.  What is the best practice in bash for optional
parameters propagation?


 
 +# __git_complete_index_file requires 1 argument: the file index
 +# status mode
 +__git_complete_index_file ()
 +{
 +local pfx cur_=$cur
 +
 +case $cur_ in
 +?*/*)
 +pfx=${cur_%/*}
 +cur_=${cur_##*/}
 +pfx=${pfx}/
 +
 +__gitcomp_nl $(__git_index_files ${1} ${pfx}) $pfx 
 $cur_ 
 +;;
 +*)
 +__gitcomp_nl $(__git_index_files ${1})  $cur_ 
 +;;
 +esac
 
 Please dedent the case arms by one level, i.e.


I missed it.
Vim do not intent correctly this, and I forgot to dedent.


 [...]
 +# __git_complete_diff_index_file requires 1 argument: the id of a tree
 +# object
 +__git_complete_diff_index_file ()
 +{
 +local pfx cur_=$cur
 +
 +case $cur_ in
 +?*/*)
 +pfx=${cur_%/*}
 +cur_=${cur_##*/}
 +pfx=${pfx}/
 +
 +__gitcomp_nl $(__git_diff_index_files ${1} ${pfx}) 
 $pfx $cur_

Re: [PATCH] git-completion.bash: add support for path completion

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 17/12/2012 20:42, Junio C Hamano ha scritto:
 [...]
 I am not sure how you would handle the last parameter to git mv,
 though.  That is by definition a path that does not exist,
 i.e. cannot be completed.

 Right, the code should be changed.
 No completion should be done for the second parameter.
 
 I deliberately wrote the last not the second, as you can do
 
   $ mkdir X
 $ git mv COPYING README X/.
 
 You do need to expand the second parameter to README when the user
 types
 
   git mv COPYING REAMDE X
 
 then goes back with \C-b to M, types \C-d three times to remove
 MDE, and then finally says TAB, to result in
 
   git mv COPYING README X
 

Assuming X is a new untracked directory, do you think it is an usability
problem if an user try to do:

git mv COPYING README TAB

and X does not appear in the completion list?

As far as I know, the solution is to only support custom expansion the
first parameter, unless the user will do something like:

git mv COPYING README -- TAB


Regards  Manlio

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlDSOWAACgkQscQJ24LbaUSOnACfds93RtX1CDOeGbwCGM5/N8HI
yVwAn0AZEO6rE083gKgFimGIbiRTyN5Z
=z7K5
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3] git-completion.bash: add support for path completion

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 19/12/2012 20:57, Junio C Hamano ha scritto:
 [...]

I just found a serious bug with git commit path completion.

When doing the first commit on an empty repository, completion will
cause an error:

$git commit -m init TABfatal: ambiguous argument 'HEAD': unknown
revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git command [revision...] -- [file...]'

The problem is that for a newly created repository there is no HEAD.

If HEAD does not exists, code must use ls-files instead of diff-index
to get the completion list.

Another change is to always call git commands with stderr redirected to
/dev/null.


By the way, this is also a bug of current bash completion code:

$ git show does-not-exists:TABfatal: Not a valid object name
  does-not-exists

I will write a patch (based on master) to fix this.

 [...]


Regards  Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlDSUR0ACgkQscQJ24LbaUSkRwCfVKk9JhSD4sKDFm4heAkVbN0o
KAAAn3paTXyUiFlfY/UBpnkwiARegLsE
=7Q5s
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] git-completion.bash: add support for path completion

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 19/12/2012 23:49, Junio C Hamano ha scritto:
 Manlio Perillo manlio.peri...@gmail.com writes:
 
 git mv COPYING README X

 Assuming X is a new untracked directory, do you think it is an usability
 problem if an user try to do:

  git mv COPYING README TAB

 and X does not appear in the completion list?
 
 It is hard to say.  Will it show Documentation/ in the list?  Will
 it show git.c in the list?
 

Currently all cached files will be showed.

 Your git mv git.TAB completing to git mv git.c would be an
 improvement compared to the stock less git.TAB that offers
 git.c and git.o as choices.  For things like mv and rm, this
 may not make too much of a difference, git add TAB would be a
 vast improvement from the stock one.  The users will notice that the
 completion knows what it is doing, and will come to depend on it.
 

Yes, this is precisely the reason why I'm implementing it ;-).

I also use Mercurial (I discovered Git just a few weeks ago, after
reading Pro Git), and Mercurial do have path completion (completion list
does not stop at directory boundary, however).

When I started to use Git, one of the first thing I noticed was the lack
of path completion for git add.

 [...]
 In the ideal world (read: I am *not* saying you should implement it
 this way, or we won't look at your patch), I think you would want
 to show tracked files (because it may be the third path that the
 user wants to move with the command, not the destination directory)
 and any directory on the filesystem (it could be the third path that
 is being moved if it has tracked files, or it could be the final
 destination directory argument).

What about this?

* show all and only cached files for the first argument
* show all cached + untracked directories and files for all other
  arguments

This should solve most of the problem, and will still not show ignored
files.  And, most important, it is very easy to implement.


The only issue is that git ls-files -o does not show empty
directories, and git ls-files --directory -o will add a trailing slash.



Thanks   Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlDSUr4ACgkQscQJ24LbaURf0gCeJVZviwfKHgHNZ8vYBjnjwP8+
WF4AnAn3/KPJciJg9r387qIzCajx4j0s
=/10k
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] git-completion.bash: add support for path completion

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 17/12/2012 20:42, Junio C Hamano ha scritto:
 [...]
 I am not sure how you would handle the last parameter to git mv,
 though.  That is by definition a path that does not exist,
 i.e. cannot be completed.

 Right, the code should be changed.
 No completion should be done for the second parameter.
 
 I deliberately wrote the last not the second, as you can do
 
   $ mkdir X
 $ git mv COPYING README X/.
 

The patch is ready, however I decided to leave git mv completion simple.
Pressing TAB will always try to autocomplete using all cached files.
I have added a note to remember it needs more work.


P.S.:
git-completion.bash has a lot of other things that may be improved:

* adding missing commands
 (as an example, there is strangely no custom support fot git status)

* completion support for commands like git checkout is not complete.
  git checkout TAB will correctly try to complete the tree-ish,
  however git checkout HEAD -- TAB will try to complete the path
  using *all* files in the working directory.

  This is easy to fix, using the new functions I have added

* not all long options are supported.
  The script documentation says that only common long options are
  supported, so I'm not sure it is ok to add support for all available
  long options.


Regards   Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlDQmQgACgkQscQJ24LbaUSw9QCfT1lCH/yjA4Lgmb2nMspNWM3l
hMMAn26UxWesuoOxMbuwhqaypPjkmN84
=Wh4c
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3] git-completion.bash: add support for path completion

[Manlio Perillo]

The git-completion.bash script did not implemented full, git aware,
support for completion, for git commands that operate on files within
the current working directory or the index.

For these commands, only long options completion was available.
As an example:

git add TAB

will suggest all files in the current working directory, including
ignored files and files that have not been modified.

Full support for completion is now implemented, for git commands where
the non-option arguments always refer to paths within the current
working directory or the index, as the follow:

* the path completion for the git mv, git rm and git ls-tree
  commands will suggest all cached files.

* the path completion for the git add command will suggest all
  untracked and modified files.  Ignored files are excluded.

* the path completion for the git clean command will suggest all
  untracked files.  Ignored files are excluded.

* the path completion for the git commit command will suggest all
  files that have been modified from the HEAD.

For all affected commands, completion will always stop at directory
boundary.  Only standard ignored files are excluded, using the
--exclude-standard option of the ls-files command.

Signed-off-by: Manlio Perillo manlio.peri...@gmail.com
---
 contrib/completion/git-completion.bash | 112 -
 1 file changed, 97 insertions(+), 15 deletions(-)

diff --git a/contrib/completion/git-completion.bash 
b/contrib/completion/git-completion.bash
index 0b77eb1..923ef37 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -13,6 +13,7 @@
 #*) .git/remotes file names
 #*) git 'subcommands'
 #*) tree paths within 'ref:path/to/file' expressions
+#*) file paths within current working directory and index
 #*) common --long-options
 #
 # To use these routines:
@@ -233,6 +234,59 @@ __gitcomp_nl ()
COMPREPLY=($(compgen -P ${2-} -S ${4- } -W $1 -- ${3-$cur}))
 }
 
+# Perl filter used to process path list returned by ls-files and
+# diff-index --name-only commands, in order to list file names
+# relative to a specified directory, and append a slash to directory
+# names.
+# The script expects the prefix path in the pfx environ variable.
+# The output must be processed with the uniq filter, to remove
+# duplicate directories.
+# XXX remove duplicates in the Perl script ?
+__git_index_file_list_filter='$pfx = $ENV{pfx};
+   $idx = index($_, $pfx);
+   if ($idx == 0) {
+   $_ = substr $_, length($pfx);
+   @segments = split(/, $_);
+   if ($segments[1]) {
+   print $segments[0], /\n
+   } else {
+   print $segments[0], \n
+   }
+   }'
+
+# __git_files accepts 1 or 2 arguments:
+# 1: A string for file index status mode (c, m, d, o), as
+#supported by git ls-files command.  This is required.
+# 2: An optional directory path.  If provided, only files within the
+#specified directory are listed.  Sub directories are never recursed.
+#Path must have a trailing slash.
+__git_files ()
+{
+   local dir=$(__gitdir) flags=-${1}
+
+   if [ -d $dir ]; then
+   git --git-dir=$dir ls-files --exclude-standard ${flags} 
${pfx} \
+   | pfx=$2 perl -ne ${__git_index_file_list_filter} \
+   | uniq
+   return
+   fi
+}
+
+# __git_commit_files accepts 1 optional argument: a directory path.
+# If provided, only files within the specified directory are listed.
+# Sub directories are never recursed.  Path must have a trailing slash.
+__git_commit_files ()
+{
+   local dir=$(__gitdir)
+
+   if [ -d $dir ]; then
+   git --git-dir=$dir diff-index --name-only HEAD \
+   | pfx=$1 perl -ne ${__git_index_file_list_filter} \
+   | uniq
+   return
+   fi
+}
+
 __git_heads ()
 {
local dir=$(__gitdir)
@@ -430,6 +484,25 @@ __git_complete_revlist_file ()
 }
 
 
+# __git_complete_index_file requires 1 argument, the file index
+# status mode
+_git_complete_index_file ()
+{
+   local pfx cur_=$cur flags=${1}
+   case $cur_ in
+   ?*/*)
+   pfx=${cur_%/*}
+   cur_=${cur_##*/}
+   pfx=${pfx}/
+
+   __gitcomp_nl $(__git_files ${flags} ${pfx}) $pfx 
$cur_ 
+   ;;
+   *)
+   __gitcomp_nl $(__git_files ${flags})  $cur_ 
+   ;;
+   esac
+}
+
 __git_complete_file ()
 {
__git_complete_revlist_file
@@ -770,8 +843,6 @@ _git_apply ()
 
 _git_add ()
 {
-   __git_has_doubledash  return
-
case $cur

Incorrect man page for git-diff

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi.

Documentation seems to suggest this is supported, but it is not true:

  $ git diff HEAD:git.c HEAD~100:git.c -- git.c
  usage: git diff [options] [commit [commit]] [--] [path...]

unless I'm missing something.



Manlio

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlDQqncACgkQscQJ24LbaUT9XwCfV40P7lGulSWw+dzVo17EhcDQ
YFoAnRb46025qYsKWp9mg6ZTRyuuaG3x
=0gO1
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3] git-completion.bash: add support for path completion

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 18/12/2012 18:53, Junio C Hamano ha scritto:
 [jch: cc'ed git-completion experts to review implementation details]
 
 Manlio Perillo manlio.peri...@gmail.com writes:
 
 The git-completion.bash script did not implemented full, git aware,
 support for completion, for git commands that operate on files within
 the current working directory or the index.

 For these commands, only long options completion was available.
 
 I find the long options completion is a misleading phrase.  It
 sounds as if you changed the current completion that does not
 complete git commit -TAB but does git commit --TAB to
 complete the short options (e.g. git commit -c), but I do not
 think that is the topic of this patch.
 

It does not sound misleading to me.
I'm saying that the git-completion.bash script only implemented
completion for long options, but not for file names in the current
working directory.

Do you think I should rewrite the subject and the log message introduction?

As an example, something like this in the subject:

  git-completion.bash: improve some git commands completion

and in the message:

  The git-completion.bash script did not implemented full, git aware,
  support for completion, for git commands that operate on files within
  the current working directory or the index.

  As an example:

 ...

I'm still not fully satisfied with it, however.
It still requires reading the full message to understand the changes
implemented.

 As an example:

  git add TAB

 will suggest all files in the current working directory, including
 ignored files and files that have not been modified.

 Full support for completion is now implemented, for git commands where
 
 s/Full.*implemented/Support more comprehensive completion/; or
 something, talking in the imperative mood (i.e. as if you are giving
 the order to the codebase to do something).
 

Ok.

 the non-option arguments always refer to paths within the current
 working directory or the index, as the follow:

 * the path completion for the git mv, git rm and git ls-tree
   commands will suggest all cached files.
 
 I thought you dropped git mv in this round.
 

Well, no.
But the current implementation should not cause problems.
Also note that I added support for ls-files, too.

There are some XXX marks in the code, but I think that the changes
always improve the old behaviour.

 [...]
 For all affected commands, completion will always stop at directory
 boundary.  Only standard ignored files are excluded, using the
 --exclude-standard option of the ls-files command.
 
 I read always stop at directory boundary to mean that
 
   git cmd tTAB
 
 will give us t/ tag.c (assuming there is a new or modified file in
 t/ and tag.c is the only modified file at the root level that begins
 with t) and then
 
   git cmd t/TAB
 
 will likewise show the files and top-level subdirectories within t/
 directory.  That would be great.
 

Yes, this is how it works, bugs excluded (I'm not a bash/perl expert).


 [...]
 +# Perl filter used to process path list returned by ls-files and
 +# diff-index --name-only commands, in order to list file names
 +# relative to a specified directory, and append a slash to directory
 +# names.
 +# The script expects the prefix path in the pfx environ variable.
 +# The output must be processed with the uniq filter, to remove
 +# duplicate directories.
 +# XXX remove duplicates in the Perl script ?
 
 Surely, that will remove one fork/exec with pipeline.  I am not sure
 what the performance implication of using Perl here, but because we
 do not have to stick to POSIX shell in this file, the completion
 experts would be able to help rewriting this logic as a pure bash
 script.
 

Ok. I'll wait for a review from git-completion experts.

Note that the performance is the reason why I suggested, in a previous
email, that git should have some more options to format data in custom ways.
As an example, there is no way to tell ls-files to not recurse
directories, and there is no way to also get the file type.

A --no-recurse option, and a change in the code to make, as an example

  git ls-files --stage --modified

to honor the --modified option,  will probably make it possible to use a
simple sed filter (there is still the problem that, unlike ls-tree,
ls-files shows the complete file path).

 [...]
 +__git_files ()
 +{
 +local dir=$(__gitdir) flags=-${1}
 +
 +if [ -d $dir ]; then
 +git --git-dir=$dir ls-files --exclude-standard ${flags} 
 ${pfx} \
 +| pfx=$2 perl -ne ${__git_index_file_list_filter} \
 +| uniq
 
 This is purely a style thing (note that style suggestions are not
 optional), but
 
 the data source command |
 a filter command |
 another filter command
 
 is easier to read and can be spelled without the backslash.  The
 same comment applies to git-commit-files as well.
 

I agree.

But I was copying

Re: Incorrect man page for git-diff

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 18/12/2012 19:11, Junio C Hamano ha scritto:
 Manlio Perillo manlio.peri...@gmail.com writes:
 
 Documentation seems to suggest this is supported, but it is not true:

   $ git diff HEAD:git.c HEAD~100:git.c -- git.c
   usage: git diff [options] [commit [commit]] [--] [path...]

 unless I'm missing something.
 
 Neither HEAD:git.c nor HEAD~100:git.c are commits.

Well, the documentation calls these parameter commit, later saying
For a more complete list of ways to spell commit, see SPECIFYING
REVISIONS.

  You are
 comparing two blob objects in their raw forms without textconv nor
 filter.
 

Note that I was not missing the fact that git diff does not apply
texconv and filters.

I'm not sure the man page is wrong and should be changed:

  -- usage: git diff [options] [commit [commit]] [--] [path...]
  ++ usage: git diff [options] [commit [commit]]


Regards  Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlDQv40ACgkQscQJ24LbaUT+vwCgj0rjaZbc+/x0+jvAGZydbVKB
244An2pWLj7t4nG3lZzx+LGyH3mjTujS
=TmVI
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3] git-completion.bash: add support for path completion

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 18/12/2012 20:22, Junio C Hamano ha scritto:
 [...]
 Note that the performance is the reason why I suggested, in a previous
 email, that git should have some more options to format data in custom ways.
 As an example, there is no way to tell ls-files to not recurse
 directories, and there is no way to also get the file type.
 
 To ls-files, no-recurse is an idiotic thing to ask.  The index is a
 flat structure that is read as a whole.  There is no recursion
 involved.

What about an option like --as-tree, so that ls-files will list the
files as they were in a tree, instead of a flat structure ?


Thanks  Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlDQ0j4ACgkQscQJ24LbaURXoACffQ4iz6MsoeffEZEBib1b1KF8
NZsAoIUXa7OonWyFxfJ35mukBK/sddGr
=0nO7
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] git-completion.bash: update obsolete code.

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 17/12/2012 05:54, Junio C Hamano ha scritto:
 Manlio Perillo manlio.peri...@gmail.com writes:
 
 The git-completion.bash script was using the git ls-tree command
 without the --name-only option, with a sed filter to parse path names;
 use the --name-only option, instead.

 Signed-off-by: Manlio Perillo manlio.peri...@gmail.com
 ---
 
 Did you miss the different handling between blobs and trees the
 latter gets trailing slash in the completion)?
 

Yes, I totally missed it, sorry.
I was assuming the bash completion script was written before --name-only
option was added to ls-tree.

By the way, IMHO there should be an option for adding a slash to
directory names in ls-tree.

 [...]


Regards  Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEUEARECAAYFAlDPTgUACgkQscQJ24LbaUSkKgCePH2NFHf/qp2ZrgI9eD9D0D3G
zOwAmL8Dc8r9DevyV1ZhaCb2G9MPZxU=
=QJEy
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] git.c: add --index-file command-line option.

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 16/12/2012 06:59, Junio C Hamano ha scritto:
 I
 Manlio Perillo manlio.peri...@gmail.com writes:
 
 This works with a shell.
 I'm using Python to write a custom git command.
 
 I would be very surprised if Python lacked a way to spawn a
 subprocess with an environment modified from the current process.

Of course it is possible, but a command-line option is more convenient,
IMHO.



Regards  Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlDNhGsACgkQscQJ24LbaUQ0dQCglUAw8zwRKNeDUGznfrm1xFKf
GQsAnA/ucztku4v9LnIr0Lv/gyl5ULiT
=j/1w
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] git-completion.bash: add support for path completion

[Manlio Perillo]

The git-completion.bash script did not implemented full support for
completion, for git commands that operate on files from the current
working directory or the index.

For these commands, only options completion was available.

Full support for completion is now implemented, for git commands where
the non-option arguments always refer to paths on the current working
directory or the index, as the follow:

* the path completion for the git mv and git rm commands is provided
  using git ls-files --exclude-standard

* the path completion for the git add command is provided using
  git ls-files --exclude-standard -o -m

* the path completion for the git clean command is provided using
  git ls-files --exclude-standard -o

* the path completion for the git commit command is provides using
  git diff-index --name-only HEAD

Signed-off-by: Manlio Perillo manlio.peri...@gmail.com
---
 contrib/completion/git-completion.bash | 39 ++
 1 file changed, 26 insertions(+), 13 deletions(-)

diff --git a/contrib/completion/git-completion.bash 
b/contrib/completion/git-completion.bash
index 0b77eb1..8b348c3 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -233,6 +233,25 @@ __gitcomp_nl ()
COMPREPLY=($(compgen -P ${2-} -S ${4- } -W $1 -- ${3-$cur}))
 }
 
+__git_files ()
+{
+   local dir=$(__gitdir)
+   if [ -d $dir ]; then
+   git --git-dir=$dir ls-files --exclude-standard $*
+   return
+   fi
+}
+
+# Return all staged files with modification from current HEAD
+__git_commit_files ()
+{
+   local dir=$(__gitdir)
+   if [ -d $dir ]; then
+   git --git-dir=$dir diff-index --name-only HEAD
+   return
+   fi
+}
+
 __git_heads ()
 {
local dir=$(__gitdir)
@@ -770,8 +789,6 @@ _git_apply ()
 
 _git_add ()
 {
-   __git_has_doubledash  return
-
case $cur in
--*)
__gitcomp 
@@ -780,7 +797,8 @@ _git_add ()

return
esac
-   COMPREPLY=()
+   # XXX should we care for --update and --all options ?
+   __gitcomp_nl $(__git_files -o -m)  $cur 
 }
 
 _git_archive ()
@@ -930,15 +948,14 @@ _git_cherry_pick ()
 
 _git_clean ()
 {
-   __git_has_doubledash  return
-
case $cur in
--*)
__gitcomp --dry-run --quiet
return
;;
esac
-   COMPREPLY=()
+   # TODO: check for -x option
+   __gitcomp_nl $(__git_files -o)  $cur 
 }
 
 _git_clone ()
@@ -969,8 +986,6 @@ _git_clone ()
 
 _git_commit ()
 {
-   __git_has_doubledash  return
-
case $cur in
--cleanup=*)
__gitcomp default strip verbatim whitespace
@@ -998,7 +1013,7 @@ _git_commit ()

return
esac
-   COMPREPLY=()
+   __gitcomp_nl $(__git_commit_files)  $cur 
 }
 
 _git_describe ()
@@ -1362,7 +1377,7 @@ _git_mv ()
return
;;
esac
-   COMPREPLY=()
+   __gitcomp_nl $(__git_files)  $cur 
 }
 
 _git_name_rev ()
@@ -2068,15 +2083,13 @@ _git_revert ()
 
 _git_rm ()
 {
-   __git_has_doubledash  return
-
case $cur in
--*)
__gitcomp --cached --dry-run --ignore-unmatch --quiet
return
;;
esac
-   COMPREPLY=()
+   __gitcomp_nl $(__git_files)  $cur 
 }
 
 _git_shortlog ()
-- 
1.8.1.rc1.18.g9db0d25

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] git-completion.bash: update obsolete code.

[Manlio Perillo]

The git-completion.bash script was using the git ls-tree command
without the --name-only option, with a sed filter to parse path names;
use the --name-only option, instead.

Signed-off-by: Manlio Perillo manlio.peri...@gmail.com
---
 contrib/completion/git-completion.bash | 15 +--
 1 file changed, 1 insertion(+), 14 deletions(-)

diff --git a/contrib/completion/git-completion.bash 
b/contrib/completion/git-completion.bash
index 0b77eb1..85d9051 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -397,20 +397,7 @@ __git_complete_revlist_file ()
*)   pfx=$ref:$pfx ;;
esac
 
-   __gitcomp_nl $(git --git-dir=$(__gitdir) ls-tree $ls \
-   | sed '/^100... blob /{
-  s,^.*,,
-  s,$, ,
-  }
-  /^12 blob /{
-  s,^.*,,
-  s,$, ,
-  }
-  /^04 tree /{
-  s,^.*,,
-  s,$,/,
-  }
-  s/^.*//') \
+   __gitcomp_nl $(git --git-dir=$(__gitdir) ls-tree --name-only 
$ls) \
$pfx $cur_ 
;;
*...*)
-- 
1.8.1.rc1.18.g9db0d25

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] git-completion.bash: add support for path completion

[Manlio Perillo]

The git-completion.bash script did not implemented full support for
completion, for git commands that operate on files from the current
working directory or the index.

For these commands, only options completion was available.

Full support for completion is now implemented, for git commands where
the non-option arguments always refer to paths on the current working
directory or the index, as the follow:

* the path completion for the git mv and git rm commands is provided
  using git ls-files --exclude-standard

* the path completion for the git add command is provided using
  git ls-files --exclude-standard -o -m

* the path completion for the git clean command is provided using
  git ls-files --exclude-standard -o

* the path completion for the git commit command is provides using
  git diff-index --name-only HEAD

Signed-off-by: Manlio Perillo manlio.peri...@gmail.com
---

Updated the script documentation.

 contrib/completion/git-completion.bash | 40 +++---
 1 file changed, 27 insertions(+), 13 deletions(-)

diff --git a/contrib/completion/git-completion.bash 
b/contrib/completion/git-completion.bash
index 0b77eb1..3bd7fc8 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -13,6 +13,7 @@
 #*) .git/remotes file names
 #*) git 'subcommands'
 #*) tree paths within 'ref:path/to/file' expressions
+#*) working directory and index file names
 #*) common --long-options
 #
 # To use these routines:
@@ -233,6 +234,25 @@ __gitcomp_nl ()
COMPREPLY=($(compgen -P ${2-} -S ${4- } -W $1 -- ${3-$cur}))
 }
 
+__git_files ()
+{
+   local dir=$(__gitdir)
+   if [ -d $dir ]; then
+   git --git-dir=$dir ls-files --exclude-standard $*
+   return
+   fi
+}
+
+# Return all staged files with modification from current HEAD
+__git_commit_files ()
+{
+   local dir=$(__gitdir)
+   if [ -d $dir ]; then
+   git --git-dir=$dir diff-index --name-only HEAD
+   return
+   fi
+}
+
 __git_heads ()
 {
local dir=$(__gitdir)
@@ -770,8 +790,6 @@ _git_apply ()
 
 _git_add ()
 {
-   __git_has_doubledash  return
-
case $cur in
--*)
__gitcomp 
@@ -780,7 +798,8 @@ _git_add ()

return
esac
-   COMPREPLY=()
+   # XXX should we care for --update and --all options ?
+   __gitcomp_nl $(__git_files -o -m)  $cur 
 }
 
 _git_archive ()
@@ -930,15 +949,14 @@ _git_cherry_pick ()
 
 _git_clean ()
 {
-   __git_has_doubledash  return
-
case $cur in
--*)
__gitcomp --dry-run --quiet
return
;;
esac
-   COMPREPLY=()
+   # TODO: check for -x option
+   __gitcomp_nl $(__git_files -o)  $cur 
 }
 
 _git_clone ()
@@ -969,8 +987,6 @@ _git_clone ()
 
 _git_commit ()
 {
-   __git_has_doubledash  return
-
case $cur in
--cleanup=*)
__gitcomp default strip verbatim whitespace
@@ -998,7 +1014,7 @@ _git_commit ()

return
esac
-   COMPREPLY=()
+   __gitcomp_nl $(__git_commit_files)  $cur 
 }
 
 _git_describe ()
@@ -1362,7 +1378,7 @@ _git_mv ()
return
;;
esac
-   COMPREPLY=()
+   __gitcomp_nl $(__git_files)  $cur 
 }
 
 _git_name_rev ()
@@ -2068,15 +2084,13 @@ _git_revert ()
 
 _git_rm ()
 {
-   __git_has_doubledash  return
-
case $cur in
--*)
__gitcomp --cached --dry-run --ignore-unmatch --quiet
return
;;
esac
-   COMPREPLY=()
+   __gitcomp_nl $(__git_files)  $cur 
 }
 
 _git_shortlog ()
-- 
1.8.1.rc1.18.g9db0d25

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] git.c: add --index-file command-line option.

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 15/12/2012 19:02, Junio C Hamano ha scritto:
 Manlio Perillo manlio.peri...@gmail.com writes:
 
 Unlike other environment variables (e.g. GIT_WORK_TREE,
 GIT_NAMESPACE), it was not possible to set the GIT_INDEX_FILE
 environment variable using the command line.
 
 Is this necessary?  I'd prefer to see a better reason than just
 because others have it.

A long running program will be able to tell git to use an alternate
index file, without having to modify its own environment, or having to
use execvpe (I assume this is the reason why it is possible to specify
GIT_WORK_TREE from command line).



Regards  Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEUEARECAAYFAlDMxzsACgkQscQJ24LbaUSzEQCYymkZa6JrT42OzigRfDgc5Hss
gwCgjIzs1b0hEyu1WAgDgCir9XalDN8=
=GtMF
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] git.c: add --index-file command-line option.

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 15/12/2012 20:36, Junio C Hamano ha scritto:
 [...]
 Unlike other environment variables (e.g. GIT_WORK_TREE,
 GIT_NAMESPACE), it was not possible to set the GIT_INDEX_FILE
 environment variable using the command line.

 Is this necessary?  I'd prefer to see a better reason than just
 because others have it.

 A long running program will be able to tell git to use an alternate
 index file, without having to modify its own environment,...
 
 Hrm, isn't that the single-shot environment export syntax
 
   GIT_INDEX_FILE=foo git blah
 
 is for?  Is there a real-world need for this?
 

This works with a shell.
I'm using Python to write a custom git command.




Regards  Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlDM8yQACgkQscQJ24LbaUTftQCbBC7D9P7Sqlr9GzWuCIcIHPf2
aQcAn13+d4trLZS4izGvZtoaopMav4nV
=vfb6
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] git.c: add --index-file command-line option.

[Manlio Perillo]

Unlike other environment variables (e.g. GIT_WORK_TREE,
GIT_NAMESPACE), it was not possible to set the GIT_INDEX_FILE
environment variable using the command line.

Add a new --index-file command-line option.

Update the t7500-commit test to include --index-file option coverage.
The tests have been adapted from the existing
'using alternate GIT_INDEX_FILE (1)' and
'using alternate GIT_INDEX_FILE (2)' tests.

Signed-off-by: Manlio Perillo manlio.peri...@gmail.com
---
 Documentation/git.txt | 10 +-
 git.c | 17 -
 t/t7500-commit.sh | 29 +
 3 files changed, 54 insertions(+), 2 deletions(-)

diff --git a/Documentation/git.txt b/Documentation/git.txt
index e643683..5a582dd 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -12,7 +12,8 @@ SYNOPSIS
 'git' [--version] [--help] [-c name=value]
 [--exec-path[=path]] [--html-path] [--man-path] [--info-path]
 [-p|--paginate|--no-pager] [--no-replace-objects] [--bare]
-[--git-dir=path] [--work-tree=path] [--namespace=name]
+[--git-dir=path] [--work-tree=path] [--index-file=path]
+[--namespace=name]
 command [args]
 
 DESCRIPTION
@@ -408,6 +409,12 @@ help ...`.
variable (see core.worktree in linkgit:git-config[1] for a
more detailed discussion).
 
+--index-file=path::
+   Set the path to the index file. It can be an absolute path
+   or a path relative to the current working directory.
+   This can also be controlled by setting the GIT_INDEX_FILE
+   environment variable.
+
 --namespace=path::
Set the git namespace.  See linkgit:gitnamespaces[7] for more
details.  Equivalent to setting the `GIT_NAMESPACE` environment
@@ -632,6 +639,7 @@ git so take care if using Cogito etc.
This environment allows the specification of an alternate
index file. If not specified, the default of `$GIT_DIR/index`
is used.
+   The '--index-file command-line option also sets this value.
 
 'GIT_OBJECT_DIRECTORY'::
If the object storage directory is specified via this
diff --git a/git.c b/git.c
index d33f9b3..b0f473d 100644
--- a/git.c
+++ b/git.c
@@ -8,7 +8,8 @@
 const char git_usage_string[] =
git [--version] [--exec-path[=path]] [--html-path] [--man-path] 
[--info-path]\n
   [-p|--paginate|--no-pager] [--no-replace-objects] 
[--bare]\n
-  [--git-dir=path] [--work-tree=path] 
[--namespace=name]\n
+  [--git-dir=path] [--work-tree=path] 
[--index-file=path]\n
+  [--namespace=name]\n
   [-c name=value] [--help]\n
   command [args];
 
@@ -121,6 +122,20 @@ static int handle_options(const char ***argv, int *argc, 
int *envchanged)
setenv(GIT_WORK_TREE_ENVIRONMENT, cmd + 12, 1);
if (envchanged)
*envchanged = 1;
+   } else if (!strcmp(cmd, --index-file)) {
+   if (*argc  2) {
+   fprintf(stderr, No path given for 
--index-file.\n );
+   usage(git_usage_string);
+   }
+   setenv(INDEX_ENVIRONMENT, (*argv)[1], 1);
+   if (envchanged)
+   *envchanged = 1;
+   (*argv)++;
+   (*argc)--;
+   } else if (!prefixcmp(cmd, --index-file=)) {
+   setenv(INDEX_ENVIRONMENT, cmd + 13, 1);
+   if (envchanged)
+   *envchanged = 1;
} else if (!strcmp(cmd, --bare)) {
static char git_dir[PATH_MAX+1];
is_bare_repository_cfg = 1;
diff --git a/t/t7500-commit.sh b/t/t7500-commit.sh
index 1c908f4..c405a78 100755
--- a/t/t7500-commit.sh
+++ b/t/t7500-commit.sh
@@ -168,6 +168,35 @@ test_expect_success 'using alternate GIT_INDEX_FILE (2)' '
cmp .git/index saved-index /dev/null
 '
 
+test_expect_success 'using alternate --index-file (1)' '
+
+   cp .git/index saved-index 
+   (
+   echo some new content file 
+   index_file=.git/another_index 
+   git --index-file=$index_file add file 
+   git --index-file=$index_file commit -m commit using another 
index 
+   git --index-file=$index_file diff-index --exit-code HEAD 
+   git --index-file=$index_file diff-files --exit-code
+   ) 
+   cmp .git/index saved-index /dev/null
+
+'
+
+test_expect_success 'using alternate --index-file (2)' '
+
+   cp .git/index saved-index 
+   (
+   rm -f .git/no-such-index 
+   index_file=.git/no-such-index 
+   git --index-file=$index_file commit -m commit using 
nonexistent index 
+   test -z $(git --index-file=$index_file ls-files) 
+   test -z $(git --index-file

Re: [PATCH] Documentation/git: add missing info about --git-dir command-line option

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 12/12/2012 20:35, Junio C Hamano ha scritto:
 Manlio Perillo manlio.peri...@gmail.com writes:
 
 The Documentation/git.txt file, in the GIT_DIR environment variable
 section, did not mentioned that this value can also be set using the
 --git-dir command line option.
 ---
 
 s/mentioned/mention/; Also it may help to say
 
   Unlike other environment variables (e.g. GIT_WORK_TREE,
   GIT_NAMESPACE),
 

I'm sorry, I just copied this text as is (I'm lazy) in the commit
message failing to notice the use of the tab character.

When I checked the patch email message, my editor rendered the tab
character as a single space...


That's the reason why I have all my editors configured to never ever use
tabs.


Manlio Perillo
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlDLYUMACgkQscQJ24LbaUTUPACcDhufXkawZZPBV0p/af1GFu1D
/BcAnjPARpeTi4EdyM/3wV0eI9U9Fu51
=rSfl
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] git.txt: add missing info about --git-dir command-line option

[Manlio Perillo]

Unlike other environment variables (e.g. GIT_WORK_TREE, GIT_NAMESPACE),
the Documentation/git.txt file did not mention that the GIT_DIR
environment variable can also be set using the --git-dir command line
option.

Signed-off-by: Manlio Perillo manlio.peri...@gmail.com
---
 Documentation/git.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/git.txt b/Documentation/git.txt
index e643683..60db292 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -650,6 +650,7 @@ git so take care if using Cogito etc.
If the 'GIT_DIR' environment variable is set then it
specifies a path to use instead of the default `.git`
for the base of the repository.
+   The '--git-dir' command-line option also sets this value.
 
 'GIT_WORK_TREE'::
Set the path to the working tree.  The value will not be
-- 
1.8.1.rc1.19.g2021cc5.dirty

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Documentation/git: add missing info about --git-dir command-line option

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 12/12/2012 20:35, Junio C Hamano ha scritto:
 Manlio Perillo manlio.peri...@gmail.com writes:
 
 The Documentation/git.txt file, in the GIT_DIR environment variable
 section, did not mentioned that this value can also be set using the
 --git-dir command line option.
 ---
 
 s/mentioned/mention/; Also it may help to say
 
   Unlike other environment variables (e.g. GIT_WORK_TREE,
   GIT_NAMESPACE),
 
 somewhere in the description.
 
 Please sign-off your patch (see Documentation/SubmittingPatches).
 
 Thanks.
 

Thanks to you.

I have sent the updated patch, let me know if is ok.



Manlio Perillo
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlDKF9YACgkQscQJ24LbaUQyHwCcDiaJjFZ5vwHzxjHyhEBCyFdd
GnIAn34MjoWmQOcLKJEl/EpE0ImeQBLG
=yrux
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Documentation/git: add missing info about --git-dir command-line option

[Manlio Perillo]

The Documentation/git.txt file, in the GIT_DIR environment variable
section, did not mentioned that this value can also be set using the
--git-dir command line option.
---
 Documentation/git.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/git.txt b/Documentation/git.txt
index e643683..60db292 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -650,6 +650,7 @@ git so take care if using Cogito etc.
If the 'GIT_DIR' environment variable is set then it
specifies a path to use instead of the default `.git`
for the base of the repository.
+   The '--git-dir' command-line option also sets this value.
  'GIT_WORK_TREE'::
Set the path to the working tree.  The value will not be
-- 
1.8.0.1.347.gf94c325.dirty

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html