php-src is now on git

14 years ago by Simon Schick — view source — reply

unread

2012/3/19 David Soria Parra dsp@php.net:

Hi Internals,

The initial migration is done and initial testing was successful.

http://git.php.net/?p=php-src.git;a=summary
http://github.com/php/php-src

Please note that some branches and tags were renamed to make
the repository cleaner.

Please checkout the repository and play around. I have created
a workflow wiki page at https://wiki.php.net/vcs/gitworkflow.
There is also an FAQ at https://wiki.php.net/vcs/gitfaq.

If you have questions about the workflow or problems let me know.
General git questions should be asked in the appropriate IRC channels
and mailinglists.

David

--

Hi, David

Thanks for this great step!

As I quickly viewed into the github-repository I recognized the big
list of branches ... 52 is quite a big list ..

I don't know if someone asked just that before:
Are there plans reducing this list?
Branches (at least to me) seems to be something like big features,
bugfixes or releases that are or could actively be developed in the
future.
One step is for example closing all the php-4.x branches and leave
them as tagged open-end if changes are not merged ...

Bye
Simon

14 years ago by David Soria Parra — view source — reply

unread

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

2012/3/19 David Soria Parra dsp@php.net: Hi, David

Thanks for this great step!

As I quickly viewed into the github-repository I recognized the
big list of branches ... 52 is quite a big list ..

I don't know if someone asked just that before: Are there plans
reducing this list? Branches (at least to me) seems to be something
like big features, bugfixes or releases that are or could actively
be developed in the future. One step is for example closing all the
php-4.x branches and leave them as tagged open-end if changes are
not merged ...

absolutly. We carrying around a lot of branches since 2001. Neither
gwynne nor I wanted to remove the branches. People with full
repository access are free to cleanup the branches and tags if they
are sure that they are not longer needed. I personally dont think i am
in the position to judge which branch or tag to delete and which not.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPZ2stAAoJEAT0aMuPE7Z1awoQAKLRXhY8BHbHoIbCmbO0vz/p
7LC5WdhiQ8HLp73HpmMf/jzS6D2+8nIOCKGi4cs1tht6nqG9IqKPZRTly+XY1Bu+
KOEysrbb1/OFBSl0B2ks+KiIrS5wVvWwkfHrNcEHsE/kdUdlRT73S3k5gkHN/fzo
CLC0eZ+V/x6Tbd2Uf/nzS8ZM4b/2KdGnUCJw08nKsU5MmeUt85zTsRTAunaBzUQy
cSiVCEFJ7TMyWTPGBECXtMu+dUJFlmjcLSRe7kFyZ1YHgX7b2WZHNi4OkLrAK5Kl
ypFCr7wgHhTsR9/C3+ZzPD4BRJJvLfCWxHJz4qWl8j4fJ2SBLoHsvv/Q4alruhGY
Z0D7HsySZgh1iCfDYXslzSY7HAkfUGLZtVh2L8ezPrCeZ+GO4aHMiQwsEbnq5G4Z
NOxTR5HQBmyB2j+bc5Gsc63dxcDnySpBlmvh1XxZBYX1mSyLAlz/XzKsFpPTKOJr
I4x8eA/qf449sCMr19+m3Evy6T6uGgzEwOKuer2+K086UIfbubL12hiS29Dj5IYN
XjGcRFBHtCrGQXHNfSvMe+A3HRVCzx5Qu5UjjVm9L93+h2mn7Ix8e7bS9LAlMj3n
KZ7SHCQGoL+WknYJOfr2YFurXUgM+3n4g/beXjVbHGE88IYTaS+7f5hUtIwLMHUM
Ase72LeLJxIkN78pXCst
=IPhy
-----END PGP SIGNATURE

14 years ago by Stas Malyshev — view source — reply

unread

Hi!

I don't know if someone asked just that before:
Are there plans reducing this list?
Branches (at least to me) seems to be something like big features,
bugfixes or releases that are or could actively be developed in the
future.

With git, cost of branches is near zero, so we don't need to be too
aggressive, and git workflow usually involves branching a lot. Of
course, not every branch has to live in the main php repo :)

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

14 years ago by Stas Malyshev — view source — reply

