Bug? Git checkout fails with a wrong error message

Bug? Git checkout fails with a wrong error message

[Yves Goergen]

Hi,

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
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.

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.
-----

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
delete something now. I did not play with any file at all outside of my
mentioned Git operations, so why should I play around with any file to continue
using Git operations now? Git broke it, Git's supposed to handle it now!

Here's some other input:

There are no uncommitted changes in my working directory. 'git status' doesn't
list anything.

The file in question is not untracked. Right now on the master branch, it has a
green checkmark in Explorer (provided by TortoiseGit) and it has a history as
well. There are more Form....Designer.cs files that don't cause any trouble.

'git clean -f -d', 'git reset --hard HEAD', 'git stash' do nothing and don't
help resolving the issue.

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?

Re: Bug? Git checkout fails with a wrong error message

[Holger Hellmuth]

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!

Re: Bug? Git checkout fails with a wrong error message

[Yves Goergen]

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.

> 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?

>> -----
>> 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.

> What does git diff -- Form1.Designer.cs' say?

Nothing.

> What does 'git diff form-refactoring -- Form1.Designer.cs' say?

All lines deleted.

Will this message also appear on the mailing list where I posted my
first message with Gmane? (That's the only thing I've found on the
official Git website.)

-- 
Yves Goergen "LonelyPixel" <nospam.list@unclassified.de>
Visit my web laboratory at http://beta.unclassified.de

Re: Bug? Git checkout fails with a wrong error message

[Holger Hellmuth]

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:
> 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?

>> 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


>>> -----
>>> 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?

>> 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)

Re: Bug? Git checkout fails with a wrong error message

[Yves Goergen]

On 13.01.2012 20:28 CE(S)T, Holger Hellmuth wrote:
> Is it possible that Visual Studio changes them while you are comitting?

No. Those files may only be modified while open.

>> 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

Well, there is a tracked file about which Git says it's untracked. How
would you describe such internal inconsistency? Maybe corruption would
fit better.

> As an aside, if .Designer.cs is generated automatically from Form1.cs it 
> shouldn't be tracked at all.

Of course, it's important! The file contains everything I draw in the UI
designer. I just don't write that myself which is why I rarely see its
contents.

> 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?

It hasn't. This is already triple-checked by now. The file really is
definitely not ignored by any of the both ignore/exclude files known to me.

>>> 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?

I don't have the time to re-check right now, but I remember seeing a
valid file beginning and end and no gaps in between. So I think it was
all files.

> 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"?

Yes, and in dark red.

> 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)

That was some kind of less display. I could have attached a screenshot
to show it. It's not common or especially simple to include console
output on Windows, as there often is no console at all.

-- 
Yves Goergen "LonelyPixel" <nospam.list@unclassified.de>
Visit my web laboratory at http://beta.unclassified.de

Re: Bug? Git checkout fails with a wrong error message

[Holger Hellmuth]

On 15.01.2012 09:14, Yves Goergen wrote:
> On 13.01.2012 20:28 CE(S)T, Holger Hellmuth wrote:
>> Is it possible that Visual Studio changes them while you are comitting?
>
> No. Those files may only be modified while open.
>
>>> 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
>
> Well, there is a tracked file about which Git says it's untracked. How
> would you describe such internal inconsistency? Maybe corruption would
> fit better.

The original point I was trying to make was that git rename is made out 
of the rather simple operations git add <newname> and git rm <oldname>. 
Not a seldom used function but the basic operations of the vcs. It must 
be one heck of a corner case or a bit flip in the hardware.

The most likely place where the corruption could be is the index. This 
is actually a simple file located in .git\ that can be recreated by 
deleting that file and doing "git reset". I would shut down tortoise-git 
(i.e. the explorer) before doing this and use the command line.

Re: Bug? Git checkout fails with a wrong error message

[Yves Goergen]

It's getting more weird. I believe that (msys)Git doesn't really know
how the filesystem on its operating system works. I have made some more
changes now and want to commit them. TortoiseGit reports the files
Form1.Designer.cs and Form1.designer.cs (note the case difference) as
modified and ready to commit. How is that supposed to work? On Windows,
file names are case-insensitive (as on MacOS X) and both names refer to
the absolute same file. 'git status' has the very same listing with that
same file twice.

What else is now broken in my repository?

If the index is such a problem child, how can I safely delete it
completely and maybe have it regenerated if Git can't live without it?

-- 
Yves Goergen "LonelyPixel" <nospam.list@unclassified.de>
Visit my web laboratory at http://beta.unclassified.de

Re: Bug? Git checkout fails with a wrong error message

[Jeff King]

On Mon, Jan 16, 2012 at 07:50:51PM +0100, Yves Goergen wrote:

