Re: Updated _git completion (not attached)

[Mikael Magnusson <mikachu@xxxxxxxxx>]

On 28 February 2011 18:07, Nikolai Weibull <now@xxxxxxxx> wrote:
> On Mon, Feb 28, 2011 at 17:33, Wayne Davison
> <wayned@xxxxxxxxxxxxxxxxxxxxx> wrote:
>>>
>>> On Sat, Feb 19, 2011 at 02:39:57PM +0100, Simon Ruderich wrote:
>>> - It seems like git checkout doesn't list only modified files but all
>>> files.
>
>> One thing to keep in mind is that it is right for it to list all
>> (known-to-git) files after a tag or hash, since the user may want to change
>> the file to a prior state.  It is only the default "git checkout FILE" that
>> only really has meaning for changed files.
>
>> And, I had thought for sure that
>> git didn't allow filenames after git checkout -f (and indeed, the current
>> completion code doesn't complete files after it), but in my testing of git
>> 1.7.1, it accepted files to force w/o complaint.
>
> If no tree-ish is given it uses HEAD as the tree-ish to look for files
> in.  Perhaps it should only list files modified between HEAD and the
> working tree when the tree-ish is HEAD.

Actually it looks in the index when no tree-ish is given, which is why
it restored the previously specified zsh-4.3.9 version of ChangeLog
when no tree-ish was given; that version was still in the index. If
you want to restore the current branch's version of a file when it has
changed staged, you have to explicitly say HEAD.

(This also applies when you have done changes to a file, git-added
them, and then do more changes. git checkout with no tree-ish and the
filename will then restore the version you last added.)

As far as I can tell, -f only affects behaviour when switching
branches or when specified files have unmerged changes (as in from a
merge or rebase conflict), and not otherwise when specifying explicit
files even when they have unstaged changes.

-- 
Mikael Magnusson