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

On Tuesday 2008 December 30 16:36:19 Conor Rafferty wrote:

Yeah, I guess I missed that, and I am seeing some "odd" behavior from git checkout <treeish> <path>, but I'm not an expert on exactly what that is supposed to do, particularly when applied to a directory.

The description is: "When <paths> are given, this command does not switch branches. It updates the named paths in the working tree from the index file, or from a named commit. [...] <tree-ish> argument can be used to specify a specific tree-ish to update the index for the given paths before updating the working tree."

I'm guess what is happening here is that the index is getting updated in a way that includes both the files from the HEAD tree and from the named tree. Then the modified index is written out, outputting all of them, effectively doing some sort of "theirs" merge. It's not quite what I would expect but I don't normally use git checkout <treeish> <path> when path indicates a directory.

You should do a "git status" when you get ls output that is "unexpected". Here, it confirms that the index has been updated (git thinks I've staged some changes).

Personally, I expected "git checkout <treeish> <paths>" to bypass the index entirely, the way "git commit <paths>" does, but this way also makes sense -- at least when applied to a single file. (And probably saves a good number of git add commands...).

In short, while I can't say for sure, I'm pretty sure you don't want the "git commit <treeish> <path>" form and want the "git commit <treeish>" form instead.