"Your local changes ... would be overwritten" bug

"Your local changes ... would be overwritten" bug

[Hannu Koivisto]

Greetings,

I have a problem where "git checkout origin/another-branch" in master
should remove a set of files but instead I get:

error: Your local changes to the following files would be overwritten by checkout:
        file1
        file2
        ...
Please, commit your changes or stash them before you can switch branches.
Aborting

(where the files listed are those that should be removed)

The problem occurs only if the checkout is not run in the top level
directory of the repository and the files in question have execute
bit set.  Before checkout, git status says

# On branch master
nothing to commit (working directory clean)

The following script can be used to reproduce the problem:

-------------------------------------------
mkdir temp
cd temp
git init
echo foo > testfile
git add testfile
git commit -m "test1"
echo foo > testfile2
chmod +x testfile2
git add testfile2
git commit -m "test2"
mkdir foo
cd foo
git co master~1
--------------------------------------------

The problem disappears if one removes either the "chmod +x
testfile2" line or the "cd foo" line.

I'm running Cygwin git 1.7.5.1 in Windows XP.

-- 
Hannu

Re: "Your local changes ... would be overwritten" bug

[Matthieu Moy]

Hannu Koivisto <azure@iki.fi> writes:

> The following script can be used to reproduce the problem:

[...]

I cannot reproduce on Linux.

> I'm running Cygwin git 1.7.5.1 in Windows XP.

Probably a dumb question (from a non-windows-user), but why not use the
native Git for windows?

What happens if you run "git status" before running the problematic "git
checkout"? (I'm asking because "git status" refreshes the stat-cache, so
it may change the result)

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: "Your local changes ... would be overwritten" bug

[Vijay Lakshminarayanan]

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

> Hannu Koivisto <azure@iki.fi> writes:
>
>> The following script can be used to reproduce the problem:
>
> [...]
>
> I cannot reproduce on Linux.

I can't either.

>> I'm running Cygwin git 1.7.5.1 in Windows XP.

I'm running cygwin git 1.7.5.1 in Windows Vista.

$ mkdir temp
d temp
git init
echo foo > testfile
git add testfile
git commit -m "test1"
echo foo > testfile2
chmod +x testfile2
git add testfile2
git commit -m "test2"
mkdir foo
cd foo
git co master~1

vijay@balrog ~/foo
$ cd temp

vijay@balrog ~/foo/temp
$ git init
Initialized empty Git repository in /home/vijay/foo/temp/.git/

vijay@balrog ~/foo/temp
$ echo foo > testfile

vijay@balrog ~/foo/temp
$ git add testfile

vijay@balrog ~/foo/temp
$ git commit -m "test1"
[master (root-commit) 7564449] test1
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 testfile

vijay@balrog ~/foo/temp
$ echo foo > testfile2

vijay@balrog ~/foo/temp
$ chmod +x testfile2

vijay@balrog ~/foo/temp
$ git add testfile2

vijay@balrog ~/foo/temp
$ git commit -m "test2"
[master 9675b55] test2

 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100755 testfile2

vijay@balrog ~/foo/temp
$ mkdir foo

vijay@balrog ~/foo/temp
$ cd foo

vijay@balrog ~/foo/temp/foo
$ git co master~1
git: 'co' is not a git command. See 'git --help'.

Did you mean one of these?
        commit
        clone
        log

vijay@balrog ~/foo/temp/foo
$ git checkout master~1
Note: checking out 'master~1'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b new_branch_name

HEAD is now at 7564449... test1

> Probably a dumb question (from a non-windows-user), but why not use the
> native Git for windows?

Do you mean msysgit?  As a GNU/Linux user, I probably don't need to
explain the luxuries a bash prompt gives you.  In this scenario, cygwin
is the closest approximation on Windows system.

msysgit comes with its own bash shell etc (which is good) but rather
than go that integration route, it's much simpler to have git working
within cygwin when you're already used to it.

Cheers
~vijay

Re: "Your local changes ... would be overwritten" bug

[Andrew Ardill]

I can not reproduce on msysgit version 1.7.6.msysgit.0, for what it is worth.

Regards,

Andrew Ardill



