Question

I currently have a git repository at github that stores the packaging files for a bunch of packages with a directory structure like this:

package-a
  `- PKGBUILD
package-b
  `- PKGBUILD
package-c
  `- PKGBUILD
xorg
  `- PKGBUILD
libx11
  `- PKGBUILD

I created an experimental branch, newxorg, that contains packaging files for a new version of xorg and libx11 and also updated package-a and package-b on master. My history is something like this:

M1 -- M2 -- M3 -- M4
       \
        B1 -- B2

where:
B1 = "Update xorg"
B2 = "Update libx11"
M3 = "Update package-a"
M4 = "Update package-b"

Ideally, I’d like my new branch to contain the M3 and M4 commits from master, like this:

M1 -- M2 -- M3 -- M4
                   \
                    B1 -- B2

But the problem is that I’ve already pushed both master and the newxorg branch to the remote github server. Since people have already cloned the new branch, I’m guessing a rebase would really screw things up for them. What would be the best way to merge the new commits from master?

Answer 1

If there aren’t too many new commits on master I would cherry-pick them on newxorg.

Following your example, cherry picking M3 and M4 from master on newxorg would get you from:

M1 -- M2 -- M3 -- M4
   \
    B1 -- B2

to:

M1 -- M2 -- M3 -- M4
   \
    B1 -- B2 -- M3 -- M4

You will have M3 and M4 separately on newxorg.

With cherry-pick you would have a “small” problem if you decide to merge newxorg into master (at a later stage) since cherry-pick would create other commits identical in every point to the original M3 and M4 commits, BUT with a different sha1 hash. You (and others) will see this in the history as duplicate commits…

There is also the option of merging master into newxorg (but that would create another merge commit so it isn’t exactly what you asked for).

In your case I would prefer to use the merging method to avoid later problems.

Choose whatever method you see fit.

---

LE. Merging details

As you requested, here are a bit more details about the merging method:

1. checkout the newxorg branch (git checkout newxorg)
2. merge master into newxorg (git merge master)

If you have problems checking out the newxorg branch you might need to stash the changes you have in your working copy: git stash and when you need those changes back you can do a git stash pop (pop applies the changes and then discards the stash) or a git stash apply (apply applies the changes and keeps the stash).

Here is the initial setup:

and the final setup:

At a later stage, when you want to merge back newxorg into master use these commands:

git checkout master
git merge newxorg

If you will have conflicts when merging you can use the git mergetool to resolve the conflicts. You might need to configure a visual merge tool such as p4merge (which is cross-platform).

PS. in case you’re wondering where did I get those screenshots from: they are from your repository on github.