3

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
dobyek
  • 109
  • 1
  • 8
  • 1
    https://stackoverflow.com/a/6964322/9523118 Check this link it might help – Krishna Sony Apr 30 '21 at 14:11
  • I've already viewed it. git update-index and git add -u both don't work in my case. Thanks for your comment. – dobyek Apr 30 '21 at 14:19
  • You need to commit the deletions made by `git rm --cached` before merging the other branch. From your question it seems that you missed this step. – Ron Inbar Apr 30 '21 at 14:23
  • Sorry I just didn't write that on question. I did commit and done succesfully. But when merge, it occurs error. It seems to be caused by the tracking history of *.pyc files. – dobyek Apr 30 '21 at 14:42
  • Can you please edit your question and add the output of `git status` just before you issue the command that results in the error? – Ron Inbar Apr 30 '21 at 18:42
  • According to the output of `git status`, all you needed to do was `git add *.pyc` or `git restore *.pyc`, then `git commit`, and only then `git merge`. – Ron Inbar May 02 '21 at 16:38

2 Answers2

2

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.
  • They can therefore be removed before and/or after merging.
  • So all you have to do is get ready for the merge step, then make sure there are no *.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.

torek
  • 448,244
  • 59
  • 642
  • 775
  • You don't need to painstakingly copy the work you've done in the old repo; fit allows you to cherry pick commits across unrelated histories, as long as the diffs "fit". – rubenvb Apr 30 '21 at 21:51
0

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
Naeem Khoshnevis
  • 2,001
  • 4
  • 18
  • 30
  • For whom this answer will help. Detailed link : https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History#_removing_file_every_commit – dobyek Apr 30 '21 at 15:23