Re: git-name-rev off-by-one bug

From: Junio C Hamano <junkio@cox.net>
Date: Nov 30, 2005, 08:37 UTC
Message-ID: <7vek4ywmxx.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <7voe43iyyu.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano <junkio@cox.net> writes:

Show 7 quoted lines

> On a related topic of removing unwanted paths, earlier I said
> 2-way is used to make sure "git checkout" takes your changes
> with you when you switch branches.  As a natural consequence of
> this, if you do not have any local changes, "git checkout"
> without "-f" does the right thing -- it removes unwanted paths
> that existed in the original branch but not in the branch you
> are switching to.

Here is an unsolicited advice ("tip of the day").

I was on a branch which had some local "throwaway" changes, and I wanted to switch back to the master branch. To be honest, I even forgot I had local changes there. So I ran "git checkout", and here is what happened.

        junio@siamese:~/git$ git checkout master
        fatal: Entry 'Documentat...' not uptodate. Cannot merge.

The easiest is "git checkout -f master" at this point, but I usually do not do that. If that entry "git checkout" complains about is something that is not in the master branch and I have throwaway changes, "git checkout -f master" would leave that file with throwaway changes behind. So I did this first:

        junio@siamese:~/git$ git reset --hard

This would sync my working tree to the current branch.  Then

        junio@siamese:~/git$ git checkout master

would switch branches properly, removing that new file that should not exist in the working tree.