I've got a branch that renames many files, and I'm trying to rebase it onto master where the original files have been modified (preferably without this devolving into a manual conflict-resolution nightmare).
Situation
I've been porting a JavaScript project to TypeScript, in my local
typescriptbranch. All of the.jsfiles have now become.tsfiles, and some of the syntax has been upgraded.Meanwhile, changes to the original
.jsfiles have happened on themasterbranch.I want to rebase my
typescriptbranch ontomaster-- but the changes are not merging correctly, as the file renames hadn't been detected -- so we're getting conflicts where changes are made to.jsfiles which git thinks had been deleted (however they have actually been renamed to the.tsfile).
What I think I know
Git graph:
o-[typescript] .js files become .ts
|
| o-[master] changes to the .js files
| |
| o
|/
o-[root] common ancestor
So, while standing in the root branch:
I can run this command to view all of the renames:
git diff --name-status --find-renames=10% typescriptI understand that the git merge command has the same sort of
--find-renamesfunctionality, though I'm having difficulty getting that to work.- Update:
git merge -X find-renames=10% mybranchappears to be the expected syntax.
- Update:
I understand the git rebase might support
find-renamesfunctionality, though I'm still not clear about how that might be used.
Solution ideas?
(Nope) Perhaps from
root, I could merge intypescriptwhile detecting the renames (like this:git merge -X find-renames=10% typescript). Then, root will be just liketypescript, except with renames (rather than mass deletions/additions).- From there, I'm hoping I could just
git rebase master, and with the renames having been in place, the operation will go smoothly and place the edits into the correct files.- Update: I tried this, but my subsequent rebase didn't go over any better than before.
- From there, I'm hoping I could just
(Yep) I think perhaps the rebase itself needs to be performed with the
find-renamesoption.. I'm investigating this...git rebase -X find-renames=10% master-- nopegit rebase -X --find-renames=10% master-- nopegit rebase --find-renames=10% master-- nopegit rebase -X recursive --find-renames=10% master-- nopegit rebase --merge -X find-renames=10% master-- nopegit rebase --strategy-option="rename-threshold=10" master-- that's the ticket! it works!
(Nope) Perhaps I need to look at the problem differently? Maybe I should start from
master, and then do some kind of squash merge oftypescriptwith the rename detection (rather than any kind of rebase?)- I don't need the
typescriptbranch history, it will be squashed down to one fat commit for review anyways.. - Update: It looks like Git stops working when I attempt this strategy.. When I'm standing in the
rootbranch, I can rungit merge -X find-renames=10 typescript-- and it fast-forwards totypescript.. (not quite what I was hoping for, I was hoping for a new commit that had renames rather than additions/deletions..)- When I'm standing in the
masterbranch, and I run the exact same command, git tells me this:fatal: Unknown option for merge-recursive: -Xfind-renames=10... - Now, this bothers me, because I actually did not enter what it quoted (I did include the space), and the only thing that seems different to me, is which branch I'm currently standing in -- if the option is "Unknown", then why does it work when in a different branch?
- Anyways, so that's creepy, and seems to make this approach a dead-end.
- When I'm standing in the
- I don't need the