> It's getting more weird. I believe that (msys)Git doesn't really know
> how the filesystem on its operating system works. I have made some more
> changes now and want to commit them. TortoiseGit reports the files
> Form1.Designer.cs and Form1.designer.cs (note the case difference) as
> modified and ready to commit. How is that supposed to work? On Windows,
> file names are case-insensitive (as on MacOS X) and both names refer to
> the absolute same file. 'git status' has the very same listing with that
> same file twice.

What is the output of "git config core.ignorecase" in your repository?

> If the index is such a problem child, how can I safely delete it
> completely and maybe have it regenerated if Git can't live without it?

If you delete your index, it will appear to git as if you have staged
all files for deletion (if you run "git status", for example). You can
then run "git reset" to regenerate it based on the last commit.

But I doubt that will help your problem. It seems unlikely to me that
the source of the problem is a corrupted index, but rather is some
corner case in case-insensitive comparisons between the index and the
working tree.

-Peff

Re: Bug? Git checkout fails with a wrong error message

[Yves Goergen]

On 16.01.2012 20:09 CE(S)T, Jeff King wrote:
> What is the output of "git config core.ignorecase" in your repository?

None, i.e. an empty line.

-- 
Yves Goergen "LonelyPixel" <nospam.list@unclassified.de>
Visit my web laboratory at http://beta.unclassified.de

Re: Bug? Git checkout fails with a wrong error message

[Jeff King]

On Mon, Jan 16, 2012 at 10:20:42PM +0100, Yves Goergen wrote:

> On 16.01.2012 20:09 CE(S)T, Jeff King wrote:
> > What is the output of "git config core.ignorecase" in your repository?
> 
> None, i.e. an empty line.

That's odd. When the repository is first created, git will do a test to
see whether the filesystem supports case-sensitivity, and will set
core.ignorecase if it does not. Might this repository have been created
on a different filesystem, and then moved onto the case-insensitive
filesystem?

Or might it have been created by something other than core git? I don't
know whether one can create a repo in TortoiseGit, or if so how it does
so.

In any case, try doing:

  git config core.ignorecase true

and see if that clears up your problems.

-Peff

Re: Bug? Git checkout fails with a wrong error message

[Yves Goergen]

On 16.01.2012 22:27 CE(S)T, Jeff King wrote:
> On Mon, Jan 16, 2012 at 10:20:42PM +0100, Yves Goergen wrote:
> 
>> On 16.01.2012 20:09 CE(S)T, Jeff King wrote:
>>> What is the output of "git config core.ignorecase" in your repository?
>> None, i.e. an empty line.
> 
> That's odd. When the repository is first created, git will do a test to
> see whether the filesystem supports case-sensitivity, and will set
> core.ignorecase if it does not. Might this repository have been created
> on a different filesystem, and then moved onto the case-insensitive
> filesystem?
> 
> Or might it have been created by something other than core git? I don't
> know whether one can create a repo in TortoiseGit, or if so how it does
> so.

It may have been created through the Visual Studio source provider for
Git, which is configured to use TortoiseGit which in turn uses msysGit.
But I have not written any of those programmes so I cannot guarantee for
what they do.

> In any case, try doing:
> 
>   git config core.ignorecase true
> 
> and see if that clears up your problems.

'git config core.ignorecase' now outputs "true" but I can still commit
the same file (modified) twice. So this doesn't help.

Meanwhile I have browsed my other code projects and found that the
designer-generated file name is sometimes with a "D" and sometimes with
a "d", so it's usually inconsistent. I haven't figured out where that
comes from but it means that this is a common issue that Git needs to
handle well to be usable on Windows. But we're not there yet.

-- 
Yves Goergen "LonelyPixel" <nospam.list@unclassified.de>
Visit my web laboratory at http://beta.unclassified.de

Re: Bug? Git checkout fails with a wrong error message

[Thomas Rast]

Yves Goergen <nospam.list@unclassified.de> writes:

> It's getting more weird. I believe that (msys)Git doesn't really know
> how the filesystem on its operating system works. I have made some more
> changes now and want to commit them. TortoiseGit reports the files
> Form1.Designer.cs and Form1.designer.cs (note the case difference) as
> modified and ready to commit. How is that supposed to work?

Depends.

If you work together with developers who have a case-sensitive FS (such
as Linux, or with the right options OS X), it's entirely possible that
this file exists in both spellings within the repository.

Otherwise, because Git needs to have the ability to store such
spellings, there are some ways of introducing them (e.g.,
git-update-index).

I suspect the adoption rate of TortoiseGit across this list is about 0%,
partly because it is a Windows-only tool, partly because it was written
almost entirely without interacting with the Git list.  So speaking in
TortoiseGit terms here will most likely get you nowhere.

