Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59069
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4F67AE0B.8090508@oracle.com>
References: <slrnjmeju4.mfm.dsp@experimentalworks.net>
	<CAKOpQSyLSXJU77T03ayj1zw7MeBhom_V58NO8PFu+R_KpH_GvQ@mail.gmail.com>
	<CAJWj5+EWWV6g3aFOVF+Or99yijJu5Uo-Bt2ObNZ7Fs6UWv3zLg@mail.gmail.com>
	<CAKOpQSy1eeWDgTCnD7bRvr_+icsj1ExEhuiHvogNsshaB6u3sg@mail.gmail.com>
	<CAJWj5+GqrCdW0tuVZsQ=GW2n+eV1Q69M_o8h3NOMahGhiwGHmw@mail.gmail.com>
	<CAKOpQSweGeOy8vaMaRGc75ia=uC6YRLcZ3YkxKMDL9ZXxubbug@mail.gmail.com>
	<4F67AE0B.8090508@oracle.com>
Date: Mon, 19 Mar 2012 15:26:19 -0700
Message-ID: <CAKOpQSw=2jrywUOY=zkrX0GuMN71zVfTNDROPR3225gbjLyU0A@mail.gmail.com>
To: Christopher Jones <christopher.jones@oracle.com>
Cc: PHP Developers Mailing List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d043892ab1dd92304bba00c01
Subject: Re: [PHP-DEV] php-src is now on git
From: kris.craig@gmail.com (Kris Craig)

--f46d043892ab1dd92304bba00c01
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Mar 19, 2012 at 3:07 PM, Christopher Jones <
christopher.jones@oracle.com> wrote:

>
>
> On 03/19/2012 01:31 PM, Kris Craig wrote:
>
>> Here's what I wound-up doing: The merge entries on the workflow page now
>> contain "--no-ff" and I added an entry to the FAQ about the merge.ff option
>> available in newer clients. This way we should be covered either way. =)
>> --Kris
>>
>
> Is this supported by the php-src repo?  This is what I get after using
> --no-ff:
>
> $ git push origin
> To https://git.php.net/**repository/php-src.git<https://git.php.net/repository/php-src.git>
>  ! [rejected]        PHP-5.3 -> PHP-5.3 (non-fast-forward)
>  ! [rejected]        PHP-5.4 -> PHP-5.4 (non-fast-forward)
>  ! [rejected]        master -> master (non-fast-forward)
> error: failed to push some refs to 'https://git.php.net/**
> repository/php-src.git <https://git.php.net/repository/php-src.git>'
> To prevent you from losing history, non-fast-forward updates were rejected
> Merge the remote changes (e.g. 'git pull') before pushing again.  See the
> 'Note about fast-forwards' section of 'git push --help' for details.
>
>
> --
> Email: christopher.jones@oracle.com
> Tel:  +1 650 506 8630
> Blog:  http://blogs.oracle.com/opal/
>
>
That error can sometimes be misleading.  I've noticed that it typically
happens if you're trying to push a branch containing merged commits to a
remote version of that branch that is newer than the one your commits were
merged into (i.e. you forgot to do a git pull followed by a git rebase
before doing the merge).  I can't say for certain but that's a likely
possibility that that's what happened in your case.

Moving forward, we should probably add that to the workflow as it can save
a lot of headaches moving forward.  Specifically, when merging in a branch:


   1. git checkout <destination branch>
   2. git pull [destination branch]
   3. git checkout <feature branch>
   4. git rebase <destination branch>
   5. git checkout <destination branch>
   6. git merge --no-ff <destination branch>
   7. git push origin [destination branch]
   8. git branch -d <feature branch>

What often happens is that you'll pull a branch then start working on a
feature branch.  However, while you're doing that, somebody else pushes a
newer version of the branch you pulled.  If you then merge into the older
"revision" of that branch without first making sure it's up-to-date,
everything will blow up in your face when you try to do a push.  Despite
the migraines this tends to cause, it's actually a good thing that it does
this.  After all, we don't *want* an older version of a branch being dumped
on top of a newer version.  That would get very ugly lol.  The only
downside is that the resulting error message when using --no-ff is
needlessly confusing for newcomers.

Assuming that's what happened in your case, you've got some damage control
to do.  Whenever I'm training people in the office on using Git and they
make this inevitable mistake, I always tell them to think of the damage
control as good practice lol.  =)

Anyway, assuming you haven't yet deleted the original feature branch, this
will be really easy:


   1. git checkout -b <new backup branch name> <corrupted branch name>
      - Creates a backup copy of the outdated branch with the merges.
   2. git branch -D <corrupted branch name>
      - Deletes the corrupted branch.  Note that uppercase "-D" is required
      since this is considered an "unsafe" delete.
   3. git checkout -b <corrupted branch name> origin/<corrupted branch name>
      - Re-creates the branch you just deleted, this time just grabbing the
      one currently on the remote origin.
   4. git checkout <feature branch>
      - Checkout the feature branch that you originally merged into the
      develop branch.
   5. git rebase <corrupted branch name>
      - Your feature branch will now be based off of the current develop
      branch that you just pulled from the remote origin.
   6. git checkout <corrupted branch name>
   7. git merge --no-ff <feature branch>
      - Merge the newly-rebased feature branch into this branch.
   8. git push origin [corrupted branch name]
      - Now your push should be successful.


I hope that helps!  =)

--Kris

--f46d043892ab1dd92304bba00c01--