1

My git repo has 2 branches: 'develop' and 'feature'.

When I run git rebase develop, I see:

First, rewinding head to replay your work on top of it...
Applying: inital commit
Using index info to reconstruct a base tree...
A       datastore/static/js/app/main.js
Falling back to patching base and 3-way merge...
CONFLICT (modify/delete): datastore/static/js/app/main.js deleted in HEAD and modified in inital commit. Version inital commit of datastore/static/js/app/main.js left in tree.
error: Failed to merge in the changes.
Patch failed at 0001 inital commit
hint: Use 'git am --show-current-patch' to see the failed patch
Resolve all conflicts manually, mark them as resolved with
"git add/rm <conflicted_files>", then run "git rebase --continue".
You can instead skip this commit: run "git rebase --skip".
To abort and get back to the state before "git rebase", run "git rebase --abort".

I think this relates to the fact that an earlier commit on 'develop' moved datastore/static/js/app/main.js to assets/js/app/main.js, but because there were also changes within the file, git did not treat it as a "rename" but instead as a deletion of datastore/static/js/app/main.js and creation of new file assets/js/app/main.js.

What commands can I run to fix my situation?

I'm aware that git diff --base can show me some information that would help me manually fix my problem, but my intuition says that there is a cleaner, more automatic way (which is desirable since I will be dealing with many more than just 1 file conflict).

P.S. I also studied answers to these questions but still haven't figured out how to proceed:

Ryan
  • 22,332
  • 31
  • 176
  • 357
  • I think your Git version predates the latest update to rebase to default to using `git rebase -m`. If so, you may find that running `git rebase -m develop` works better. – torek Jul 23 '20 at 00:05
  • @torek `git --version` = "git version 2.25.1" Is my git too old? I also just tried `git rebase -m develop` and don't notice a difference. Thanks. – Ryan Jul 23 '20 at 00:17
  • 1
    Hm, no, you should be OK by then - 2.21 is the one that has the rewrite of `git rebase --merge` (`-m` is short for `--merge`). Without the `--merge` option, rebase doesn't "see" file renames as renames. With it, you can still run afoul of renames that don't meet Git's rename test, though. – torek Jul 23 '20 at 00:41
  • 1
    (Version 2.26 makes `git rebase` do `git rebase -m` by *default*, but with the explicit flag, you should be fine.) – torek Jul 23 '20 at 00:45

0 Answers0