# php-src is now on git - Thread: https://externals.io/message/59030 - Original archive: https://news-web.php.net/php.internals/59030 - Started by David Soria Parra on 2012-03-19T15:24:56+00:00 - Messages: 35 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/59030.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #59030 — David Soria Parra — 2012-03-19T15:24:56+00:00 URL: https://externals.io/message/59030#59030 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 --- ## #59031 — Simon Schick — 2012-03-19T17:16:01+00:00 URL: https://externals.io/message/59030#59031 · In reply to: #59030 2012/3/19 David Soria Parra : > 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 --- ## #59032 — Stas Malyshev — 2012-03-19T17:18:01+00:00 URL: https://externals.io/message/59030#59032 · In reply to: #59030 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 --- ## #59033 — David Soria Parra — 2012-03-19T17:19:43+00:00 URL: https://externals.io/message/59030#59033 · In reply to: #59032 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Hi! > > > […] > > 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? > > > […] > > 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 --- ## #59034 — Derick Rethans — 2012-03-19T17:20:06+00:00 URL: https://externals.io/message/59030#59034 · In reply to: #59030 > 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 --- ## #59035 — David Soria Parra — 2012-03-19T17:21:49+00:00 URL: https://externals.io/message/59030#59035 · In reply to: #59031 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > 2012/3/19 David Soria Parra : 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 --- ## #59036 — Stas Malyshev — 2012-03-19T17:24:09+00:00 URL: https://externals.io/message/59030#59036 · In reply to: #59031 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 --- ## #59037 — David Soria Parra — 2012-03-19T17:24:30+00:00 URL: https://externals.io/message/59030#59037 · In reply to: #59034 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > > > […] > > 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 --- ## #59038 — Derick Rethans — 2012-03-19T17:27:24+00:00 URL: https://externals.io/message/59030#59038 · In reply to: #59037 > > > […] > > 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 --- ## #59039 — David Soria Parra — 2012-03-19T17:30:07+00:00 URL: https://externals.io/message/59030#59039 · In reply to: #59038 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > […] > > 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 --- ## #59040 — Christopher Jones — 2012-03-19T17:53:41+00:00 URL: https://externals.io/message/59030#59040 · In reply to: #59033 > > […] > > 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/ --- ## #59041 — Kris Craig — 2012-03-19T18:21:58+00:00 URL: https://externals.io/message/59030#59041 · In reply to: #59030 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 *much*easier to sort through complex features that contain numerous commits. --Kris --- ## #59042 — Kris Craig — 2012-03-19T18:34:22+00:00 URL: https://externals.io/message/59030#59042 · In reply to: #59041 Also, > 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 *much*easier 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 --- ## #59043 — Kris Craig — 2012-03-19T18:39:36+00:00 URL: https://externals.io/message/59030#59043 · In reply to: #59042 Me again, > Also, > > > > > > […] > 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 --- ## #59044 — Christopher Jones — 2012-03-19T18:40:39+00:00 URL: https://externals.io/message/59030#59044 · In reply to: #59042 > 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/ --- ## #59045 — Alexander Moskaliov — 2012-03-19T18:46:59+00:00 URL: https://externals.io/message/59030#59045 · In reply to: #59040 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 > > > > > Also a small thing - gitfaq recommends git config core.autocrlf > > […] > > Done. > > -- > Email: christopher.jones@oracle.com > Tel: +1 650 506 8630 > Blog: http://blogs.oracle.com/opal/ --- ## #59046 — Kris Craig — 2012-03-19T18:47:49+00:00 URL: https://externals.io/message/59030#59046 · In reply to: #59044 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. > > […] > 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 --- ## #59047 — Kris Craig — 2012-03-19T18:49:16+00:00 URL: https://externals.io/message/59030#59047 · In reply to: #59045 On Mon, Mar 19, 2012 at 11:46 AM, Alexander Moskaliov wrote: > 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 > > > […] > 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 --- ## #59048 — Christopher Jones — 2012-03-19T18:54:30+00:00 URL: https://externals.io/message/59030#59048 · In reply to: #59045 > 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 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/ --- ## #59049 — Simon Schick — 2012-03-19T18:55:01+00:00 URL: https://externals.io/message/59030#59049 · In reply to: #59041 2012/3/19 Kris Craig : > 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 > *much*easier 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 --- ## #59050 — Kris Craig — 2012-03-19T18:58:11+00:00 URL: https://externals.io/message/59030#59050 · In reply to: #59049 Simon, On Mon, Mar 19, 2012 at 11:55 AM, Simon Schick wrote: > 2012/3/19 Kris Craig : > > […] > approach > > […] > > 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 --- ## #59051 — Kris Craig — 2012-03-19T19:16:17+00:00 URL: https://externals.io/message/59030#59051 · In reply to: #59030 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 --- ## #59053 — Alexander Moskaliov — 2012-03-19T19:31:43+00:00 URL: https://externals.io/message/59030#59053 · In reply to: #59048 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 > Do you want to add it back (now or as appropriate), mentioning webprojects > & documentation? --- ## #59057 — Simon Schick — 2012-03-19T20:16:10+00:00 URL: https://externals.io/message/59030#59057 · In reply to: #59050 2012/3/19 Kris Craig : > 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 --- ## #59058 — David Soria Parra — 2012-03-19T20:29:20+00:00 URL: https://externals.io/message/59030#59058 · In reply to: #59046 > --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 --- Next page: https://externals.io/message/59030.md?page=2