We use git to store our PC board designs. We are a small company and the only person doing commits & pushes is the board designer (me), so there’s no risk of overwriting someone else’s work by rewriting git history.
We recently had to change our OS from Linux (Ubuntu) to Windows. Several files in our repos violate Windows filename rules (e.g. contain a colon, path too long, etc.). I sometimes need to check out previous commits to see the design history, so ideally the entire history needs to contain valid Windows filenames, otherwise the checkout fails.
Doing an interactive git rebase seemed like it could solve the problem. Unfortunately git doesn’t handle things the way I was hoping.
For example, I have a file called file:1.txt that was renamed file:2.txt several commits later. Because this file wasn’t critical, I decided to delete it using a git interactive rebase. I deleted it it from the first commit where it appeared. I thought git would know that it had been deleted & update the subsequent commits accordingly. Unfortunately that’s not what happened. Rebase got to the subsequent commit where the file was renamed, and gave a conflict because it was trying to change the name of a file that no longer existed.
A few other similar issues popped up in my attempts with other files/paths, but the basic problem seemed to be that a git interactive rebase doesn’t always handle filename changes or file deletions well. It doesn’t seem to make all the necessary adjustments to the git history automatically.
Am I missing something here? Is there a better way to do this?
BTW, for context I would say that I’m an intermediate git user. I’ve used basic commands for awhile, but I’ve rarely used the advanced ones (e.g. rebasing), and I know nothing of the plumbing commands – nor do I write external scripts to accomplish git tasks.
Thanks!
2
Answers
Git does not record renames.
git mvis more or less a shortcut formvfollowed bygit rmandgit add. Git commands that detect a rename do so by heuristics, which can often fail (also, you don’t want it to guess wrong). Thus, as far as git history is concerned,1.txtstopped existing at some point, and2.txtwas newly created.git rebasewill perform rename heuristics, but maybe the files were too different. See the--find-renamesoption, but be aware of the possibility of false positives.So – if
git rebasedid detect a rename, removing1.txtshould also remove2.txt. If it did not, you will have to remove both files separately (or tweak the rename threshold, but I probably would not recommend it).As matt mentioned in a comment, usually the easiest way to change history across a repo is to use
git-filter-repo. In your case you can use the option--path-renameas described here.Since you’ll be working on Windows, you may find this answer useful for installing it.