Re: Change in "git checkout" behaviour between 1.6.0.2 and 1.6.0.3

From: Bruce Stephens <bruce.stephens@isode.com>
Date: Nov 12, 2008, 17:40 UTC
Message-ID: <804p2cq1vc.fsf@tiny.isode.net>
In-Reply-To: <80wsf9ovsp.fsf@tiny.isode.net>

Bruce Stephens <bruce.stephens@isode.com> writes:

Show 12 quoted lines

> The following works fine with 1.6.0.2 and before, but not 1.6.0.3 or
> later:
>
> 	git clone -n git git-test
>         cd git-test
>         git checkout -b work v1.6.0.2
>
> When it breaks, the error is:
>
> 	error: Entry '.gitignore' would be overwritten by merge. Cannot merge.
>
> I'm guessing it's a bug rather than a deliberate change?

According to "git bisect", the commit that caused this is the following one. Perhaps "git clone -n" doesn't start out with the index empty in the relevant sense?

commit 5521883490e85f4d973141972cf16f89a79f1979
Author: Junio C Hamano <gitster@pobox.com>
Date:   Sun Sep 7 19:49:25 2008 -0700

    checkout: do not lose staged removal
    
    The logic to checkout a different commit implements the safety to never
    lose user's local changes.  For example, switching from a commit to
    another commit, when you have changed a path that is different between
    them, need to merge your changes to the version from the switched-to
    commit, which you may not necessarily be able to resolve easily.  By
    default, "git checkout" refused to switch branches, to give you a chance
    to stash your local changes (or use "-m" to merge, accepting the risks of
    getting conflicts).
    
    This safety, however, had one deliberate hole since early June 2005.  When
    your local change was to remove a path (and optionally to stage that
    removal), the command checked out the path from the switched-to commit
    nevertheless.
    
    This was to allow an initial checkout to happen smoothly (e.g. an initial
    checkout is done by starting with an empty index and switching from the
    commit at the HEAD to the same commit).  We can tighten the rule slightly
    to allow this special case to pass, without losing sight of removal
    explicitly done by the user, by noticing if the index is truly empty when
    the operation begins.
    
    For historical background, see:
    
        http://thread.gmane.org/gmane.comp.version-control.git/4641/focus=4646
    
    This case is marked as *0* in the message, which both Linus and I said "it
    feels somewhat wrong but otherwise we cannot start from an empty index".
    
    Signed-off-by: Junio C Hamano <gitster@pobox.com>