From: Holger Hellmuth <hellmuth@ira•uka.de>
To: Yves Goergen <nospam.list@unclassified•de>
Cc: git@vger•kernel.org
Subject: Re: Bug? Git checkout fails with a wrong error message
Date: Fri, 13 Jan 2012 13:50:53 +0100 [thread overview]
Message-ID: <4F1028AD.9080701@ira.uka.de> (raw)
In-Reply-To: <loom.20120112T193624-86@post.gmane.org>
On 12.01.2012 19:44, Yves Goergen wrote:
> Hi,
Important information missing: What version of git are you using? Should
the version number begin with 1.6 or even lower you will get the advice
to update your version to something non-ancient. Lots of bug-fixes
happened in-between.
> I am using Git alone for my local software project in Visual Studio 2010. I've
> been on the master branch most of the time. Recently I created a new branch to
> do a larger refactoring of one of the dialogue windows. I did the following
> modifications:
>
> * Rename Form1 to Form1a (including all depending files)
> * Add new Form1
>
> I checked this change into the branch, say form-refactoring. Interestingly, Git
> didn't notice that I renamed the file Form1.cs into Form1a.cs and created a
> brand new, totally different Form1.cs, but instead it noticed a new Form1a.cs
I assume .cs is a C source file for visual studio, not a generated file,
right ?
> file and found a whole lot of differences between the previous and new Form1.cs
> files. This will of course lead to totally garbaged diffs, but I don't care in
> this case as long as all files are handled correctly in the end.
git does not record renames like cvs/svn do. It operates on snapshots
and infers renames through comparisions. So if the next commit has a
file missing and the same or similar file contents under some different
path, it reports it as a rename. You can try -M with git log or git diff
so that git expends more effort to detect renames+edits. Or you could
avoid doing renames and edits of the same file in the same commit.
But apart from the cosmetic inconvenience of a non-sensical diff this
commit wasn't more difficult or special as any other commit. git doesn't
care if a commit changes one line or a thousand. So I don't this
renaming in itself did somehow confuse git.
> Then I switched back to master to do some other small changes. Nothing
> conflicting. Until now, everything worked fine.
>
> Today, I wanted to switch back to my branch form-refactoring to continue that
> work. But all I get is the following message:
>
> -----
> git.exe checkout form-refactoring
>
> Aborting
> error: The following untracked working tree files would be overwritten by
> checkout:
> Form1.Designer.cs
> Please move or remove them before you can switch branches.
> -----
You didn't mention that filename before (please assume people not
accustomed to the ways of Visual Studio 2010). Is that another file you
renamed and created new in the form-refactoring branch?
What does git diff -- Form1.Designer.cs' say?
What does 'git diff form-refactoring -- Form1.Designer.cs' say?
> What is that supposed to be? The mentioned file is not untracked. Neither in the
> master branch, nor in the form-refactoring branch. It is part of both branches,
> but one is not a descendent of the other (because it was recreated on the
> form-refactoring branch, if that matters). What would happen if I delete it, is
> it gone for good then? I don't trust Git to bring back the correct file if I
You can copy the file to somewhere outside of git and do 'git checkout
-- Form1.Designer.cs'. A comparision of the two files should show you
that git still has the files recorded.
> Right now, I cannot continue with my work because I cannot switch branches. Is
> there an easy solution to this? Is my Git repository broken, all by standard
> operations?
The easy solution is: Make a backup of the repository, then 'git
checkout -f form-refactoring'. My uneducated guess is that the problem
has to do with an old git version and white space or filenames with
different case on a case-insensitive file system or some other problem
that leads to a misinterpretation. But as I said, uneducated guess!
next prev parent reply other threads:[~2012-01-13 12:50 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-12 18:44 Bug? Git checkout fails with a wrong error message Yves Goergen
2012-01-13 12:50 ` Holger Hellmuth [this message]
2012-01-13 17:46 ` Yves Goergen
2012-01-13 19:28 ` Holger Hellmuth
2012-01-15 8:14 ` Yves Goergen
2012-01-16 11:07 ` Holger Hellmuth
2012-01-16 18:50 ` Yves Goergen
2012-01-16 19:09 ` Jeff King
2012-01-16 21:20 ` Yves Goergen
2012-01-16 21:27 ` Jeff King
2012-01-17 7:41 ` Yves Goergen
2012-01-16 19:17 ` Thomas Rast
[not found] ` <4F152767.9010104@unclassified.de>
2012-01-17 8:45 ` Thomas Rast
2012-01-17 17:56 ` Yves Goergen
2012-01-19 10:24 ` Thomas Rast
2012-01-16 21:18 ` Erik Faye-Lund
2012-01-16 18:58 ` Yves Goergen
2012-01-13 17:37 ` Bug! Git merge also " Yves Goergen
2012-01-13 17:50 ` Jeff King
2012-01-13 18:49 ` Yves Goergen
2012-01-13 18:54 ` Jeff King
2012-01-13 19:05 ` Yves Goergen
2012-01-13 17:56 ` Carlos Martín Nieto
2012-01-13 18:59 ` Yves Goergen
2012-01-13 19:34 ` Jakub Narebski
2012-01-15 8:17 ` Yves Goergen
2012-01-15 10:08 ` Jakub Narebski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F1028AD.9080701@ira.uka.de \
--to=hellmuth@ira$(echo .)uka.de \
--cc=git@vger$(echo .)kernel.org \
--cc=nospam.list@unclassified$(echo .)de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox