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

Manlio Perillo [off-list ref] writes:

quoted

	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?

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.

But at that point, if "git mv COPYING README <TAB>" offers only
directories that contain tracked files, the users may get irritated,
because it is likely that the destination directory was created
immediately before the user started typing "git mv".  You will hear
"Surely I created X, it is there, why aren't you showing it to me?"

The updated completion knows what it is doing everywhere else, and
it sets the user-expectation at that level.  Uneven cleverness will
stand out like a sore thumb and hurts the user perception, which is
arguably unfair, but nothing in life is fair X-<.

I think over-showing the choices is much better than hiding some
choices, if we cannot do a perfect completion in some cases.  "You
should know that I won't be moving these files in Y, as I already
marked it to be ignored in the .gitignore file!" is less grave a
gripe than "You know I created X just a minute ago, and it is there,
why aren't you showing it to me?" because you can simply say "but Y
is there as a directory." admitting that you are less clever than
the user expects you to be, but at least you are giving the choice
to the user of not picking it.

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Il 19/12/2012 23:49, Junio C Hamano ha scritto:

Manlio Perillo [off-list ref] writes:

quoted

quoted

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