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:
conorr@KINKLADZE /w/GITPLATFORM/swproj $ git status # On branch master
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).
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
From: Boyd Stephen Smith Jr. <hidden> Date: 2016-06-15 22:45:50
On Tuesday 2008 December 30 16:36:19 Conor Rafferty wrote:
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
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.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
From: Daniel Barkalow <hidden> Date: 2016-06-15 22:45:51
On Tue, 30 Dec 2008, Conor Rafferty wrote:
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
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*
From: Jeff Whiteside <hidden> Date: 2016-06-15 22:45:51
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 [off-list ref] wrote:
On Tue, 30 Dec 2008, Conor Rafferty wrote:
quoted
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
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*
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html