[PHP-DEV] php-src is now on git

On Mon, Mar 19, 2012 at 3:07 PM, Christopher Jones <
[email protected]> 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.githttps://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

Question:

On Mon, Mar 19, 2012 at 2:01 PM, Kris Craig <[email protected]> wrote:

>
>
> On Mon, Mar 19, 2012 at 1:39 PM, Christopher Jones <
> [email protected]> wrote:
>
>>
>>
>> On 03/19/2012 01:31 PM, Kris Craig wrote:
>>
>>> I added an entry to the FAQ about the merge.ff option
>>> available in newer clients.
>>>
>>
>> Would it be more visible if that comment was moved to the Recommended Git
>> Settings section?
>>
>>
>> Chris
>>
>> --
>> Email: christopher.jones@oracle.com
>> Tel: +1 650 506 8630
>> Blog: http://blogs.oracle.com/opal/
>>
>>
> Hmm good idea, I'll move it there and mention the client version
> requirement (tnx for looking that up, Gábor!).
>
> --Kris
>
>
Regarding the recommended method for using git clone, after a little
tinkering I realized that I do, in fact, have SSH access for Git-- Or, to
be more precise, I didn't have access but I had the ability to make it so
that I did.

Specifically, I noticed the "SSH Key" field in user administration (is that
new or was that always there?). By using ssh-keygen and adding the
newly-generated public key to that field in my php.net user account, I was
able to successfully perform a git clone using git@git.php.net:php-src.git.

So here's my question: Assuming everyone with SVN karma can do this as
well, is there any cost that would make it undesirable for us to recommend
wide use of this? I.e. I remember somebody mentioning something about
limited SSH ports available. Could you elaborate on that?

If it is doable, then I'd recommend scrapping my previous suggestion and
going with the SSH option (though still mentioning the https one as an
lighter-weight alternative) and also adding a brief section on how to
configure add/configure the necessary keys to make it work. Again I'm more
than happy to do the heavy lifting on actually updating the docs; I just
want to make sure we're all on the same page before I do.


Thanks! =)

--Kris

>
>
> Specifically, I noticed the "SSH Key" field in user administration (is that
> new or was that always there?).


https://wiki.php.net/vcs/gitfaq#using_ssh

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

On Mon, Mar 19, 2012 at 4:03 PM, Ferenc Kovacs <[email protected]> wrote:

>
>> Specifically, I noticed the "SSH Key" field in user administration (is
>> that
>> new or was that always there?).
>
>
> https://wiki.php.net/vcs/gitfaq#using_ssh
>
> --
> Ferenc Kovács
> @Tyr43l - http://tyrael.hu
>

Lol yep that's where I found it! What I'm asking though is whether this
should be the *recommended* approach on the workflow page. I.e. are there
any potential problems with having too many people using the SSH login at
once, for example?

--Kris

On 03/19/2012 03:26 PM, Kris Craig wrote:
> On Mon, Mar 19, 2012 at 3:07 PM, Christopher Jones<
> [email protected]> 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.githttps://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.githttps://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.

Could be. Thanks for the details.

Chris


--
Email: christopher.jones@oracle.com
Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

El 20/03/12 21:45, David Soria Parra escribió:
> On 03/20/2012 09:48 PM, Ángel González wrote:
> > El 19/03/12 21:29, David Soria Parra escribió:
> >> On 2012-03-19, Kris Craig <[email protected]> wrote:
> >>> The workflow page currently recommends the "git:" one for
> >>> cloning (which doesn't work for me, either).
> >> git:// is recommended when you can use it. The access is limited
> >> due to port limiations, but the protocl itself is superior to
> >> https for the purpose.
> >>
> >> http is a fallback when you cannot use ssh (developers only) or
> >> git
> > Actually, the provided url is wrong. It lists
> > http://git.php.net/repository/php-src.git but that returns "ERR
> > access denied or repository not exported: /repository/php-src.git"
> > (that's an error given by the server)
>
> http://git.php.net/repository/php-src.git
> works for me

Sorry David. I managed to paste the wrong url there. :/
The bad url is git://git.php.net/repository/php-src.git

If you replace the protocol in my above mail, it will begin to make
sense, specially how it becomes in the working
git://git.php.net/php-src.git
after dropping "repository" from the path.

Best regards


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

El 19/03/12 21:29, David Soria Parra escribió:
> On 2012-03-19, Kris Craig <[email protected]> wrote:
>> The workflow page currently recommends the "git:" one for cloning (which
>> doesn't work for me, either).
> git:// is recommended when you can use it. The access is limited due to
> port limiations, but the protocl itself is superior to https for
> the purpose.
>
> http is a fallback when you cannot use ssh (developers only) or git
Actually, the provided url is wrong.
It lists http://git.php.net/repository/php-src.git but that returns
"ERR access denied or repository not exported: /repository/php-src.git"
(that's an error given by the server)

If you remove "repository" from the path and use just
git://git.php.net/php-src.git it works :)


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/20/2012 09:48 PM, Ángel González wrote:
> El 19/03/12 21:29, David Soria Parra escribió:
>> On 2012-03-19, Kris Craig <[email protected]> wrote:
>>> The workflow page currently recommends the "git:" one for
>>> cloning (which doesn't work for me, either).
>> git:// is recommended when you can use it. The access is limited
>> due to port limiations, but the protocl itself is superior to
>> https for the purpose.
>>
>> http is a fallback when you cannot use ssh (developers only) or
>> git
> Actually, the provided url is wrong. It lists
> http://git.php.net/repository/php-src.git but that returns "ERR
> access denied or repository not exported: /repository/php-src.git"
> (that's an error given by the server)

http://git.php.net/repository/php-src.git
works for me
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPaOxkAAoJEAT0aMuPE7Z1IUgP/imd9FqddUiAJcYnxjCFZB2T
E+U0lkIy0w6zX0nVwgFsls47ON28tcQjblVmkwotpij+1IR70UuilOrjI3aaHHSx
B0SyGUFMT7zoGAbs98tvwE2v26bYNd9fR15usZpLmnvyKoCZTXdJk8HRoyGpDQYm
D3SsnPF1P11tyHPWcs5jVpemTbGY6EnGTRJbZbCZmSBTEwB9+DB+6BzXRHu8tNx2
nNfVlinnRvbw+VTvKbeYj3eThGmXCyztWyKNpnUW+oSS7CSA6uKaFUpDFZiaWgnd
9bGOe4evkKms8z3rJdE+mnoasTwxcTpT4XvaayEYShateKhozTWxQBE0ix7BuaMI
WGkCuPhnko2fyTmhq5uxdpJL8/oxF8CejNcNCXGmi+8B1slIOXuk9owdI78g085f
pGd6BSbjXfrhJnxAGLMwifY+aTVOSyr+nnlzuUIhJDsEWX5s77O4DQ1NmwJ7rDEU
e1z0DbiL1enExipFi81H0r58J+05wPmbj4qIgZXstMhl/2qCoeCz9ZQ0z33QdEpC
5WGhShJjuiHWk7Vo/1oG1xObZ9qLefRPo7qq1D7eR7GmiCFKesCQX/VQtExkbtAR
W3fOVPeoZMbaqW280iVqQsaeuV1TsQmkCG9WyjrnoL7kwGvPMr5T4hYYL4PGep8d
Nd0JVzBlHgIINffgOc4p
=0Uto
-----END PGP SIGNATURE-----

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php