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

I don't understand, sorry. I thought I'd already removed all files from the local tree, in the $ rm *.* move just above the checkout

-----Original Message-----
From: Boyd Stephen Smith Jr. [mailto:bss@iguanasuicide.net] 
Sent: 30 December 2008 21:49
To: Conor Rafferty
Cc: git@vger.kernel.org
Subject: Re: for newbs = little exercise / tutorial / warmup for windows
and other non-sophisticated new Git users :-) [Scanned]

On Tuesday 2008 December 30 15:27:33 you wrote:

Not a bug. git checkout <commit> <paths> does not delete files by design. Try using "git checkout versionB" instead (no paths specified), and it will properly remove AC.txt from your working tree as well as warning you that "You're Doing It Wrong" (tm).

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.

On Tue, 30 Dec 2008, Conor Rafferty wrote:

That removes them from the filesystem, but they're still in the index. And "git checkout <something> ." first gets everything that *is* in "." in <something> into the index, and then gets everything from "." in the index into the filesystem.

I suppose it is questionable as to whether it ought to copy paths that aren't in versionA from the index into the filesystem.

To see this in a bit more detail, do:

$ rm *.* $ git status (notice that the deletes are in the "won't be committed" section)

Now, "git checkout <path>" will discard any changes in the "won't be committed" section for that path. Maybe "git checkout versionA <path>" should only discard changes that are in the "won't be committed" section for filenames that match that path and are in versionA (or are *different* in versionA and not removed?), but I think it's an area where, if you're expecting any particular behavior out of that command, you're likely to be surprised in some way in some situation.

	-Daniel
*This .sig left intentionally blank*

wtf is wrong with

git checkout <something>

??

if you must have

git checkout <something> <paths>

then instead use

git checkout <something> <paths> git clean

but you will lose other files that aren't part of the repo but are still in the project's dir (i.e. untracked files).

On Tue, Dec 30, 2008 at 4:15 PM, Daniel Barkalow <barkalow@iabervon.org> wrote: