Can't fast-forward forked branch (without changes) anymore

Ok, this is probably a very easy question for you, but here it comes:

I’ve forked the Marlin repository to manage configurations for my different 3D printers. To do this, after the fork, I created new branches for each printer/configuration. To access the upstream repo, I added one additional remote (once):

$ git remote add upstream
$ git remote -v
origin (fetch)
origin (push)
upstream (fetch)
upstream (push)

then (after a new release on the 2.0.x stable branch on upstream)

$ git checkout 2.0.x
$ git fetch upstream
$ git merge upstream/2.0.x

Since I left the 2.0.x branch as it was/is, this was simply a fast-forward. For my other custom branches, I only had to merge a few (configuration) files and was done.
Unfortunately, this worked only twice. Now, I get a lot of conflicts and changes although the branch should be “clean” on the 2.0.x branch.

I assume this has something to do with the whole “merge vs. rebase” topic, but I don’t understand why it worked before and not anymore… To be honest, I read quite a bit about that, but still wasn’t sure which approach would be better suited for this scenario. Merging seemed to do what I wanted…

$ git --version
git version 2.28.0

Ok, maybe I need to rephrase this a little:

What I basically want, is to take the current 2.0.x branch – as it is – from upstream and then reapply my changes. I don’t care about commit messages or “when I changed what”, I just want to merge the latest state of my branch with the upstream branch.

I though about saving the 4 files I changed, reset it to upstream/2.0.x and then copy the files back in. But then I would overwrite the few changes made in the files since I last merged the upstream branch.

There must be an easier way to do this!?

That is a very different thing from fast-forwarding. It sounds like rebasing might be what you want. In short, git rebase reapplies your commits on top of a changed base. If you’re not familiar with rebasing I highly recommend you read the Rebasing chapter of the Git Book, and in particularly the cautions there.

The commands for a rebase commands would probably look similar to this:

git checkout your-branch
git rebase upstream/2.0.x

Note that this will lead to chaos if some of the commits from the upstream branch that you already have were rebased since. Seems unlikely in a well-structured project, but still worth checking.

Thank you for your reply!

I think I found a solution, at least for now.
What I did is merging into the “clean” local 2.0.x branch first, by simply always choosing the incoming changes using the mergetool (Kdiff3 in my case). I’m sure there is a command for that, but I did it manually for now.

After that, I merged the local 2.0.x branch into my custom branches, which – after doing the step above – only needed merging of the actually changed files.

I’m not sure if this will work in the future too, but I guess I will find out soon enough.

1 Like

-X theirs should do the trick

1 Like

Thanks! I was already slightly suspecting this option to be the one doing that. :grinning:
I will try that next time.