> If the index is such a problem child, how can I safely delete it
> completely and maybe have it regenerated if Git can't live without it?

The index is not only, as its name might imply, a throw-away cache.  It
is also used as the area where you prepare the contents of the next
commit, and thus might hold data you do not want to lose.  Nevertheless,
you can discard and reset it to the contents of HEAD with

  rm -f .git/index
  git reset

> Great, I have the same file with an equal name twice in my repository
> (with 'git ls-files').
> 
> How stupid! Git, go learn file names.

Please cut&paste (!) actual command invocations (!) and outputs.

To see why this is important, consider

  "I have the same file with an equal name twice in my repository"

Judging by how this thread is going, there are at least four ways this
could be interpreted:

* You have the byte-for-byte identical file name listed twice in the
  index.  That would be a pretty bad bug.

* Ditto, but in a commit.

* You have two filenames in the index that differ only by case, which
  makes them identical to your OS.

* Ditto, but in a commit.

See what I mean?

So please, let's be precise.  You could start by cut&pasting the outputs
of the following commands:

  git ls-tree -r HEAD
  git ls-files --debug
  git status -s

Otherwise, you can keep throwing around fuzzy complaints all you want
but nobody will be able to help you because we cannot determine the
exact state that your repository is in.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

Re: Bug? Git checkout fails with a wrong error message

[Thomas Rast]

Yves Goergen <nospam.list@unclassified.de> writes:

> On 16.01.2012 20:17 CE(S)T, Thomas Rast wrote:
>> If you work together with developers who have a case-sensitive FS (such
>> as Linux, or with the right options OS X), it's entirely possible that
>> this file exists in both spellings within the repository.
>
> Just FTR, I am working on the project alone, only on Windows with Visual
> Studio 2010 and I have two copies of the repository which I am
> occasionally synchronising via a USB memory stick when I work on the
> other machine. I have not pulled anything since the first issue came up
> on last Friday. No case-sensitive filesystem in the game.

Ok.

  $ git ls-tree -r HEAD
  100644 blob 5369994b8f905514661ee58b396dec31f8575a4d    PosterWantsItCensored.Designer.cs
  100644 blob 5369994b8f905514661ee58b396dec31f8575a4d    PosterWantsItCensored.designer.cs
  ^      ^    ^
  |      |    content hash
  |      type
  file mode

That tells us that you have identical file contents in two files whose
names differ only in case.

This is important: Different name for git.  Same name for OS.  Same
contents.

That should also settle your remark at the end:

> I find it interesting to see that both files with the equal file name
> (like what the only relevant file system considers equal) have the same
> hash value. Does that qualify for your description of the "pretty bad bug"?

No, not a bug, just the same contents.

[And before you sue me for disclosing the SHA1 above: inferring the
contents of the file from the SHA1 is equivalent to breaking SHA1.  If
anyone could, he'd already be busy writing a paper about it (or perhaps
working for the NSA).]

>> * You have the byte-for-byte identical file name listed twice in the
>>   index.  That would be a pretty bad bug.
>
> The index should usually be empty here, I guess. I really do not use
> it.  No index interaction at all.

Please read up on the index before making such statements.  You do use
the index, because it is a very important part of how git operates
whenever the operation also involves the worktree.  And except in border
cases (new empty repo etc.) it should never be empty.

Your paste of

  $ git status -s
  [no output]

tells us that the index has *no differences* to your worktree, nor to
HEAD.


So in summary, the picture in your repository is:

* Somehow you got a different-only-in-case file pair into your
  repository.  It's already in HEAD.  See below.

* The index and worktree are healthy and unchanged (w.r.t. HEAD) from
  Git's POV.  (This is possible despite the different-only-in-case files
  because they have the same contents.)

For now I'm siding with Erik's theory

Erik Faye-Lund wrote:
} Very speculative comment: This might be a bug in TortoiseGit. Looking
} at the sources, it seems they are using libgit2 to mess around with
} the index; perhaps it's case-sensitivity code isn't as well tested as
} Git for Windows'?

It would also be interesting to know for how long this problem has
existed.  You can search for the offending commit with something like

  git log --name-status --diff-filter=A -- "PosterWantsItCensored.*"

which should normally give you just one or two commits, namely the
one(s) that introduced the two files.

As for the fix, there are two-and-two-thirds cases.  First I'd like to
point out, however, that I have no idea how core.ignoreCase interacts
with rm --cached.  I'm assuming you have to set it to 'false' for the
recipes below to work.  Erik or Peff may correct me.  You should set it
to 'true' again for real work.

