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

From: Sitaram Chamarty <sitaramc@gmail.com>
Date: Dec 31, 2008, 13:37 UTC
Message-ID: <slrnglmtdd.v54.sitaramc@sitaramc.homelinux.net>
In-Reply-To: <gjfn28$3k2$4@ger.gmane.org>

a quick comment: you don't need to use the sha1 to create a tag at the current HEAD. "git tag newtag sha" can be shortened to "git tag newtag" if the sha is for the latest commit you did. Like the "." thing, I'd be curious where you picked up this habit...

On 2008-12-31, Zorba <cr@altmore.co.uk> wrote:

Show 7 quoted lines

> Why should
>
> $ git checkout <version> .
>
> screw things up for
>
> $ git checkout <version>

These are quite different operations so yes you could say they should have used some other name instead of overloading two different functions on the same command. But to be fair, the doc is fairly clear, in the first 2 paras.

And really, if I understand all your angst and what you're trying to do, you just have to stop using the "." and -- if you want untracked files gone each time you switch to an older version -- use git clean. See below.

I have snipped your log heavily but it should still be fairly simple to follow which piece I am referring to below:

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

> $ git rm AC.txt
> $ git add BC.txt
> $ git commit -m "version B"
> $ git tag versionB fad9

> $ cat > AC.txt
> $ ls
> ABC.txt  AC.txt  BC.txt  C.txt

> $ git reset --hard versionB
> HEAD is now at fad9c29 version B
> $ ls
> ABC.txt  AC.txt  BC.txt  C.txt

you're wondering why AC.txt is still hanging around when resetting to a commit where that file was explicitly deleted?

A commit represents a state, not a set of actions.

"versionB" doesn't represent a "delete of AC.txt", plus an "add of BC.txt". It represents a state where ABC.txt and BC.txt exist, that's it.

So AC.txt is now just an untracked file at the point you do the reset, as you would have seen if you did a "git status".

A reset will not touch untracked files -- hardly any operation will touch an untracked file actually.

If you really want that functionality, use git clean after
the reset, this is the only command I know that deletes
untracked files:
        git clean -d -f
        # or first try with "-n" for a "dry-run"

[later]

> $ git checkout versionA
> $ ls
> ABC.txt  AC.txt  comment.txt

> $ git checkout versionB
> $ ls
> ABC.txt  BC.txt  comment.txt

And now you're wondering what happened to "AC.txt"? Well this time it's a known and tracked file for the current state (versionA), so it is a candidate for removal/change as dictated by the new state you're going to.

I should also mention that you have not yet tried the case where you have local modifications to some file that is known to both the current branch and the branch you're switching to. "git help checkout" and look for the word "merge" and read up the two places it is relevant to this context (one a description and one an example).