All of lore.kernel.org
 help / color / mirror / Atom feed
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!

  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.uka.de \
    --cc=git@vger.kernel.org \
    --cc=nospam.list@unclassified.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.