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@xxxxxxxxxxxxx> wrote:
> 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).
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
