Reputation: 139
it seems like a similar question with Untrack files from git temporarily but I can't find a good-working answer for me.
I'm running a python-django server and have trouble on git merge
.
At the beginning of the project, a developer had committed all the *.pyc files on git, and these commits are used on the server as production code.
Now I have removed all the *.pyc files from the repository and make the proper .gitignore file.
But the problem occurs here.
Everything goes well till commit, but if I tried to merge it with production code, it emits an error.
Your local changes to the following files would be overwritten by merge:
Of course, the troubled files are the *.pyc files.
I assume it's because the *.pyc files are already tracked in some commits, and when trying to merge, git judge that the local *.pyc files will be removed by the commits which have 'delete: *.pyc' internally.
Describe it as an example :
Let's say I'm on branch A and want to merge branch B to branch A.
The top commit of branch B has no *.pyc file. And the top commit of branch A has *pyc files on the working tree, but they're already removed from index(stage) by git rm --cached
.
When I try git merge B
on branch A the error Your local changes to the following files would be overwritten by merge:
occurs.
Is there any feature to resolve it in git?
P.S.: I'm new in StackOverflow and not fluent in English. If I made any mistake on this question or some phrases are hard to understand, please comment on me. Thank you.
Add git-status:
I can't upload the output with real file names, but it seems like below. Just the file names differ.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: files.pyc
Upvotes: 3
Views: 263
Reputation: 489888
You can resort to using filter-branch, as in Naeem Khoshnevis's answer. If you need to do a lot of work with the "bad" commits that contain the *.pyc
files, this might even be the way to go. The downside of doing this kind of work is that the product of filter-branch
is usually a new, incompatible repository, that requires everyone who has a clone of the original repository, to throw out their clones, and painstakingly copy any work they had done on the original clone, over to the new clone.1 It may be better just to work around the problem:
*.pyc
files are simply byte-compiled Python code, made from the "real" Python source.*.pyc
files in your current commit and current working tree. Then, do the merge. If that introduces some *.pyc
files, so be it: let that happen. Then re-remove the files and commit this as a "repair the merge" step.You're now done with the problematic merge. The fact that the merge commit itself has incorrect *.pyc
files in it is not really a problem except that the merge commit itself cannot be tested during bisection. If you don't like that—it can be a problem later, because there's no obvious marker for this—you can consider making an evil merge using git merge -n
(then removing the *.pyc
files before committing the merge), or using git commit --amend
after the merge to replace the normal merge with the evil merge.
Note that no matter which of these various approaches you take, there is some pain. That's unavoidable: someone made a mistake earlier, and everyone is now paying for it. What you get to choose now is which painful process to go with, based on how painful you believe it will be.
1There are some ways to automate some of this, especially in modern Git and/or using the new filter-repo system, but it's painful no matter what.
Upvotes: 2
Reputation: 2472
It seems you need to remove that file from your entire git history. In Pro Git, you can read the "Removing a File from Every Commit" section. You need to use git filter-branch
command.
Example from the book for removing password.txt from all commits.
git filter-branch --tree-filter 'rm -f passwords.txt' HEAD
Upvotes: 0