0

I'm trying to emulate in git what subversion users would think of as a vendor branch. In my case, I'm using a patched version of Drupal, which is available via git. So I'm thinking the right thing to do is a git repository with multiple remotes, as described in Merging two remote repositories in Git

I'd like to pull from drupal.org git repo a version of Drupal, and commit it to my own git repo where I will apply patches. So I clone my repo and add drupal.org as another remote, like so.

git clone myrepo:drupal/core
git remote add drupal.org http://git.drupal.org/project/drupal.git
git checkout -b custom-7.x drupal.org/7.x
git pull drupal.org 7.30

I believe my problem comes from that last line. It is pulling a tagged version of drupal 7.x which is not the same as the tip of the branch.

Next, I try to push drupal 7.30 into my repository, and here's where it fails.

git push -n origin
...
 ! [rejected]        custom-7.x -> custom-7.x (non-fast-forward)
error: failed to push some refs to 'git.electricgroups:drupal/core'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

It's ironic that git provides 4 lines of hint, yet I still don't have a clue.

Can git be used to manage my patched version of Drupal? Is there a better way to set it up? If not, how do I get past this error?

Community
  • 1
  • 1
Dave Cohen
  • 1,277
  • 2
  • 15
  • 21

1 Answers1

0

Git is trying to tell you that your remote custom-7.x branch can't be fast-forwarded to the state of you local custom-7.x branch. This is explained in detail in many other places (including the man page for git-push that last hint points you to, but it basically boils down to that your remote branch has one or more commits that your local branch doesn't have. In other words, the commits in the remote branch is not a subset of your local branch.

There are multiple possible causes of this, but with the information given it's impossible to tell which.

  • You have made commits on the origin/custom-7.x branch. I suppose local customizations of Drupal is the whole point of having that branch, so it's a pretty likely scenario. Instead of basing your local branch on drupal/7.x, base it origin/custom-7.x. Then, merge drupal/7.x into it. You may have to solve conflicts. Push to origin.
  • The upstream 7.x branch has been rewritten since you last pushed it to your remote's custom-7.x. Upstreams typically don't do this since it's disruptive to a lot of people's work, but it's possible. In this case you'll either have to rewrite your own branch (typically by rebasing your patches onto the remote branch and force-pushing them into your remote).
Magnus Bäck
  • 11,381
  • 3
  • 47
  • 59
  • I have not (yet) made commits to my custom-7.x branch, but I plan to. And yes, the upstream branch has changes, which I think is what upstream branches should do. However, I don't want every little upstream change in my custom version. I want to be able to control what gets in there by updating to an upstream tag. Sounds like git is not a tool capable of this. – Dave Cohen Aug 21 '14 at 16:51
  • Of course it is, but `git merge` is the wrong tool. Some googling indicates that they actually are rebasing their branches as part of their normal workflow. Unusual, but it explains what you're seeing. Going back to your problem, it rather sounds like you should be cherrypicking changes from the upstream branch. That'll allow you to choose exactly what you want to have. I wouldn't recommend going down that path, though. Unless the upstream has serious quality problems you'll risk creating a lot of extra work for yourself by not using the upstream as-is or with minimal patches. – Magnus Bäck Aug 22 '14 at 05:46