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

6 messages from 2008-12-31 to 2008-12-31. Participants: Conor Rafferty, Boyd Stephen Smith Jr., Junio C Hamano, Daniel Barkalow.
Thread: https://gitlist.dev/t/16936

## Conor Rafferty, 2008-12-31 02:22

Subject: RE: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]
Message-ID: <BB5F02FD3789B54E8964D38D6775E718242D36@ALTMORE-SVR.altmore.local>
URL: https://gitlist.dev/e/BB5F02FD3789B54E8964D38D6775E718242D36%40ALTMORE-SVR.altmore.local

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

```

## Boyd Stephen Smith Jr., 2008-12-31 03:40

Subject: Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]
Message-ID: <200812302141.02248.bss@iguanasuicide.net>
URL: https://gitlist.dev/e/200812302141.02248.bss%40iguanasuicide.net
In-Reply-To: <BB5F02FD3789B54E8964D38D6775E718242D36@ALTMORE-SVR.altmore.local>

```
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/                      \_/     

```

## Junio C Hamano, 2008-12-31 04:48

Subject: Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]
Message-ID: <7v7i5hymp7.fsf@gitster.siamese.dyndns.org>
URL: https://gitlist.dev/e/7v7i5hymp7.fsf%40gitster.siamese.dyndns.org
In-Reply-To: <200812302141.02248.bss@iguanasuicide.net>

```
"Boyd Stephen Smith Jr." <bss@iguanasuicide.net> writes:

> 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>", 

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.

```

## Daniel Barkalow, 2008-12-31 05:21

Subject: Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]
Message-ID: <alpine.LNX.1.00.0812302356040.19665@iabervon.org>
URL: https://gitlist.dev/e/alpine.LNX.1.00.0812302356040.19665%40iabervon.org
In-Reply-To: <7v7i5hymp7.fsf@gitster.siamese.dyndns.org>

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

> "Boyd Stephen Smith Jr." <bss@iguanasuicide.net> writes:
> 
> > 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>", 
> 
> 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.

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*

```

## Junio C Hamano, 2008-12-31 06:07

Subject: Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]
Message-ID: <7vzlicyj1o.fsf@gitster.siamese.dyndns.org>
URL: https://gitlist.dev/e/7vzlicyj1o.fsf%40gitster.siamese.dyndns.org
In-Reply-To: <alpine.LNX.1.00.0812302356040.19665@iabervon.org>

```
Daniel Barkalow <barkalow@iabervon.org> writes:

> 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>....
> ...
> (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.)

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.

```

## Boyd Stephen Smith Jr., 2008-12-31 15:14

Subject: Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]
Message-ID: <200812310914.25779.bss@iguanasuicide.net>
URL: https://gitlist.dev/e/200812310914.25779.bss%40iguanasuicide.net
In-Reply-To: <7v7i5hymp7.fsf@gitster.siamese.dyndns.org>

```
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]':
>"Boyd Stephen Smith Jr." <bss@iguanasuicide.net> writes:
>> "git checkout <branch> <paths>" is similar to "hg revert -r <branch>
>> <paths>",
>
>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.

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

>    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.

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>".
-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss@iguanasuicide.net                     ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.net/                      \_/     

```