unread

Hi!

The initial migration is done and initial testing was successful.

Thanks David! This is awesome! Great work and I think it will make
developing PHP and contributing to the project much easier. I think we
should do php.net frontpage announcement.

Please note that some branches and tags were renamed to make
the repository cleaner.

We need then to fix our docs on wiki - some of them say 5.4, some PHP_5_4.

Also a small thing - gitfaq recommends git config core.autocrlf input,
but we have some files in win32 which do not work with this setting (at
least on my Mac).

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

14 years ago by David Soria Parra — view source — reply

unread

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

Hi!

The initial migration is done and initial testing was
successful.

Thanks David! This is awesome! Great work and I think it will make
developing PHP and contributing to the project much easier. I
think we should do php.net frontpage announcement.

can someone do that?

Please note that some branches and tags were renamed to make the
repository cleaner.

We need then to fix our docs on wiki - some of them say 5.4, some
PHP_5_4.

Also a small thing - gitfaq recommends git config core.autocrlf
input, but we have some files in win32 which do not work with this
setting (at least on my Mac).

ah okay, can you remove it please? Thanks

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPZ2qvAAoJEAT0aMuPE7Z1e0sP/3gsDzHWhbb1YS+uwDQRfd/B
jjuVy4eoBmfVXPZgLvCDRtLs1WzsmShfNQtI2jGr8ZZ9tTDrbLs624VZNXpoQudW
SEFhyePPm/SRACFrpxLkAAd1vKrT+ZKUdpTjAgvK99lb29nbtYqwDp4S918+cGaP
3wlL5V0lacVL15cNs/mHZA3JE2wkvhyXVIVwnv8xjVxE7NE2NSfrkCJGlbYeJN8y
uo5Yl9oa8uRzuYdi3NakvFJzqaNqxsrl299nk91kpY9eusyYR+elzUUik+yipp3H
yhTie4/3HeNIbZM+g72BOfKFJoTKkkxvbLCKuuQwcUCHh0SBNnZeh27f7e0Yp+YX
SjTY5GF3G3xtcC3/yLUR08/G7GCrwquwU350lk1Amjyb+5mSC1XFyAQ78/Cq9Sc8
itEwwqO1MjaQk7iE9KABqwb1M48ZZXlcfbO6Pz1RkShSuG1Uxy2Eb9crnii6bJJg
RCNdJxf43p3lX1SLqP7mz0LXF1KQwpvueAN8I83BzprgYv/hT5zu8wII+frcJTWp
NJKudPVHPS8viXKVSBDfQ5WGzCpfNKLQte4QpKZQ81aVeuyyXNjrKBgy6h2Wr20E
KUE2JoUy6SjM7zL+1IeieYSsU3PKE+1nZXLmgPWWOyBjR2+oYX2aOLgIGKJJHJC9
A2PwEZR4kErUIBcAnoof
=ngSq
-----END PGP SIGNATURE

14 years ago by Christopher Jones — view source — reply

unread

Also a small thing - gitfaq recommends git config core.autocrlf
input, but we have some files in win32 which do not work with this
setting (at least on my Mac).

ah okay, can you remove it please? Thanks

Done.

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

14 years ago by Alexander Moskaliov — view source — reply

unread

Really it was a mistake to do this option recommended (I did it =)). But
I think for webprojects and documentation will need to mention this option.

With regards, Alexander Moskaliov
Irker@irker.net

2012/3/19 Christopher Jones christopher.jones@oracle.com

Also a small thing - gitfaq recommends git config core.autocrlf

input, but we have some files in win32 which do not work with this
setting (at least on my Mac).

ah okay, can you remove it please? Thanks

Done.

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

14 years ago by Kris Craig — view source — reply

unread

On Mon, Mar 19, 2012 at 11:46 AM, Alexander Moskaliov irker@irker.netwrote:

Really it was a mistake to do this option recommended (I did it =)). But
I think for webprojects and documentation will need to mention this option.

With regards, Alexander Moskaliov
Irker@irker.net

2012/3/19 Christopher Jones christopher.jones@oracle.com

Also a small thing - gitfaq recommends git config core.autocrlf

