www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: Current use of GitHub
Date Mon, 04 Apr 2011 21:17:14 GMT
> //do some work locally, committing to local git.
> git svn rebase // pull in other changes from apache
> git push -u github //I don't remember the exact command I used, but it did get my local
changes to a github branch named feature1
> //do some more work locally, committing to local git.
> //no one else changed the github branch AFAICT
> git svn rebase // pull in more apache changes, resolving merge conflicts
> I now can't push my local changes to the same feature1 github branch.  My theory about
why is that I've reordered history on my local git compared to the existing github branch.
 I have no way to verify this :-).  I guess I could create a new github branch every time
I push???


Bottom line is that this is because when you rebase, you've changed
the history of your branch. Since you did the first rebase before you
pushed, this is fine, when you do the second rebase, it changes the
commits you did locally before, which causes your local branch history
to diverge from the branch at your GitHub remote.

Think of the commit pattern like such:

SN commit N from svn
LNM local commit N, version M

// do some work locally

S0 -> L10 -> L20

git svn rebase

S0 -> S1 -> S2 -> L11 -> L21

git push github feature_name

# GitHub now has L31 as the head for branch feature_name

// more local work

S0 -> S1 -> S2 -> L11 -> L21 -> L30

git svn rebase

S0 -> S1 -> S2 -> S3 -> L12 -> L22 -> L31

// Now you can't push

this is because your local branch has L31 as the head, and the GitHub
branch is still L30. This is what's referred to a non fast forward
push. You'll notice that both branches have commit S2 as the most
recent commit in common.

Now is the part where I write something that gets me branded as a heretic.

To fix this, just do:

$ git push -f github feature_name

This will forcefully overwrite your remote branch so that it points at L31.

Most people will tell you to never rebase something that has been
pushed publicly. Generally that's true. For instance, you should never
ever rebase your stable branches (master, version branches etc) that
people might be using to develop against. On the other hand, if I have
a public tracking branch of some wip, I'll rebase at will, treating it
solely as a way for people to keep an eye on what I'm hacking on.

I'll note that the alternative to this work flow is to svn rebase a
local checkout of trunk, and then merge that into your feature branch.
This will ensure that you'll always have fast forward updates when you
push to GitHub. On the other hand, when you go to extract the work
from your feature branch it can become much more difficult if you want
to do anything more complicated than a single patch.

View raw message