5

I got a Git repository that I accidentally pushed a file 4 commits ago that is located in (path relative to the repository root folder): /Core/C:/testoutput/agwqe1s.xml

I did this on my Linux machine, so the actual file was created without any problem. The thing is when I go back to my Windows machine, I can't switch to the branch that has this file because the Windows just refuses to create such a folder. Ok, no problem, I deleted the file on my Linux end and commit it, but even tough it's not working. Git still tries to create this illegal file on my Windows machine, and I don't know what to do.

I know that I could remake the repo from scratch, but then I'd lost my whole commit log history, and I wanted to avoid that. What are my options over here?

Adam Dymitruk
  • 124,556
  • 26
  • 146
  • 141
SHiRKiT
  • 1,024
  • 3
  • 11
  • 30
  • Not familiar with git, but thought you must delete `C:` folder and all its children (folder & files). But you wrote, that "deleted the file". – Maximus Nov 01 '12 at 18:29
  • I deleted the file and the folder. Git doesn't store empty folders. – SHiRKiT Nov 01 '12 at 18:46

1 Answers1

6

you don't need to checkout that branch to update it. From a branch that works do this:

git fetch
git push . origin/problembranch:problembranch
git checkout problembranch

the trick is to push to the same repository. That's what the . is for.

Adam Dymitruk
  • 124,556
  • 26
  • 146
  • 141
  • The branch is updated, the problem is that when I try to checkout to the branch, what happens is: Invalid argument `/Core/C:/` because that's an illegal filename. – SHiRKiT Nov 01 '12 at 19:04
  • 1
    update the branch in Linux. Push it up. Fetch it on windows while on a different branch. Only checkout the branch after doing the push command I posted. – Adam Dymitruk Nov 01 '12 at 19:10
  • Didn't work. I did this `git filter-branch --index-filter 'git rm --cached --ignore-unmatch FILENAME' \ --prune-empty --tag-name-filter cat -- --all` got this solution from http://stackoverflow.com/questions/2254601/bad-commit-to-git Thank you for your time @AdamDymitruk – SHiRKiT Nov 01 '12 at 19:14
  • which part didn't work. If you fetched successfully, the push would update the branch without it having to be checked out. Now that the branch points to a commit with a tree that doesn't have an invalid path, checking it out should work. The problem with what you have done here is that others may be caught off guard with changed SHA1s. My solution keeps them the same. All you do is add one commit to repair the damage. With yours, you can seriously harm a parent repo if this is a submodule. I'm adding this for completeness if others are considering the same thing with this problem. – Adam Dymitruk Nov 01 '12 at 19:17
  • 1
    I did it wrong, you're right, it worked. And the solution I posted can seriously harm the repo if done wrong. – SHiRKiT Nov 01 '12 at 19:45