input, but we have some files in win32 which do not work with this
setting (at least on my Mac).

ah okay, can you remove it please? Thanks

Done.

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

--

Ahh ok then I figured it was probably something like that but wanted to
make sure lol. I'll go ahead and make the correction. =)

--Kris

14 years ago by Christopher Jones — view source — reply

unread

Really it was a mistake to do this option recommended (I did it =)). But I think for webprojects and documentation will need to mention this option.

With regards, Alexander Moskaliov
Irker@irker.net mailto:Irker@irker.net

Do you want to add it back (now or as appropriate), mentioning webprojects & documentation?

Chris

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

14 years ago by Alexander Moskaliov — view source — reply

unread

I think we can add it now, because we have already moved to git all web
sources.
With regards, Alexander Moskaliov
Irker@irker.net

2012/3/19 Christopher Jones christopher.jones@oracle.com

Do you want to add it back (now or as appropriate), mentioning webprojects
& documentation?

14 years ago by Derick Rethans — view source — reply

unread

There is also an FAQ at https://wiki.php.net/vcs/gitfaq.

I can't find in the FAQ what's happening with the commit mails. Can you
add that (and CC this list too)? (Refering to "The git push/commit email
notification process is under discussion (Jan 2012). For mail lists see
http://php.net/mailing-lists.php"; as well in the FAQ).

cheers,
Derick

--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug

14 years ago by David Soria Parra — view source — reply

unread

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

There is also an FAQ at https://wiki.php.net/vcs/gitfaq.

I can't find in the FAQ what's happening with the commit mails. Can
you add that (and CC this list too)? (Refering to "The git
push/commit email notification process is under discussion (Jan
2012). For mail lists see http://php.net/mailing-lists.php"; as well
in the FAQ).

I will add that.

For every push a mail with a log what revisions are pushed will be
mailed. For every commit in the push a follow up with changed files in
the subject will be mailed too.

The format should be:

[git] branch PHP-5.4 updated.
| [git] commit ab33e5176ae ext/lib/date

cheers, Derick

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPZ2vOAAoJEAT0aMuPE7Z1LFAP/ja9A4mmyQbIpy69kKUEAcIh
/XwxUF6R0xHdYsZ7JdKm7awiMIgxTYa0kdn3uvR0PREGt4MmPHIaO3Kaahg434tp
0zTbSlfnUKP3AyN1RdJ/gii23n6FHHC56qpKH+FdMQ6zVyNMWG6FczBypnL4w9uv
/ucMsM9Y98jviL55mV2b/Gb7ZOHgBbi5sXSyY+iRRBXeV9JSclHppGwR7rfy7K+8
Qeuqce1aoEgKfNxUO6fGHOZYRD8AYOrdRNlOXT+sI0MzvbT+p5jW6t0Hlv4vczMY
QTU2w28zr8ceyQYS4xghYMdqPcg/5+ogyGikGutVS38qBnnuJ1kT9VwR8L5zKFKo
NZU54pbqbsr4J4aB+mMXETJ9kaOIEEJLvRxYlyzwVzq1XWNyKbhvGi9JX3BLyolU
hgkYaWuzd77/ZjzY+JXUWpO+OIFQpjafZC8wxHEvhHRzslBfOBhdDSuub+vT15OD
QBpyuBAe2VvJ2P3VwFJ1lzSNp/buiPp7mD1fPbRo5qibDm1sqkd8KPRGztQeggBH
nx2UCsuCXKnnIRbsPiM9I37IVh1unYUv81myRmx96LYoH2o7guwQ44Ak8XmBPOKD
gSkfJ6FQPEbvFCcQqJ6hiUZvzK0p9YJtMUEEBIDajQpDQMalQ7MfIa5ypQwnIZ1u
WJAXVFsYkQO+57ySstva
=k8nl
-----END PGP SIGNATURE

14 years ago by Derick Rethans — view source — reply

unread

There is also an FAQ at https://wiki.php.net/vcs/gitfaq.

I can't find in the FAQ what's happening with the commit mails. Can
you add that (and CC this list too)? (Refering to "The git
push/commit email notification process is under discussion (Jan
2012). For mail lists see http://php.net/mailing-lists.php"; as well
in the FAQ).

I will add that.

For every push a mail with a log what revisions are pushed will be
mailed. For every commit in the push a follow up with changed files in
the subject will be mailed too.

The format should be:

[git] branch PHP-5.4 updated.
| [git] commit ab33e5176ae ext/lib/date

Can we strip out as much "nonsense" from there as possible? I am mostly
interested in the short part of the commit message; and not the words
"commit", and the hash.

I was mostly wondering where they are going to be sent to though..
PHP-CVS I hope?

cheers,
Derick

--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug

14 years ago by David Soria Parra — view source — reply

unread

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

[git] branch PHP-5.4 updated. | [git] commit ab33e5176ae
ext/lib/date

Can we strip out as much "nonsense" from there as possible? I am
mostly interested in the short part of the commit message; and not
the words "commit", and the hash.

we can strip [git]
i personally think "commit" and the hash are necessary information but
if people disagree we can change it. the current format shouldnt be a
problem for the main purpose of filtering mails based on paths.

I was mostly wondering where they are going to be sent to though..
PHP-CVS I hope?
php-cvs

cheers, Derick

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPZ20fAAoJEAT0aMuPE7Z1w/oP/0sLoQYAPM4dUCzX+fOU96Xy
efiZccfsWfj8VZ5XUEUtA1dYYmGQeYt5TL+SLxdS//L2e6g7Ndi7ANcbDTDb+XGe
W3/dLJxQbyksY773hr2kCWzMV5oZpbaqGKAj5jQlQnsNt6H54lyo0eY/JgaqY7YQ
2EhPHLGZiYRqZkcsjB09PqqyutJRLXkOd5ef6VjAlynZ+x6duC67zw/9LbYzGrSB
Mmw7y8o7dqvs+fPJJXPvUBPOvu5hJP9hW0VJEIzMsq0i8lanhtfjVNelcfXACuMY
U/SLSjdOoQTe/JNSVujTH8evZesLyuLKn/gs1XwY4nIl98Glhv/JSrq/RvC6lFAe
ewghEOX7swr/VmSeFBwQ7miLGRn/dKD7d+FY+Ay6FaADXUx9KwGHhvdp1YLPvwnd
C5/RrZFEC4fcnjwcJ68B/jhr4ZtRs0g/9WVZ4l1/8rWOviQqiEOrXgoELim+LYy3
yX0r8rmXICreuE0TaxBSS4VABsHk0guerT+XbB0TDysKyaMgE9RDx820A5aOPyUI
BWLzDsibU8J5bJS81VetSbnq6YYWelxoCzsmFtRiSW+R1+xvu2rJeh7sWJYtwkc7
/FL2ftuQTysSUxb5zpXVt1F2MLQc62eonU4SBBvqY73PAZZ0jGHyiaJtrqLzI3qv
WLelvoXKqgLCedNJkyDc
=T/FL
-----END PGP SIGNATURE

14 years ago by Kris Craig — view source — reply

unread

Hey,

Hi Internals,

The initial migration is done and initial testing was successful.

http://git.php.net/?p=php-src.git;a=summary
http://github.com/php/php-src

Please note that some branches and tags were renamed to make
the repository cleaner.

Please checkout the repository and play around. I have created
a workflow wiki page at https://wiki.php.net/vcs/gitworkflow.
There is also an FAQ at https://wiki.php.net/vcs/gitfaq.

If you have questions about the workflow or problems let me know.
General git questions should be asked in the appropriate IRC channels
and mailinglists.

David

--

Could we modify the workflow to recommend using the "--no-ff" switch when
merging in a feature branch? This is by and large the recommended approach
as it preserves the feature branch's commit history, making it
mucheasier to sort through complex features that contain numerous
commits.

--Kris

14 years ago by Kris Craig — view source — reply

unread

Also,

Hey,

Hi Internals,

The initial migration is done and initial testing was successful.

http://git.php.net/?p=php-src.git;a=summary
http://github.com/php/php-src

Please note that some branches and tags were renamed to make
the repository cleaner.

Please checkout the repository and play around. I have created
a workflow wiki page at https://wiki.php.net/vcs/gitworkflow.
There is also an FAQ at https://wiki.php.net/vcs/gitfaq.

If you have questions about the workflow or problems let me know.
General git questions should be asked in the appropriate IRC channels
and mailinglists.

David

--

Could we modify the workflow to recommend using the "--no-ff" switch when
merging in a feature branch? This is by and large the recommended approach
as it preserves the feature branch's commit history, making it mucheasier to sort through complex features that contain numerous commits.

--Kris

I noticed that the workflow page recommends using the SSH URL for cloning.
However, isn't that one much more limited access? I.e. for myself at
least, it just prompts for a password (presumably for the SSH "git" user)
which of course I don't have. Is there a reason why that's recommended or
is it just a typo? If the latter, I'd be inclined to change it to the SSL
(i.e. https) URL (which the FAQ recommends for clone/push and utilizes
php.net credentials) to minimize confusion.

--Kris

14 years ago by Kris Craig — view source — reply

unread

Me again,

Also,

Hey,

Hi Internals,

The initial migration is done and initial testing was successful.

http://git.php.net/?p=php-src.git;a=summary
http://github.com/php/php-src

Please note that some branches and tags were renamed to make
the repository cleaner.

Please checkout the repository and play around. I have created
a workflow wiki page at https://wiki.php.net/vcs/gitworkflow.
There is also an FAQ at https://wiki.php.net/vcs/gitfaq.

If you have questions about the workflow or problems let me know.
General git questions should be asked in the appropriate IRC channels
and mailinglists.

David

--

Could we modify the workflow to recommend using the "--no-ff" switch when
merging in a feature branch? This is by and large the recommended approach
as it preserves the feature branch's commit history, making it mucheasier to sort through complex features that contain numerous commits.

--Kris

I noticed that the workflow page recommends using the SSH URL for
cloning. However, isn't that one much more limited access? I.e. for
myself at least, it just prompts for a password (presumably for the SSH
"git" user) which of course I don't have. Is there a reason why that's
recommended or is it just a typo? If the latter, I'd be inclined to change
it to the SSL (i.e. https) URL (which the FAQ recommends for clone/push and
utilizes php.net credentials) to minimize confusion.

--Kris

Also on the workflow page, it shouldn't be necessary to do "git checkout -b
PHP-5.3 origin/PHP-5.3" if the local repo is already tracking from remote
(which it is if you did a git clone to set it up). Instead, you can simply
do "git checkout PHP-5.3" and it will automatically track from the remote
branch and pull the necessary data to create a local working copy.

Any objections to me changing that? The less confusing we can make it,
particularly for people who are already struggling with the SVN
withdrawals, the better IMHO. =)

