Re: Bug? Git checkout fails with a wrong error message
- From
- Holger Hellmuth <hellmuth@ira.uka.de>
- Date
- Jan 13, 2012, 19:28 UTC
- Message-ID
- <4F1085EC.9010708@ira.uka.de>
- In-Reply-To
- <4F106DDF.4040408@unclassified.de>
Added Peff and Carlos to the CC so they see this part of the thread too.
On 13.01.2012 18:46, Yves Goergen wrote:
Show 16 quoted lines
> On 13.01.2012 13:50 CE(S)T, Holger Hellmuth wrote: >> 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. > > The first bug happened with msysGit 1.7.6 and 1.7.8, the second one > (reported now) with 1.7.8. That update didn't change a thing. > >> I assume .cs is a C source file for visual studio, not a generated file, >> right ? > > .cs is C# code and .Designer.cs files are used internally by the Visual > Studio designer. They're not supposed to be edited by the programmer and > contain lots of stuff that changes all the time. So they are generated > and presented in a different way.
Is it possible that Visual Studio changes them while you are comitting?
Show 9 quoted lines
>> 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. > > I renamed the file and created a new one with the same name. Is it so > simple to crash the Git repository?
Who said anything about crash? git simply doesn't care whether a change is because of a rename. It isn't special or different to any change you can make to a file
Show 17 quoted lines
>>> ----- >>> 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? > > Form1.cs, Form1.Designer.cs and Form1.resx all belong together and are > renamed atomically. If I rename "Form1" in the project, actually these 3 > files are renamed on disk.
As an aside, if .Designer.cs is generated automatically from Form1.cs it shouldn't be tracked at all. Maybe tortoise git has a global gitignore with a line "*.Designer.cs" in it to account for that fact. Maybe this lead to the error message?
Show 7 quoted lines
>> What does git diff -- Form1.Designer.cs' say? > > Nothing. > >> What does 'git diff form-refactoring -- Form1.Designer.cs' say? > > All lines deleted.
Really all lines? That would indicate that you don't have a file Form1.Designer.cs (or an empty one) in your working directory in branch master. In case there is no file (as seen by git) the output of diff should compare with /dev/null aka the void aka <I don't know how this prints on the windows side>. Also notice the line "deleted file mode ..."
> git diff master -- zumf
diff --git a/zumf b/zumf deleted file mode 100644 index 925eccd..0000000 --- a/zumf +++ /dev/null @@ -1 +0,0 @@ Or did you just mean "all the shown lines in the diff were fronted by a minus sign"? Which would just indicate that the file in form-refactoring is a superset of the one in master. (As you can see, actual reproduction of command line output is very helpful to avoid ambiguity and can give further hints)