Case 1: The commit that introduced the second spelling is HEAD

  In this case you're sort of lucky because it's easy to fix.  You can
  do

    git rm --cached PosterWantsItCensored.designer.cs

  to get rid of the spelling you do not want.  Then run

    git status -s

  again to verify that it did the right thing; it should say

    D  PosterWantsItCensored.designer.cs

  where it's important that a) the other spelling does *not* show up in
  the list anywhere and b) the D is in the leftmost column.  Once you
  have verified this, run

    git commit --amend

  to fix HEAD.

Case 2a: The commit that introduced it is older, but you don't care if
         you cannot sanely checkout old commits

  This is the case that I personally would never choose, since I care
  about history, but for completeness: proceed as for case 1, except at
  the end run

    git commit  # no --amend

  and write a nice message saying that you fixed the
  different-only-in-case issue.

Case 2b: The commit that introduced it is older, but history since its
         parent has been linear (use gitk or some such to establish
         this)

  First run

    git log --full-history --oneline -- "PosterWantsItCensored.*"

  to see which commits touched the file.  Let C be the SHA1 (or a unique
  prefix) of the earliest commit that contains
  PosterWantsItCensored.designer.cs (i.e., the wrong spelling) as
  established earlier.  Then run

    git rebase -i C^

  (That's right, the SHA1 of C and then a hat.)

  In the editor that pops up, change 'pick' to 'edit' on every line that
  shows a SHA1 you found in the preceding git-log command.  Save and
  exit.

  Whenever rebase stops to let you edit (you can tell by the advice
  messages it gives you), run

    git ls-tree HEAD -- PosterWantsItCensored.designer.cs PosterWantsItCensored.Designer.cs

  and check whether the SHA1s are different.  Judging by what you said
  they should always be the same (otherwise please come back for more
  advice).  You can then again do something very similar to Case 1 to
  the commit you're editing, like

    git rm --cached PosterWantsItCensored.designer.cs
    git commit --amend

  and finally

    git rebase --continue

  to edit the next commit.  Repeat until the rebase is complete.

Case 2c: History wasn't linear since C; or you're just lazy and have a
         good backup

  The all-safeties-off, please-fix-it-for-me version goes

    git filter-branch --tag-name-filter cat --index-filter '
      git rm --ignore-unmatch --cached PosterWantsItCensored.designer.cs
    ' -- --all

  I'm dead serious about the safeties off.  You have been warned.

I have not tested most of this because it would simply take even more
time than writing an essay-length email.  If something fails or got you
confused, paste everything you did and the full output again so we can
establish what happened.

All sub-items of case 2 rewrite history.  You will have to force the
push to your "hub" repository that you use to exchange history, and you
may have to reset or rebase in the other repository.  Read e.g. the
'recovering from upstream rebase' section in man git-rebase.

> (What a mess it would be if I committed something different than my
> working directory, however that works.)

You should really read up on this, e.g.

  http://tomayko.com/writings/the-thing-about-git

AFAIK everyone who groks the feature uses it daily.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

Re: Bug? Git checkout fails with a wrong error message

[Yves Goergen]

On 17.01.2012 09:45 CE(S)T, Thomas Rast wrote:
> It would also be interesting to know for how long this problem has
> existed.  You can search for the offending commit with something like
> 
>   git log --name-status --diff-filter=A -- "PosterWantsItCensored.*"
> 
> which should normally give you just one or two commits, namely the
> one(s) that introduced the two files.

I have found two commits adding that file. The second one has the file
with the then-already-present name modified and the new spelling added.
I could have noticed that at commit time, but that's the very commit
where I also renamed the original files and recreated them in the Forms
designer. 1) This may have led me to overlook that additional add and 2)
this may be the source of the spelling difference because the file was
newly created.

> As for the fix, there are two-and-two-thirds cases. (...)

That all sounds quite complicated. The "offending" commit is quite a
while back so replacing the last commit is not a solution.

This is just my personal repository that should help me out with finding
changes when I find something broken that wasn't before. Deleting and
recreating the "hub" (bare) and the other working repository would be
okay for me in this case. I have decided that it is also okay to fix the
error by new commits. To avoid all further issues with this, I have
renamed the file, committed the deletion, renamed it back and then
committed the add. The revsion in between won't compile, but it's got a
message with it and the compiler error would be obvious.

> You should really read up on this, e.g.
> 
>   http://tomayko.com/writings/the-thing-about-git
> 
> AFAIK everyone who groks the feature uses it daily.

It's on my to-read list. Looks like an interesting article from reading
the beginning of it.

I have done a test, too: I have set the core.ignorecase setting to false
(or deleted its entry) and then renamed one of the files in my working
directory only in case. TortoiseGit has offered me adding the new
spelling for a commit. After setting the core.ignorecase setting to
true, it has not offered any change to commit anymore. So it looks like
this is just the setting that every repository for Windows use should -
no - must have, and it was missing here.