--Kris

14 years ago by Christopher Jones — view source — reply

unread

I noticed that the workflow page recommends using the SSH URL for cloning.
However, isn't that one much more limited access? I.e. for myself at
least, it just prompts for a password (presumably for the SSH "git" user)
which of course I don't have. Is there a reason why that's recommended or
is it just a typo? If the latter, I'd be inclined to change it to the SSL
(i.e. https) URL (which the FAQ recommends for clone/push and utilizes
php.net credentials) to minimize confusion.

Which exact bit are you talking about, and did you check the page commit
history?

I added https:// because git: is not usable from where I am.

I believe from your emails you have more git experience than me, and I
know you've been asked several times to contribute to the docs: go do it.

Chris

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

14 years ago by Kris Craig — view source — reply

unread

Hey Chris,

On Mon, Mar 19, 2012 at 11:40 AM, Christopher Jones <
christopher.jones@oracle.com> wrote:

I noticed that the workflow page recommends using the SSH URL for cloning.

However, isn't that one much more limited access? I.e. for myself at
least, it just prompts for a password (presumably for the SSH "git" user)
which of course I don't have. Is there a reason why that's recommended or
is it just a typo? If the latter, I'd be inclined to change it to the SSL
(i.e. https) URL (which the FAQ recommends for clone/push and utilizes
php.net credentials) to minimize confusion.

