Re: bug? - git-checkout treeish paths ignores deleted files

From: Wincent Colaiuta <win@wincent.com>
Date: Oct 9, 2007, 10:20 UTC
Message-ID: <766E760C-D3F3-4593-BA95-D547CCAD0E29@wincent.com>
In-Reply-To: <470AF7F1.2010903@gmail.com>

El 9/10/2007, a las 5:39, Mark Levedahl escribió:

Show 9 quoted lines

> I'm not convinced...
>
> "git checkout branch dir" should make dir have the same value it  
> would get if I just did "git checkout branch".  The latter command  
> will ignore files only if they are untracked in *both* HEAD and  
> branch. I fail to see why the path-limited version of git-checkout  
> should give a different result on the part it is asked to affect  
> than the non-path limited version. This is very inconsistent and  
> I'm having a hard time understanding what workflow it will help.

I don't know the historical reasons for the difference but it's explained in the second para of the man page:

    When <paths> are given, this command does not switch branches. It
    updates the named paths in the working tree from the index file  
(i.e.
    it runs git-checkout-index -f -u), or from a named commit.

So when you supply "." as a path it's not actually switching branches. So that's why you see the different behaviour; it's intentionally different. Like I said, I don't know the reasons why but I imagine it's to make it easy to grab specific files from other branches without actually switching.

Cheers, Wincent