Just like that stupid autocrlf that causes more issues than it solves. I
regularly see files with all lines changed and the diff says that both
files only differ in line endings. But I have no sure observation on
whether that value was set or unset in those cases. I'll have to look
after that, too.

These two config settings are not cloned with the repository, are they?

Also, TortoiseGit already sets ignorecase = true. So maybe the Visual
Studio provider does the init on its own and is missing that. Or I have
at some time cloned the repository and the setting wasn't copied over.

-- 
Yves Goergen "LonelyPixel" <nospam.list@unclassified.de>
Visit my web laboratory at http://beta.unclassified.de

Re: Bug? Git checkout fails with a wrong error message

[Thomas Rast]

Glad that you could fix your repository.

Yves Goergen <nospam.list@unclassified.de> writes:

> Just like that stupid autocrlf that causes more issues than it solves. I
> regularly see files with all lines changed and the diff says that both
> files only differ in line endings. But I have no sure observation on
> whether that value was set or unset in those cases. I'll have to look
> after that, too.

Just please remember what I tried to teach you in this thread: copy and
paste actual command invocations and outputs, and let us do the
interpretation.  With CRLF problems, it may in addition help to pipe
through a utility that shows the presence or absence of \r, such as 'cat
-v'.

> These two config settings are not cloned with the repository, are they?

Neither config nor hooks are cloned.

> Also, TortoiseGit already sets ignorecase = true. So maybe the Visual
> Studio provider does the init on its own and is missing that. Or I have
> at some time cloned the repository and the setting wasn't copied over.

git-clone also autodetects the setting as part of initializing the
clone.  (Copying over the repository from a case-sensitive medium using
a case-sensitive OS would of course leave it unset.)

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

Re: Bug? Git checkout fails with a wrong error message

[Erik Faye-Lund]

On Mon, Jan 16, 2012 at 7:50 PM, Yves Goergen
<nospam.list@unclassified.de> wrote:
> It's getting more weird. I believe that (msys)Git doesn't really know
> how the filesystem on its operating system works.

Git for Windows know how the file-system works, and tries to prevent
you from shooting yourself in the leg by being case-insensitive when
matching the index and the working copy. But there is an opt-out for
this, which is controlled by the configuration option core.ignorecase,
which Peff already asked about. This option is supposed to be enabled
by default on Windows.

What you are describing sounds like that option might have gotten
disabled somehow. But it might be something else, see below.

> I have made some more
> changes now and want to commit them. TortoiseGit reports the files
> Form1.Designer.cs and Form1.designer.cs (note the case difference) as
> modified and ready to commit. How is that supposed to work?

Very speculative comment: This might be a bug in TortoiseGit. Looking
at the sources, it seems they are using libgit2 to mess around with
the index; perhaps it's case-sensitivity code isn't as well tested as
Git for Windows'?

For instance, they do their own index and tree sorting, in an attempt
to be case sensitive:

http://code.google.com/p/tortoisegit/source/diff?spec=svnf151c0ddf205fa1fc1ff886b8cfc4af87d373b26&r=f151c0ddf205fa1fc1ff886b8cfc4af87d373b26&format=side&path=/src/Git/GitIndex.cpp

Re: Bug? Git checkout fails with a wrong error message

[Yves Goergen]

Great, I have the same file with an equal name twice in my repository
(with 'git ls-files').

How stupid! Git, go learn file names.

I've read (and seen) bad things about Git and Windows, and I knew the
Great Failure Day would eventually come. And I've read that Mercurial
would be better suitable for Windows. You don't know anything about
that, do you?

-- 
Yves Goergen "LonelyPixel" <nospam.list@unclassified.de>
Visit my web laboratory at http://beta.unclassified.de

Bug! Git merge also fails with a wrong error message

[Yves Goergen]

I have updates to this issue.

After asking several people who didn't believe me,
after all I could pass all checks to ensure that
the file in question really is tracked, despite the error
message telling it is not. (The file has a history, it is
part of the branch,
git status behaves as expected when I rename it, and so on.)

I had found a workaround hack to access my
data again: I have cloned the repo
into another directory, then switched to
the branch in there (it actually
worked) and used BeyondCompare to manually(!)
switch my original repo and
working directory by copying some (not all) files
in .git and all differences in
the working directory.

That worked fine at first, I could commit to that branch.

Today I wanted to merge that branch into master again.
Switching to master was
fine, but merging from the form-refactoring branch
now fails for the very same
"reason":

-----
git.exe merge    --no-commit form-refactoring

error: The following untracked working tree files
would be overwritten by merge:
Form1.Designer.cs
Please move or remove them before you can merge.
Aborting
-----

