Home/ Questions/Q 6556157
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-25T12:54:31+00:00

I have forked rails git://github.com/rails/rails.git at github. My forked repository is at git://github.com/waseem/rails.git .

  • 0

I have forked rails git://github.com/rails/rails.git at github. My forked repository is at git://github.com/waseem/rails.git. I want to test out some patches submitted by other users to rails mainline. Lets say I want to test out code in migration_status branch at git://github.com/joelmoss/rails.git.

Lets say I

master $ git remote add joelmoss git://github.com/joelmoss/rails.git. and

master $ git remote add mainline git://github.com/rails/rails.git.

I have been pulling from rails mainline into my master.

master $ git pull mainline master

According to http://guides.rubyonrails.org/contributing_to_ruby_on_rails.html#testing-patches I should create a local topic branch and pull in changes from joelmoss/migration_status. So I,

master $ git checkout -b migration_status Create a local topic branch.

And when I do:

migration_status $ git pull joelmoss migration_status

I get a large number of conflicts. I also tried migration_status $ git pull --rebase joelmoss migration_status but I still get conflicts.

In the case of pull --rebase, I think (correct if wrong), git is trying to apply my local changes on top of changes fetched from joelmoss/migration_status. Ideally it should do the opposite. To consider this option, I did following.

master $ git fetch joelmoss

master $ git checkout -b joel_migration_status joelmoss/migration_status and

joel_migration_status $ git rebase master it still gave me lots of conflicts.

How do I pull in patches submitted to one of my local topic branches w/o getting conflicts? I can not resolve those conflicts as I do not know much about what code to keep what not to.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    In this case, it looks like joelmoss/migration_status is based off of 3.1.0, which split from mainline/master back in May. So if you merge you’re trying to reconcile 4 months worth of development by everyone, in branches that appear to never have been intended to merge.

    What you want to do is base your local changes on 3.1 as well. That doesn’t guarantee to remove all conflicts, but at least it should be ones you are aware of because it’s code you changed directly.

    git checkout -b master-3-1 master
git rebase --onto joelmoss/migration_status mainline/master master-3-1
    • 0