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.

-----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 <barkalow@iabervon.org> wrote:

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

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> writes:

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.

After working for some time on top of the current HEAD to make changes to existing files in "lib/" directory, if you notice that none of your changes in the directory does not make any sense, you may rather want to start over from the version that you began with. In such a case, you would make the above request with <tree-ish> equal to HEAD and <paths> equal to "lib", i.e.

    git checkout HEAD lib

and as the end result you may be able to achieve "reverting my crappy changes to all of the files in lib/".

HOWEVER.

Read what the above request says carefully again, and think about what would happen to a path that exists in the work tree but not in the named <tree-ish>.

In other words, what would happen to a new file you added since you started working on top of HEAD?

See?

A new file that you added in lib/ directory since you started working will not be molested in any way, because they do not even exist in the <tree-ish>.

If you think "git checkout <tree-ish> <paths>" has anything to do with reverting, you will keep confusing yourself. The command is "checking out the named paths out of the named tree", and absense of a file is not something that is checked out by this operation.

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

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*

Daniel Barkalow <barkalow@iabervon.org> writes:

I think that may be a good thing to do.

By the way, I am not opposed to have "git $revert <tree-ish> <path>..." that makes the work tree and the index identical to what existed in <tree-ish> at the named <paths>, i.e. checking out "the absense" of files in the named directory if <path> is a subtree. Because it is very established to use the command verb "revert" to mean making a counter-commit by now, we may have to use a word other than "revert" for that purpose, though.

On Tuesday 30 December 2008, Junio C Hamano <gitster@pobox.com> wrote about 'Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]':

That seems similar to "hg revert": Using the -r option, revert the given files or directories to their contents as of a specific revision.

This part is odd to me, but does make some sense. I can only think of a few reasons to retrieve a file from a different tree-ish without immediately turning around and doing "git add <bar>".