On 6 September 2011 04:31, Vijay Lakshminarayanan <laksvij@gmail.com> wrote:
> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>
>> Hannu Koivisto <azure@iki.fi> writes:
>>
>>> The following script can be used to reproduce the problem:
>>
>> [...]
>>
>> I cannot reproduce on Linux.
>
> I can't either.
>
>>> I'm running Cygwin git 1.7.5.1 in Windows XP.
>
> I'm running cygwin git 1.7.5.1 in Windows Vista.
>
> $ mkdir temp
> d temp
> git init
> echo foo > testfile
> git add testfile
> git commit -m "test1"
> echo foo > testfile2
> chmod +x testfile2
> git add testfile2
> git commit -m "test2"
> mkdir foo
> cd foo
> git co master~1
>
> vijay@balrog ~/foo
> $ cd temp
>
> vijay@balrog ~/foo/temp
> $ git init
> Initialized empty Git repository in /home/vijay/foo/temp/.git/
>
> vijay@balrog ~/foo/temp
> $ echo foo > testfile
>
> vijay@balrog ~/foo/temp
> $ git add testfile
>
> vijay@balrog ~/foo/temp
> $ git commit -m "test1"
> [master (root-commit) 7564449] test1
>  1 files changed, 1 insertions(+), 0 deletions(-)
>  create mode 100644 testfile
>
> vijay@balrog ~/foo/temp
> $ echo foo > testfile2
>
> vijay@balrog ~/foo/temp
> $ chmod +x testfile2
>
> vijay@balrog ~/foo/temp
> $ git add testfile2
>
> vijay@balrog ~/foo/temp
> $ git commit -m "test2"
> [master 9675b55] test2
>
>  1 files changed, 1 insertions(+), 0 deletions(-)
>  create mode 100755 testfile2
>
> vijay@balrog ~/foo/temp
> $ mkdir foo
>
> vijay@balrog ~/foo/temp
> $ cd foo
>
> vijay@balrog ~/foo/temp/foo
> $ git co master~1
> git: 'co' is not a git command. See 'git --help'.
>
> Did you mean one of these?
>        commit
>        clone
>        log
>
> vijay@balrog ~/foo/temp/foo
> $ git checkout master~1
> Note: checking out 'master~1'.
>
> You are in 'detached HEAD' state. You can look around, make experimental
> changes and commit them, and you can discard any commits you make in this
> state without impacting any branches by performing another checkout.
>
> If you want to create a new branch to retain commits you create, you may
> do so (now or later) by using -b with the checkout command again. Example:
>
>  git checkout -b new_branch_name
>
> HEAD is now at 7564449... test1
>
>> Probably a dumb question (from a non-windows-user), but why not use the
>> native Git for windows?
>
> Do you mean msysgit?  As a GNU/Linux user, I probably don't need to
> explain the luxuries a bash prompt gives you.  In this scenario, cygwin
> is the closest approximation on Windows system.
>
> msysgit comes with its own bash shell etc (which is good) but rather
> than go that integration route, it's much simpler to have git working
> within cygwin when you're already used to it.
>
> Cheers
> ~vijay
> --
> 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
>

Re: "Your local changes ... would be overwritten" bug

[Clemens Buchacher]

Hi,

On Mon, Sep 05, 2011 at 07:25:53PM +0300, Hannu Koivisto wrote:
> 
> I have a problem where "git checkout origin/another-branch" in master
> should remove a set of files but instead I get:
> 
> error: Your local changes to the following files would be overwritten by checkout:
>         file1
>         file2
>         ...
> Please, commit your changes or stash them before you can switch branches.
> Aborting

Could you set a breakpoint in add_rejected_path and send us the
backtrace? Like this:

$ gdb --args git checkout origin/another-branch
>> break add_rejected_path
>> r
... wait for break ...
>> bt

Thanks,
Clemens

Re: "Your local changes ... would be overwritten" bug

[Hannu Koivisto]

Clemens Buchacher <drizzd@aon.at> writes:

> Could you set a breakpoint in add_rejected_path and send us the
> backtrace? Like this:

Since the binary from the package doesn't come with debug
information, I built the latest git master (1.7.7.rc0.72.g4b5ea)
and it turns out the problem cannot be reproduced with this version
anymore.  I guess I should have tried that right away.  Sorry for
the noise.

-- 
Hannu