Again, that file is NOT untracked. Git just fails
processing its own data. I
cannot move that file because it is part of the
other branch and must be merged now.

Am I now supposed to checkout both branches and
do the merge somehow on my own?

Maybe it's not a good idea to use branching and
then rename, create and delete
files on that branch, as switching and merging
fail completely afterwards. And
in the end, maybe Git isn't all that good and
some of the alternatives with real
file tracking should be preferred.

I, for one, have lost a great amount of trust
in Git in the last two days.

(Sorry for the formatting mess, but the stupid Gmane
post editor forced me to do that or it wouldn't
accept my message... Don't you have a real mailing
list, if there's no web forum??)

Re: Bug! Git merge also fails with a wrong error message

[Jeff King]

On Fri, Jan 13, 2012 at 05:37:38PM +0000, Yves Goergen wrote:

> After asking several people who didn't believe me,
> after all I could pass all checks to ensure that
> the file in question really is tracked, despite the error
> message telling it is not. (The file has a history, it is
> part of the branch,
> git status behaves as expected when I rename it, and so on.)

Whether a file in the working tree is tracked or not does not have to do
with the history, but rather with whether it is mentioned in the index.

Does the file appear in "git ls-files"?

It sounds like you are perhaps making changes in the working tree and
index, and then trying to checkout/merge on top of that. In that case
"git status" would report the file as renamed, but it's possible the
file is still in the working tree. From git's perspective the file is no
longer tracked, but the operations you are requesting would overwrite
the new contents (and git is being safe by refusing to do so).

Generally you don't want to merge with uncommitted changes like this.
You would want to commit them and then do your merge.

But even if you do commit, the question still remains: if you have
committed the removal of this file, then why is it still there? Is
something else creating it after you have deleted it?

-Peff

Re: Bug! Git merge also fails with a wrong error message

[Yves Goergen]

On 13.01.2012 18:50 CE(S)T, Jeff King wrote:
> Whether a file in the working tree is tracked or not does not have to do
> with the history, but rather with whether it is mentioned in the index.

I'm not using the index. In fact I don't even know how that what I have
read about it can be useful.

> Does the file appear in "git ls-files"?

Yes, it's in the list along with all other files.

> It sounds like you are perhaps making changes in the working tree and
> index, and then trying to checkout/merge on top of that. In that case
> "git status" would report the file as renamed, but it's possible the
> file is still in the working tree. From git's perspective the file is no
> longer tracked, but the operations you are requesting would overwrite
> the new contents (and git is being safe by refusing to do so).

Here's the git status output:
# On branch master
nothing to commit (working directory clean)

I have switched to master and the very next action was trying the merge.
There's no change in the working directory, and nothing uncommitted.

-- 
Yves Goergen "LonelyPixel" <nospam.list@unclassified.de>
Visit my web laboratory at http://beta.unclassified.de

Re: Bug! Git merge also fails with a wrong error message

[Jeff King]

On Fri, Jan 13, 2012 at 07:49:17PM +0100, Yves Goergen wrote:

> On 13.01.2012 18:50 CE(S)T, Jeff King wrote:
> > Whether a file in the working tree is tracked or not does not have to do
> > with the history, but rather with whether it is mentioned in the index.
> 
> I'm not using the index. In fact I don't even know how that what I have
> read about it can be useful.

Whether you realize it or not, git is using the index to store state.
When you "git add", "git rm", or "git mv", it is updating the index.

> > Does the file appear in "git ls-files"?
> 
> Yes, it's in the list along with all other files.

Then it should be considered tracked, and there's a bug.

I notice that in your first mail, you mentioned a problem with
"checkout", and in the second one, a problem with "merge". Do you still
have the repo around with the "checkout" problem? If so, is the file
also in your "git ls-files" output in that repo?

It is much more likely to me that there is a bug in the merge than in
regular checkout (because merge has many complex corner cases
surrounding the 3-way merge, whereas checkout is simply moving from one
state to another). I'd like to make sure we're not seeing two different
problems.

> Here's the git status output:
> # On branch master
> nothing to commit (working directory clean)
> 
> I have switched to master and the very next action was trying the merge.
> There's no change in the working directory, and nothing uncommitted.

Which version of git are you using? There were many bugs fixed around
this area of merge around the v1.7.7 timeframe.

-Peff

Re: Bug! Git merge also fails with a wrong error message

[Yves Goergen]

On 13.01.2012 19:54 CE(S)T, Jeff King wrote:
> Whether you realize it or not, git is using the index to store state.
> When you "git add", "git rm", or "git mv", it is updating the index.

I'm using TortoiseGit most of the time and that doesn't expose the
concept of an "index". I edit files as usual, then select "commit" and
get the commit dialogue. In there I enter the commit message and select
all files to commit. I can add new files right there. There is no
two-step procedure.

> I notice that in your first mail, you mentioned a problem with
> "checkout", and in the second one, a problem with "merge". Do you still
> have the repo around with the "checkout" problem? If so, is the file
> also in your "git ls-files" output in that repo?

Yes, I have made a backup of the repo right after the initial problem
arose. And the git ls-files output is the same regarding that file.

> Which version of git are you using? There were many bugs fixed around
> this area of merge around the v1.7.7 timeframe.

msysGit 1.7.8 on Windows XP SP3. It's a "preview" but since Git is so
old now and there's been nothing but "previews", I consider msysGit's
meaning of the word "preview" as "stable".

-- 
Yves Goergen "LonelyPixel" <nospam.list@unclassified.de>
Visit my web laboratory at http://beta.unclassified.de

Re: Bug! Git merge also fails with a wrong error message

[Carlos Martín Nieto]

[-- Attachment #1: Type: text/plain, Size: 2790 bytes --]

On Fri, Jan 13, 2012 at 05:37:38PM +0000, Yves Goergen wrote:
> I have updates to this issue.

You still haven't told us what version of (msys)git you're using nor
have you provided a transcript of your session or found a minimal
reproducible example.

Gmane is a mailing list viewer and there /only/ is the real maling
list. The e-mail you provided for yourself looks bogus, but if it
isn't, you'll notice we communicate via e-mail.

> 
> After asking several people who didn't believe me,
> after all I could pass all checks to ensure that
> the file in question really is tracked, despite the error
> message telling it is not. (The file has a history, it is
> part of the branch,
> git status behaves as expected when I rename it, and so on.)
> 
> I had found a workaround hack to access my
> data again: I have cloned the repo
> into another directory, then switched to
> the branch in there (it actually
> worked) and used BeyondCompare to manually(!)
> switch my original repo and
> working directory by copying some (not all) files
> in .git and all differences in
> the working directory.
> 
> That worked fine at first, I could commit to that branch.
> 
> Today I wanted to merge that branch into master again.
> Switching to master was
> fine, but merging from the form-refactoring branch
> now fails for the very same
> "reason":
> 
> -----
> git.exe merge    --no-commit form-refactoring
> 
> error: The following untracked working tree files
> would be overwritten by merge:
> Form1.Designer.cs
> Please move or remove them before you can merge.
> Aborting
> -----
> 
> Again, that file is NOT untracked. Git just fails
> processing its own data. I
> cannot move that file because it is part of the
> other branch and must be merged now.
> 
> Am I now supposed to checkout both branches and
> do the merge somehow on my own?
> 
> Maybe it's not a good idea to use branching and
> then rename, create and delete
> files on that branch, as switching and merging
> fail completely afterwards. And
> in the end, maybe Git isn't all that good and
> some of the alternatives with real
> file tracking should be preferred.
> 
> I, for one, have lost a great amount of trust
> in Git in the last two days.
> 
> (Sorry for the formatting mess, but the stupid Gmane
> post editor forced me to do that or it wouldn't
> accept my message... Don't you have a real mailing
> list, if there's no web forum??)
> 
> --
> 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
> 

-- 
Carlos Martín Nieto | http://cmartin.tk

"¿Cómo voy a decir bobadas si soy mudo?" -- CACHAI

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: Bug! Git merge also fails with a wrong error message

[Yves Goergen]

On 13.01.2012 18:56 CE(S)T, Carlos Martín Nieto wrote:
> You still haven't told us what version of (msys)git you're using nor
> have you provided a transcript of your session or found a minimal
> reproducible example.

In case one of my other mails didn't arrive, the Git version is 1.7.8.

There is no session transcript because I use TortoiseGit and I'm not
going to add a screencast here.

> Gmane is a mailing list viewer and there /only/ is the real maling
> list. The e-mail you provided for yourself looks bogus, but if it
> isn't, you'll notice we communicate via e-mail.

Well, I am very confused. Starting from git-scm.com, the only support
site is a mailing list, and the hyperlink on that word sends me to Gmane
which says I am in a newsgroup called "gmane.comp.version-control.git".
Since I don't have access to the news system, I need to use the Gmane
website. I don't know exactly what it is. I know mailing lists, but that
doesn't look like one at all. There's not even a subscription page or
address. For users of the modern web who are not familiar with 70s nntp
technology and cannot use a mailing list by merely knowing its address,
this is very support-unfriendly. I almost would have considered that the
official Git website doesn't want to offer any support at all. In that
case I would likely have searched for an alternative and switched right
away. Assuming I could have extracted the remainders of my source code
from the broken Git repository.

So am I now subscribed to that "git@vger.kernel.org" mailing list and do
my posts show up there? I have no idea what's going on, neither in my
repository, nor in this mailing list. Confusing and intransparent.

-- 
Yves Goergen "LonelyPixel" <nospam.list@unclassified.de>
Visit my web laboratory at http://beta.unclassified.de

Re: Bug! Git merge also fails with a wrong error message

[Jakub Narebski]

Yves Goergen <nospam.list@unclassified.de> writes:
> On 13.01.2012 18:56 CE(S)T, Carlos Martín Nieto wrote:
 
> > Gmane is a mailing list viewer and there /only/ is the real maling
> > list. The e-mail you provided for yourself looks bogus, but if it
> > isn't, you'll notice we communicate via e-mail.
> 
> Well, I am very confused. Starting from git-scm.com, the only support
> site is a mailing list, and the hyperlink on that word sends me to Gmane
> which says I am in a newsgroup called "gmane.comp.version-control.git".

Note however that the _text_ of the hyperlink is

  git@vger.kernel.org mailing list

> Since I don't have access to the news system, I need to use the Gmane
> website. I don't know exactly what it is.

GMane is an e-mail to news gateway, and a mailing list archive. It
exposes mailing list as a newsgroup, so it can be read and written to
via newsreader (via Usenet).

Perhaps better solution would be to use mailto:git@vger.kernel.org
link, and add a sentence about archives / alternative interfaces.

>                                  I know mailing lists, but that
> doesn't look like one at all. There's not even a subscription page or
> address. 

git@vger.kernel.org is a public non-subscribe mailing list; you don't
need to subscribe to post requests there.  Note that it is a custom on
this mailing list to always include all participants in given
(sub)thread directly in Cc, so you should get responses to your emails
even if you are not subscribed.

[...]
> So am I now subscribed to that "git@vger.kernel.org" mailing list and do
> my posts show up there? I have no idea what's going on, neither in my
> repository, nor in this mailing list. Confusing and non-transparent.

If you send email to git@vger.kernel.org, it would also appear on
GMane.

-- 
Jakub Narebski

Re: Bug! Git merge also fails with a wrong error message

[Yves Goergen]

On 13.01.2012 20:34 CE(S)T, Jakub Narebski wrote:
>> Since I don't have access to the news system, I need to use the Gmane
>> website. I don't know exactly what it is.
> 
> GMane is an e-mail to news gateway, and a mailing list archive. It
> exposes mailing list as a newsgroup, so it can be read and written to
> via newsreader (via Usenet).

I have Thunderbird, but I have no usenet server to entry in a usenet
account, so as I said, I don't have access to that part of the internet.
I had at university, but that's some time ago now.

> git@vger.kernel.org is a public non-subscribe mailing list; you don't
> need to subscribe to post requests there.  Note that it is a custom on
> this mailing list to always include all participants in given
> (sub)thread directly in Cc, so you should get responses to your emails
> even if you are not subscribed.

Good to know NOW. It really should have informed me in the first place
on that website. It's a vital information without which you likely won't
get anywhere (as I).

-- 
Yves Goergen "LonelyPixel" <nospam.list@unclassified.de>
Visit my web laboratory at http://beta.unclassified.de

Re: Bug! Git merge also fails with a wrong error message

[Jakub Narebski]

On Sun, 15 Jan 2012, Yves Goergen wrote:
> On 13.01.2012 20:34 CE(S)T, Jakub Narebski wrote:

> > > Since I don't have access to the news system, I need to use the Gmane
> > > website. I don't know exactly what it is.
> > 
> > GMane is an e-mail to news gateway, and a mailing list archive. It
> > exposes mailing list as a newsgroup, so it can be read and written to
> > via newsreader (via Usenet).
> 
> I have Thunderbird, but I have no usenet server to entry in a usenet
> account, so as I said, I don't have access to that part of the internet.
> I had at university, but that's some time ago now.

GMane serves as a Usenet server; that is how it works as mail to news
gateway.  The server name is news.gmane.org... or you can try using the
following URL

  nntp://news.gmane.org/gmane.comp.version-control.git
 
> > git@vger.kernel.org is a public non-subscribe mailing list; you don't
> > need to subscribe to post requests there.  Note that it is a custom on
> > this mailing list to always include all participants in given
> > (sub)thread directly in Cc, so you should get responses to your emails
> > even if you are not subscribed.
> 
> Good to know NOW. It really should have informed me in the first place
> on that website. It's a vital information without which you likely won't
> get anywhere (as I).

You can get this information on GitCommunity page on Git Wiki.  For the
time being (while Git Wiki is served as set of static pages of exported
contents because of lack of hardware) you can find it here:

  https://git.wiki.kernel.org/articles/g/i/t/GitCommunity_c4e3.html

-- 
Jakub Narebski
Poland