Which exact bit are you talking about, and did you check the page commit
history?

I added https:// because git: is not usable from where I am.

I believe from your emails you have more git experience than me, and I
know you've been asked several times to contribute to the docs: go do it.

Chris

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

--

I sense your hostility but I think you misunderstood my question. The
workflow page currently recommends the "git:" one for cloning (which
doesn't work for me, either). I think it should be changed to "https://";,
and I fully intend on making the change myself but first I wanted to ask
here to make sure there wasn't a reason why they went with "git:" instead
(i.e. I don't want to step on anybody's toes).

If nobody objects then yeah I'll gladly update it myself. =)

--Kris

14 years ago by David Soria Parra — view source — reply

unread

--f46d043892b5b345eb04bb9cfe02
Content-Type: text/plain; charset=ISO-8859-1

Hey Chris,

On Mon, Mar 19, 2012 at 11:40 AM, Christopher Jones <
christopher.jones@oracle.com> wrote:
I sense your hostility but I think you misunderstood my question. The
workflow page currently recommends the "git:" one for cloning (which
doesn't work for me, either). I think it should be changed to "https://";,
and I fully intend on making the change myself but first I wanted to ask
here to make sure there wasn't a reason why they went with "git:" instead
(i.e. I don't want to step on anybody's toes).

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

14 years ago by Simon Schick — view source — reply

unread

2012/3/19 Kris Craig kris.craig@gmail.com:

Hey,

Could we modify the workflow to recommend using the "--no-ff" switch when
merging in a feature branch? This is by and large the recommended approach
as it preserves the feature branch's commit history, making it
mucheasier to sort through complex features that contain numerous
commits.

--Kris

Hi, Kris

I'd instead suggest to execute the following command in the git-repository:

git config --add merge.ff false

Then you do not have to add --no-ff to every merge-command you're doing.

You could even set it per branch if you want :) (just to round it up ..)
http://stackoverflow.com/questions/2500296/can-i-make-fast-forwarding-be-off-by-default-in-git

Bye
Simon

14 years ago by Kris Craig — view source — reply

unread

Simon,

On Mon, Mar 19, 2012 at 11:55 AM, Simon Schick
simonsimcity@googlemail.comwrote:

2012/3/19 Kris Craig kris.craig@gmail.com:

Hey,

Could we modify the workflow to recommend using the "--no-ff" switch when
merging in a feature branch? This is by and large the recommended
approach
as it preserves the feature branch's commit history, making it
mucheasier to sort through complex features that contain numerous
commits.

--Kris

Hi, Kris

I'd instead suggest to execute the following command in the git-repository:

git config --add merge.ff false

Then you do not have to add --no-ff to every merge-command you're doing.

You could even set it per branch if you want :) (just to round it up ..)

