Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]

On Tue, 30 Dec 2008, Junio C Hamano wrote:

"Boyd Stephen Smith Jr." [off-list ref] writes:

quoted

On Tuesday 2008 December 30 20:30:46 Conor Rafferty wrote:

quoted

MERCURIAL:

Update
hg update [-C] [-d DATE] [[-r] REV]

Which is the role of "git checkout <branch>"

"git checkout <branch> <paths>" is similar to "hg revert -r <branch> <paths>", 

No it is not.

The form of the command is makes this request:

    Please look into that named <tree-ish>, and check out the named
    <paths> out of it to my work tree.  Because the reason I want them in
    my work tree is so that I can include them as part of the next commit
    I am preparing to create in the index, please update these paths in my
    index while at it.

With that description, there's a bug: in addition to the above, it checks 
out from the index any path which does match the <paths> but isn't in 
<tree-ish>. I think the way to fix that would be to update the work tree 
from read_tree_some() instead of using the "if pathspec_match() ... 
checkout_entry()" loop over the index.

With the current code, you can have git check out a file that you've 
changed/deleted from a tree that doesn't contain it at all (and you get 
the index version). E.g.:

$ rm wt-status.c
$ git checkout e83c5163316f89bfbde7d9ab23ca2e25604af290 wt-status.c
$ ls wt-status.c
wt-status.c

(instead, you should get an error if a <path> doesn't match anything in 
the <tree-ish> and only get those things that it matches in the 
<tree-ish>.)

I think I was too zealous sharing code back in February. I should have a 
patch by the weekend if nobody beats me to it. (And I still think that, if 
you hit this case, you must be confused, but git isn't helping by doing 
what it does.)

	-Daniel
*This .sig left intentionally blank*