tags:

views:

70

answers:

3

Is there any chance to configure git to autocomplete the hashes when pressing TAB?

Edit:

Please note that this question is not about autocomplete, but about hash autocomplete. See my comment to VonC's answer.

+2  A: 

If you have to consider all hashes from your repo, this is not likely because it wouldn't scale well (if you have several hundreds of commits, tags, ... each with their own hashes, this would quickly take a long time to list them all unless you have some caching system for this hash list)

If you limit the hashes to a fairly recent list (on the current branch for instance), may be, but that won't cover all use cases.

You have here an example of git shell with different kind if tab expansion (in PowerShell), further enhanced here.
Even if your environment has no use for PowerShell, that gives you an idea of "tab expansion" implementation.

VonC
Thanks VonC. I'm asking this question because I was playing with `complete`, but all the commands are pretty expensive. I was hoping for some smart storing of last displayed hashes, e.g. via `git log` or `reflog`. The procedure is always the same: look for hash, then run a command on it. Actually I think it could be done with some bash scripting, although not easily.
takeshin
@takeshin: I agree. I am curious to see if others will come with said "some smart storing of last displayed hashes". So far, they only read your question up to "auto completion", disregarding the "hash" aspect of it completely ;)
VonC
@VonC Well, reading with understanding should be programmers attribute ;)
takeshin
A: 

Under Linux you have git shell: dev-vcs/git-sh, dev-util/easygit. Moreover if you enable bash completion for git you will get autocomplete.

Gadolin
+1  A: 

You can refer to a commit by only its first few characters: git will automatically "autocomplete" internally:

git checkout 9771

works, without having to enter the full hash!

EOL
This is nice, but I don't know whether 3,4,5 or 17 characters are enough.
takeshin
You just need the minimum number of characters that make your hash unambiguous (given your list of revision hashes). Thus, with a single commit, only 1 character is necessary, etc. After 16 commits, you will need at least 2 characters, after 16*16 = 256 commits, 3 characters, etc. Thus, for projects with about 1000 commits, I would guess that 4 characters should be enough most of the time.
EOL