http://stackoverflow.com/questions/2500296/can-i-make-fast-forwarding-be-off-by-default-in-git

Bye
Simon

Yes that's a great recommendation and it should definitely be included
IMHO! However, the merge.ff option is relatively new and is not available
in many older Git clients that are still in use. So the --no-ff tag will
still probably be necessary for some people. Perhaps we should recommend
both, or would that make things too confusing?

--Kris

14 years ago by Simon Schick — view source — reply

unread

2012/3/19 Kris Craig kris.craig@gmail.com:

Simon,

Yes that's a great recommendation and it should definitely be included
IMHO! However, the merge.ff option is relatively new and is not available
in many older Git clients that are still in use. So the --no-ff tag will
still probably be necessary for some people. Perhaps we should recommend
both, or would that make things too confusing?

--Kris

Hi, Kris

Don't really know ... Do you know which version of GIT is the first
who implements this feature? Would it be a problem to require an
update or the people should find their own solution?
I think that people who don't know much about GIT or are just starting
with GIT should be fine with that as they haven't done much with that
or just installed the latest version.
The only problem I can see here is that some linux-distributions
(Debian for example) tends to keep old versions in their repositories
;) Anyways ...
I think it would be max-information to link the
stackoverflow-discussion there if someone has a question to that. But
this (of course) has to be describe it in a easy understandable way :)
and I think that's the most dificult part.

Bye
Simon

14 years ago by Kris Craig — view source — reply

unread

On Mon, Mar 19, 2012 at 1:16 PM, Simon Schick
simonsimcity@googlemail.comwrote:

