2

I'm trying to pull a commit made on a Linux machine into a Windows machine. I'm getting this error message: 

error: git checkout-index: unable to create file my/folder/name/: (Invalid argument)

On the Linux machine there appeared to be 2 such 'name' folders called: 'name' and 'Name'. Even after uniting them under 'name' and re-committing, I still get the same error message.

On Windows I have git version 1.7.3.1.msysgit.0 and on Linux I have git version 1.7.5.4.

I did find a bunch of seemingly related SO questions of this nature, but none had a clear or relevant solution.

UPDATE: The files are hosted on a remote hosting service so that both Windows and Linux machines pull from the remote repo.

Community
  • 1
  • 1
Adi Shavit
  • 16,743
  • 5
  • 67
  • 137
  • And this could not be related to http://stackoverflow.com/questions/1209902/git-checkout-and-reset-on-windows-occasionally-shows-random-files-have-changed ? Is there any special character in the path or filename? (as illustrated in https://github.com/thoughtbot/paperclip/pull/621 or http://code.google.com/p/msysgit/issues/detail?id=80) – VonC Oct 25 '12 at 12:01
  • Not that I can see. The offending name is just 'tests'. – Adi Shavit Oct 25 '12 at 12:36
  • When you say "*uniting them under `name`*", did you add a new commit that fixes the issue, or did you rewrite history so that the two separate versions of `name` never existed? – nickgrim Oct 25 '12 at 12:52
  • I moved all the files in `Name` into `name`, deleted `Name` and committed. I didn't rewrite the history (not even sure how to do this). The strange thing is that the Linux clone never created these folders - they were like that in the repo. – Adi Shavit Oct 25 '12 at 12:54
  • Has this repo ever been cloned on a Windows machine before? – nickgrim Oct 25 '12 at 13:02
  • It's been clone many times but mostly to-from Windows machines, though there *have* been some commits from MacOS (though not to the offending path). – Adi Shavit Oct 25 '12 at 13:03
  • 1
    Did you clean your windows repo first, before pulling again? Would a fresh clone from the Linux repo on a new Windows - empty - directory work? – VonC Oct 25 '12 at 13:09
  • I did `git reset --hard`. Didn't help. I'll do a test for a clean clone. – Adi Shavit Oct 25 '12 at 13:14
  • @Vonc: a clean clone give the same error. – Adi Shavit Oct 25 '12 at 13:34

3 Answers3

2

Answering my own question due to the weirdness of the solution.

The first step is as @Don Branson, @VonC and @robinst suggested. I did a clean clone into a new folder on my Windows machine.
This did not seem to work, and git returned the exact same error.

However git status showed the offending folder as "deleted", even though a folder with the same name did exist and contained the proper files.
I then staged and committed the "deleted" folder, pushed to the remote repo. and pulled the commit from my original repo. Lo-and-behold the branch was updated properly.

Adi Shavit
  • 16,743
  • 5
  • 67
  • 137
  • 1
    Excellent. I just tried replicating this locally, and could not repeat the results. With git 1.7.1 on the Linux master and git 1.7.5.1 on the Windows target, ``git clone`` just put everything from my directory ``m`` and ``M`` into one directory named ``M``. Interesting. – Don Branson Oct 25 '12 at 13:51
  • @Don Branson, cudos for experimenting. Try committing both `m` and `M` before unifying them and then doing a new commit of the unified and deleted folders. – Adi Shavit Oct 25 '12 at 14:09
  • Thanks, Adi. I did try it that way, so it surprised me that I didn't hit the same issue. Perhaps it has to do with the versions of git in question. – Don Branson Oct 25 '12 at 14:20
1

When you git pull git will apply the commits in order. So, even though the directories are consolidated by the final commit, they won't be in the commits it's applying to reach the HEAD. I'd try a new git clone on the Windows machine.

Don Branson
  • 13,631
  • 10
  • 59
  • 101
  • Git does not check out each individual commit (one after another), it checks out the final state directly. – robinst Oct 25 '12 at 13:19
  • @robinst *apply* != *check out* – nickgrim Oct 25 '12 at 13:28
  • @robinst For a fast-forward, you're correct. But I don't think that's the case for non fast-forward. – Don Branson Oct 25 '12 at 13:32
  • The problem was that we both assumed that the tree in the newest commit in OP's repository did not have a `name` and a `Name` directory anymore. But apparently it did, that's why even a fresh clone did not fix the problem. – robinst Oct 26 '12 at 11:23
  • @nickgrim Yes, that's right. But the only thing that touches the working directory when doing `git pull` is the checkout at the end. – robinst Oct 26 '12 at 11:40
1

The problem could be that Git first tries to create the new files (under the new name name) before the old directory Name has been deleted. So when it tries to create the new directory name it doesn't notice that Name already exists, because it compares them case-sensitive.

You could try the following (with a clean working directory of course):

  1. Recursively delete my/folder/Name (the old location).
  2. Do git reset --hard origin/branchname (the branch you are pulling).

Alternatively, just do a fresh clone.

robinst
  • 30,027
  • 10
  • 102
  • 108
  • Nope. Deleted the offending dir, and did the reset. Still the same error message. – Adi Shavit Oct 25 '12 at 13:28
  • @robinst You're saying the same thing here - that there's a name collision along the way, and that a fresh clone might fix the problem. – Don Branson Oct 25 '12 at 13:34
  • Then you probably didn't really "unite" them under the same directory in the repository as you wrote in your question. If the files are all under the same directory (with the same case) in the newest commit, a fresh clone would not have caused the problem. – robinst Oct 26 '12 at 11:19