2

I've accidentally committed some files that shouldn't be tracked and should be generated for each developer on their own. I've added a pattern to .gitignore for them, but that's too late of course because the files are already in the repo. I've checked the answers to these questions, but they all say the same thing:

The command:

git rm --cached <file>

doesn't work because if I commit that, then the other developers will have their versions of the file deleted once they pull.

git update-index --assume-unchanged <file>

..doesn't work either because the files are still being tracked, so if anyone makes changes, they will be committed unless each developer runs the command. Either way, it keeps the files in the repository, which we don't want.

Is there a way to make it as if the files were never in the repository in the first place? I want the same behavior as git rm --cached <file> without the caveat of it causing the files to be deleted on a pull..

Community
  • 1
  • 1
mowwwalker
  • 16,634
  • 25
  • 104
  • 157
  • 1
    May I ask are you open to doing a `git rebase` on this branch? – Tim Biegeleisen Jan 29 '16 at 06:24
  • @TimBiegeleisen, I don't know what that does – mowwwalker Jan 29 '16 at 06:29
  • The only way out for this, other than everyone using `git update-index` is to rewrite the history of the branch. Think of Back-to-the-Future except doing it to Git branches instead. You can rewrite the commit where you added those files such that the files do not get added. – Tim Biegeleisen Jan 29 '16 at 06:30
  • @TimBiegeleisen, That sounds like it could work. How would I do something like that? – mowwwalker Jan 29 '16 at 06:45
  • Warning: If you go down this path, then _everyone_ will have to delete their local version of the branch and pull again. Given that caveat, if you want a solution I can post it. – Tim Biegeleisen Jan 29 '16 at 06:46
  • "if I commit that, then the other developers will have their versions of the file deleted once they pull" -- Only if they have no local changes. But it sounds as if they necessarily will have local changes. Is that right? –  Jan 29 '16 at 06:47
  • @TimBiegeleisen I wouldn't personally use that solution since it's the same problem of requiring all the other developers to take some action, but this is a pretty common scenario and the answer might be helpful to others – mowwwalker Jan 29 '16 at 06:47
  • 1
    Possible duplicate of [Completely remove file from all Git repository commit history](http://stackoverflow.com/questions/307828/completely-remove-file-from-all-git-repository-commit-history) – Andrew C Jan 29 '16 at 16:26

1 Answers1

0

"Is there a way to make it as if the files were never in the repository in the first place?" "I wouldn't personally use [a rebase] since it's the same problem of requiring all the other developers to take some action"

Then there is no solution. That's the nature of git, committed and pushed mistakes are forever. This is a feature, not a bug.

This is a pretty common scenario and the answer might be helpful to others

Reading the documentation would be better.

msw
  • 42,753
  • 9
  • 87
  • 112