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

MERCURIAL:

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

Update the repository's working directory (the "working copy") to the
specified revision of the repository or to the tip revision of the
current (named) branch if no revision is specified.  

I'm not looking for much....

-----Original Message-----
From: Jeff Whiteside [mailto:jeff.m.whiteside@gmail.com] 
Sent: 31 December 2008 02:22
To: Daniel Barkalow
Cc: Conor Rafferty; Boyd Stephen Smith Jr.; git@vger.kernel.org
Subject: Re: for newbs = little exercise / tutorial / warmup for windows
and other non-sophisticated new Git users :-) [Scanned]

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

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

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>", 
but the later seems to handle your use case properly.  I don't know much 
about the workings of hg revert -- it might use the history to determine 
what's correct, or completely bypass the existing "index" when determining 
what to drop.  In any case, it seems to work better for what you are trying 
to do.  Why not just use it?

I could do with more hg/bzr/darcs experience myself, but git seems to behave 
the way I like it so it's what I use.  When deciding on the right tool for 
the job, it does help to have many.  "To the man with only a hammer, all 
problems look like nails."

That said, I'm pretty sure that if you hasn't specified '.' and just used "git 
checkout <branch>" you wouldn't have seen those "artifacts".
-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss@iguanasuicide.net                     ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.net/                      \_/