www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Lyubimov <dlie...@gmail.com>
Subject Re: Current use of GitHub
Date Mon, 04 Apr 2011 21:28:17 GMT
> git push -f github feature_name

I believe that syntax of pull+history overwrite. with pull, you need to use

git push github +feature_name:feature_name

And yes, it will make you heretic :)

-d


On Mon, Apr 4, 2011 at 2:17 PM, Paul Davis <paul.joseph.davis@gmail.com> wrote:
>> //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???
>>
>
> David,
>
> 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.
>

Mime
View raw message