2012/3/19 Kris Craig kris.craig@gmail.com:

Simon,

Yes that's a great recommendation and it should definitely be included
IMHO! However, the merge.ff option is relatively new and is not
available
in many older Git clients that are still in use. So the --no-ff tag will
still probably be necessary for some people. Perhaps we should recommend
both, or would that make things too confusing?

--Kris

Hi, Kris

Don't really know ... Do you know which version of GIT is the first
who implements this feature? Would it be a problem to require an
update or the people should find their own solution?
I think that people who don't know much about GIT or are just starting
with GIT should be fine with that as they haven't done much with that
or just installed the latest version.
The only problem I can see here is that some linux-distributions
(Debian for example) tends to keep old versions in their repositories
;) Anyways ...
I think it would be max-information to link the
stackoverflow-discussion there if someone has a question to that. But
this (of course) has to be describe it in a easy understandable way :)
and I think that's the most dificult part.

Bye
Simon

I don't know off the top of my head which version it was implemented in,
but I'm pretty sure it was relatively recent.

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

14 years ago by Christopher Jones — view source — reply

unread

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/

14 years ago by Kris Craig — view source — reply

unread

On Mon, Mar 19, 2012 at 1:39 PM, Christopher Jones <
christopher.jones@oracle.com> 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

14 years ago by Kris Craig — view source — reply

unread

Question:

On Mon, Mar 19, 2012 at 1:39 PM, Christopher Jones <
christopher.jones@oracle.com> 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

14 years ago by Ferenc Kovacs — view source — reply

unread

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

14 years ago by Kris Craig — view source — reply

unread

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

14 years ago by m@maerlyn.eu — view source — reply

unread

I don't know off the top of my head which version it was implemented in,
but I'm pretty sure it was relatively recent.

It was introduced in 1.7.6, that came out around Summer 2011.

-- Gábor

14 years ago by Christopher Jones — view source — reply

unread

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
! [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'
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/

14 years ago by Kris Craig — view source — reply

unread

On Mon, Mar 19, 2012 at 3:07 PM, Christopher Jones <
christopher.jones@oracle.com> 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:

git checkout <destination branch>
git pull [destination branch]
git checkout <feature branch>
git rebase <destination branch>
git checkout <destination branch>
git merge --no-ff <destination branch>
git push origin [destination branch]
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:

git checkout -b <new backup branch name> <corrupted branch name>
- Creates a backup copy of the outdated branch with the merges.
git branch -D <corrupted branch name>
- Deletes the corrupted branch. Note that uppercase "-D" is required
  since this is considered an "unsafe" delete.
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.
git checkout <feature branch>
- Checkout the feature branch that you originally merged into the
  develop branch.
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.
git checkout <corrupted branch name>
git merge --no-ff <feature branch>
- Merge the newly-rebased feature branch into this branch.
git push origin [corrupted branch name]
- Now your push should be successful.

I hope that helps! =)

--Kris

14 years ago by Christopher Jones — view source — reply

unread

On Mon, Mar 19, 2012 at 3:07 PM, Christopher Jones<
christopher.jones@oracle.com> 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/

14 years ago by Kris Craig — view source — reply

unread

FYI-

Hi Internals,

The initial migration is done and initial testing was successful.

http://git.php.net/?p=php-src.git;a=summary
http://github.com/php/php-src

Please note that some branches and tags were renamed to make
the repository cleaner.

Please checkout the repository and play around. I have created
a workflow wiki page at https://wiki.php.net/vcs/gitworkflow.
There is also an FAQ at https://wiki.php.net/vcs/gitfaq.

If you have questions about the workflow or problems let me know.
General git questions should be asked in the appropriate IRC channels
and mailinglists.

David

--

If you don't already have Git installed on your system and aren't sure
how/where to get it, I added a list on the FAQ for all major operating
systems.

--Kris

php-src is now on git View as Markdown

Also a small thing - gitfaq recommends git config core.autocrlf input, but we have some files in win32 which do not work with this setting (at least on my Mac).

Also a small thing - gitfaq recommends git config core.autocrlf input,
but we have some files in win32 which do not work with this setting (at
least on my Mac).