Re: [PHP-DEV] Re: Git Migration: Status Update
On Wed, March 7, 2012 1:51 pm, Sebastian Bergmann wrote: Am 07.03.2012 19:46, schrieb Kris Craig: As I and others have said already, using a Subversion branching model on Git just doesn't make any sense. How often does it have to be explained to you and others that we would like to do this step by step? First we change the tool, then we change the process. Shouldn't be too hard to understand ... Maybe it's just me, but if I told my boss we were going to change the tool and decide and document the fundamental business processes later, I don't think that would float... That said, I still can't get my head around Git at all, and so far have only managed to checkout/update on a read-only basis. Not that it matters. My code contributions to PHP have been nil so far anyway. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Git Migration: Status Update
+1 Git can be confusing for seasoned Subversion developers at first, as it really is a fundamental paradigm shift in many respects. I'm not sure why you're only able to do read-only access, though. The add/commit syntax for Git is fairly similar to that of SVN. Have you tried creating a dummy repo locally and making commits to that? I'm not privy to the latest on the Git migration project, but it could just be a Git and/or FSO permissions issue on the remote origin. --Kris On Tue, Mar 13, 2012 at 8:18 AM, Richard Lynch c...@l-i-e.com wrote: On Wed, March 7, 2012 1:51 pm, Sebastian Bergmann wrote: Am 07.03.2012 19:46, schrieb Kris Craig: As I and others have said already, using a Subversion branching model on Git just doesn't make any sense. How often does it have to be explained to you and others that we would like to do this step by step? First we change the tool, then we change the process. Shouldn't be too hard to understand ... Maybe it's just me, but if I told my boss we were going to change the tool and decide and document the fundamental business processes later, I don't think that would float... That said, I still can't get my head around Git at all, and so far have only managed to checkout/update on a read-only basis. Not that it matters. My code contributions to PHP have been nil so far anyway. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Git Migration: Status Update
On 2012-03-07, Kris Craig kris.cr...@gmail.com wrote: --f46d044304ec4e135704baa12342 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Mar 6, 2012 at 10:09 PM, Kiall Mac Innes ki...@managedit.ie wrote: On Wed, Mar 7, 2012 at 6:03 AM, Drak d...@zikula.org wrote: I know I keep promising to draft an RFC for this lol, so I'll make it a high priority to put together an RFC for a PHP Git branching model sometime this week[end]. There is no need for that. PHP will continue to use release branches with optional feature branches. We are doing one step at a time and have people adopt the changes slowly. We are after all a large project and a lot of contributors cannot spend hours of reading into a VCS and a new branching model. So we are slowly moving towards new models. After all I see no need to do it differently. You can use whatever branching model you want in your personal github repository and then send a final pull request that can be merged. Adding complexity to the main repository for no reason is not needed. Keep the complexity in your personal repositories. That is after all one of the main benefits of a decentralized version control system. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Git Migration: Status Update
Sent from my iPhone 在 2012-3-7，17:12，David Soria Parra d...@php.net 写道： On 2012-03-07, Kris Craig kris.cr...@gmail.com wrote: --f46d044304ec4e135704baa12342 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Mar 6, 2012 at 10:09 PM, Kiall Mac Innes ki...@managedit.ie wrote: On Wed, Mar 7, 2012 at 6:03 AM, Drak d...@zikula.org wrote: I know I keep promising to draft an RFC for this lol, so I'll make it a high priority to put together an RFC for a PHP Git branching model sometime this week[end]. There is no need for that. PHP will continue to use release branches with optional feature branches. We are doing one step at a time and have people adopt the changes slowly. We are after all a large project and a lot of contributors cannot spend hours of reading into a VCS and a new branching model. So we are slowly moving towards new models. +1， thanks After all I see no need to do it differently. You can use whatever branching model you want in your personal github repository and then send a final pull request that can be merged. Adding complexity to the main repository for no reason is not needed. Keep the complexity in your personal repositories. That is after all one of the main benefits of a decentralized version control system. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Git Migration: Status Update
On 7 March 2012 11:54, Kiall Mac Innes ki...@managedit.ie wrote:
On Wed, Mar 7, 2012 at 6:03 AM, Drak d...@zikula.org wrote:
[snip]
Forcing pushes to one's own topic branches in one's own fork can be
acceptable providing
upstream maintainers know before merging (for example squashing some work
after peer review), but not to the central repo without some exceptional
reason - it could cause chaos otherwise.
Gerrit has an interesting take on this, you are free to do whatever you
like on refs/heads/dev/${username}/* - including force push etc.
Maybe something like this could be useful?
I understand, but it's totally unnecessary. Features and fixes are done on
a local branch and published for review in your own local fork upstream.
When you are ready you make a pull request and someone can merge in your
code - or if you have write access to the central repo simple merge and
push to the central branch for that feature. There is no need for
complexity in the central repository. It's easy, it will just take time
for contributors to find their feet if they are not used to git.
Regards.
Drak
Re: [PHP-DEV] Re: Git Migration: Status Update
On Wed, Mar 7, 2012 at 1:12 AM, David Soria Parra d...@php.net wrote: On 2012-03-07, Kris Craig kris.cr...@gmail.com wrote: --f46d044304ec4e135704baa12342 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Mar 6, 2012 at 10:09 PM, Kiall Mac Innes ki...@managedit.ie wrote: On Wed, Mar 7, 2012 at 6:03 AM, Drak d...@zikula.org wrote: I know I keep promising to draft an RFC for this lol, so I'll make it a high priority to put together an RFC for a PHP Git branching model sometime this week[end]. There is no need for that. PHP will continue to use release branches with optional feature branches. We are doing one step at a time and have people adopt the changes slowly. We are after all a large project and a lot of contributors cannot spend hours of reading into a VCS and a new branching model. So we are slowly moving towards new models. After all I see no need to do it differently. You can use whatever branching model you want in your personal github repository and then send a final pull request that can be merged. Adding complexity to the main repository for no reason is not needed. Keep the complexity in your personal repositories. That is after all one of the main benefits of a decentralized version control system. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php A few points 1. This really wouldn't be adding complexity to the repo. We would merely be using a branching model that is more compatible with Git's feature set. As I and others have said already, using a Subversion branching model on Git just doesn't make any sense. We may as well just keep using SVN if we're not going to make use of Git's branching advantages. 2. Using different branching structures between repo clones is not considered a good practice in Git. On the contrary, it just makes the commit history that much more confusing to read. If you use a standardized branching model, on the other hand, different features/contributions can be quickly and easily identified in the history (see gitk --all). In the event of a regression or other bad feature commit, reversing it is *much*easier and cleaner if branches are clearly segregated. It also makes drafting the changelog a much less cumbersome task. 3. I'm all for using a gradual approach so that people have time to get used to it. However, that transition to a standards-compliant Git branching model is still something that does need to happen eventually. 4. Git branching is not *nearly* as complicated or confusing as you guys are making it out to be. You know how long it took me to train our IT guy at work on Git branching? 10 minutes. He then made one mistake (forgot the --no-ff), which I corrected, and ever since he's been using it without any problems and raving about how much easier it is to keep track of our commit history now than when we were on Subversion. Seriously, the learning curve is *very* minimal, even for those who are used to SVN branching. 5. Enough people have expressed support for this idea to justify drafting an RFC and letting it be voted on IMHO. However, I would like to address your concerns about confusion (though experience tells me that they're largely unfounded), so when I draft it I'll propose a gradual adoption scheme of some sort so that anyone who feels intimidated by adhering to mainstream accepted Git branching standards won't feel disenfranchised. 6. There are also scripts that simplify this model ( https://github.com/nvie/gitflow), though I've never used them myself. But I'll take a look and see if that might be something that could be recommended for anyone who doesn't want to spend the few minutes it would take to learn t his model. --Kris
Re: [PHP-DEV] Re: Git Migration: Status Update
Am 07.03.2012 19:46, schrieb Kris Craig: As I and others have said already, using a Subversion branching model on Git just doesn't make any sense. How often does it have to be explained to you and others that we would like to do this step by step? First we change the tool, then we change the process. Shouldn't be too hard to understand ... -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Git Migration: Status Update
Umm Sebastian, how many times do I have to explain that *I agree with you*?! Please read my post before responding. Specifically, point #5. I hate repeating myself, so I'll simply copy/paste it if you don't mind: when I draft it I'll propose a gradual adoption scheme --Kris On Wed, Mar 7, 2012 at 10:51 AM, Sebastian Bergmann sebast...@php.netwrote: Am 07.03.2012 19:46, schrieb Kris Craig: As I and others have said already, using a Subversion branching model on Git just doesn't make any sense. How often does it have to be explained to you and others that we would like to do this step by step? First we change the tool, then we change the process. Shouldn't be too hard to understand ... -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Git Migration: Status Update
Kris Craig wrote: As I and others have said already, using a Subversion branching model on Git just doesn't make any sense. We may as well just keep using SVN if we're not going to make use of Git's branching advantages. I completely disagree. There's no need to completely switch your branching model or mental workflow. The git-flow article is just one of many ways you can do branching (I don't particularly have an opinion on it, but I don't use it). Personally, I switch between using feature branches and using release branches, much like PHP. Personally, I don't think PHP's system needs to change any time soon (or indeed, at all), unless a majority of contributors really want to. It's just a waste of time and resources otherwise. -- Ryan McCue http://ryanmccue.info/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Git Migration: Status Update
On 5 March 2012 03:15, David Soria Parra dso...@gmx.net wrote: No. We will always need to be able to delete branches created, or tags (we had situations were we needed to retag, for example). That in itself can be used to do a forced push: [snip] I am also not a strong believer trying to forbid as much as possible. If you have an SVN account you are trusted enough to not just delete something that is used. Also thanks to the decentralized model of git we all have backups, so we can just recreate it. Additionally, if someone force pushes a branch overwriting work it can always be recovered by a sysadmin from the reflog on the remote server. It's not a problem. However I stress, that something is pretty wrong if people are force pushing branches to the main repo and I'd personally be slapping wrists if I saw it for any project I oversee. Forcing pushes to one's own topic branches in one's own fork can be acceptable providing upstream maintainers know before merging (for example squashing some work after peer review), but not to the central repo without some exceptional reason - it could cause chaos otherwise. Regards, Drak
Re: [PHP-DEV] Re: Git Migration: Status Update
On Wed, Mar 7, 2012 at 6:03 AM, Drak d...@zikula.org wrote:
[snip]
Forcing pushes to one's own topic branches in one's own fork can be
acceptable providing
upstream maintainers know before merging (for example squashing some work
after peer review), but not to the central repo without some exceptional
reason - it could cause chaos otherwise.
Gerrit has an interesting take on this, you are free to do whatever you
like on refs/heads/dev/${username}/* - including force push etc.
Maybe something like this could be useful?
Kiall
Re: [PHP-DEV] Re: Git Migration: Status Update
On Tue, Mar 6, 2012 at 10:09 PM, Kiall Mac Innes ki...@managedit.ie wrote:
On Wed, Mar 7, 2012 at 6:03 AM, Drak d...@zikula.org wrote:
[snip]
Forcing pushes to one's own topic branches in one's own fork can be
acceptable providing
upstream maintainers know before merging (for example squashing some work
after peer review), but not to the central repo without some exceptional
reason - it could cause chaos otherwise.
Gerrit has an interesting take on this, you are free to do whatever you
like on refs/heads/dev/${username}/* - including force push etc.
Maybe something like this could be useful?
Kiall
Again I would just stress that, if people followed a Git branching model
and only made direct commits to feature branches they themselves
create/maintain, this scenario shouldn't be one that's likely to come up.
Once a feature branch is complete and it's been tested/approved/whatever
(process is important), you simply do a fresh pull of the develop (or, in
this case, version) branch, rebase the feature off of that, then merge it
into the develop branch and do a push. Using this approach, any merge
conflicts that might arise (such as overwriting work that somebody else
recently contributed) would be caught before anything is pushed. Instead,
said conflicts are resolved manually and then Git proceeds with the merge.
This is similar in concept to what Kiall alluded to.
I know I keep promising to draft an RFC for this lol, so I'll make it a
high priority to put together an RFC for a PHP Git branching model sometime
this week[end].
--Kris
[PHP-DEV] Re: Git Migration: Status Update
(3) Karma system fixes. Already done by me. People who have access to the root of a repository are able to do forced pushes. Do you think it's good idea not to forbid forced pushes at all? Cheers Jaroslav -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Git Migration: Status Update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/04/2012 10:32 AM, Jaroslav Hanslik wrote: (3) Karma system fixes. Already done by me. People who have access to the root of a repository are able to do forced pushes. Do you think it's good idea not to forbid forced pushes at all? No. We will always need to be able to delete branches created, or tags (we had situations were we needed to retag, for example). That in itself can be used to do a forced push: git push :master git push mynewmaster:master Will be equal to git push +mynewmaster:master equal to git push --force mynewmaster:master I am also not a strong believer trying to forbid as much as possible. If you have an SVN account you are trusted enough to not just delete something that is used. Also thanks to the decentralized model of git we all have backups, so we can just recreate it. David -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPU98AAAoJEAT0aMuPE7Z1SM8P/1eN+edqsqoMPukCZfeeWbFm DM4wRS1UYyc4WZ2LrUi/6+hadgEk4QZLwkLiZPw+CuYwlGtkRhIoPWskV3HK4xT9 HqdMeHxTxEAjsq0dnb37hklSGc2LlTFRnUhCHkrZdGb4OZEjOXeQBVa8ud/32Exa Cjxcyrmrzdxzu65W1P203zjAwo4jCR24PgWw4qhAqqI4UNYuHhgmIvptOo0MMvZV bkZ2GzKDsZladGG+mVwHdxZNwPOU9CxFnWG36wX7tl11uX80M+4WMTTJ43T1kpif ZhqbUrUWwitaZfdLBE9apKpwzO09cQdEsY7hgezZNntyH4PmHV+NCvCgz+BBywzM ivxNSjvTj8Kt3p4Y63WXOlfdrhTG/65hoZQTMn2Mv3qSIx3lVIqnUc/UFk5WBEI/ qOBARLGBtqy1ytMTdLLAcYN3cqFKS+zV0ucYIrBClr1LeIuAkIjfXNZ55CILmGy8 KEwJn6gC495jzV3LK7dw9S0mUiVvraG3IeBsNcJr8OELPZFC/U5IZHO0o1bafXWQ I/iqAA2tPeHQ289XyyHRSqL+qQHfDwP75gB0uUcu43lSieu0bNwkCI7IotHtC5vi dePV4pzyj+Yjyicx4NcrurWW5BeLafe8l1wvzUNS7SmrtUr3ZMJkj6qIVbVq6hq5 GvGw6+527FSIwn0TUGC2 =+P5T -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Git Migration: Status Update
I was about to respond to Lester's comments but it looks like Jeremiah beat me to it (again). Yeah he's correct in that bad habits refers to using Git the same way you would use Subversion. It was not mean to refer to how you've used Subversion itself. @David Generally, I would resolve this by having an intermediary branch intended solely for such collisions. For example: git checkout PHP_5.3 (git commits) git checkout PHP_5.4 (git commits) git checkout PHP_5.3-5.4_bridge git merge --no-ff PHP_5.3 git merge --no-ff PHP_5.4 (resolve merge conflicts, if any) git checkout PHP_5.4 git merge --no-ff PHP_5.3-5.4_bridge (then, when it's time for a major release; which is the only time master should ever be used) git checkout -b Release-(version number) PHP_5.4 (any last-minute release commits; basically, each commit is a release candidate) git checkout master git merge --no-ff Release-(version number) git checkout PHP_5.4 git merge --no-ff Release-(version number) git branch -d Release-(version number) The above approach would allow for David's scenario of merging 5.3 changes into 5.4 without disrupting development on either branch in the event of merge conflicts, simultaneous commits, etc. I could probably draft something a little more comprehensive if anyone's interested. --Kris On Sun, Mar 4, 2012 at 1:30 PM, David Soria Parra dso...@gmx.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/04/2012 10:32 AM, Jaroslav Hanslik wrote: (3) Karma system fixes. Already done by me. People who have access to the root of a repository are able to do forced pushes. Do you think it's good idea not to forbid forced pushes at all? No. We will always need to be able to delete branches created, or tags (we had situations were we needed to retag, for example). That in itself can be used to do a forced push: git push :master git push mynewmaster:master Will be equal to git push +mynewmaster:master equal to git push --force mynewmaster:master I am also not a strong believer trying to forbid as much as possible. If you have an SVN account you are trusted enough to not just delete something that is used. Also thanks to the decentralized model of git we all have backups, so we can just recreate it. David -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPU98AAAoJEAT0aMuPE7Z1SM8P/1eN+edqsqoMPukCZfeeWbFm DM4wRS1UYyc4WZ2LrUi/6+hadgEk4QZLwkLiZPw+CuYwlGtkRhIoPWskV3HK4xT9 HqdMeHxTxEAjsq0dnb37hklSGc2LlTFRnUhCHkrZdGb4OZEjOXeQBVa8ud/32Exa Cjxcyrmrzdxzu65W1P203zjAwo4jCR24PgWw4qhAqqI4UNYuHhgmIvptOo0MMvZV bkZ2GzKDsZladGG+mVwHdxZNwPOU9CxFnWG36wX7tl11uX80M+4WMTTJ43T1kpif ZhqbUrUWwitaZfdLBE9apKpwzO09cQdEsY7hgezZNntyH4PmHV+NCvCgz+BBywzM ivxNSjvTj8Kt3p4Y63WXOlfdrhTG/65hoZQTMn2Mv3qSIx3lVIqnUc/UFk5WBEI/ qOBARLGBtqy1ytMTdLLAcYN3cqFKS+zV0ucYIrBClr1LeIuAkIjfXNZ55CILmGy8 KEwJn6gC495jzV3LK7dw9S0mUiVvraG3IeBsNcJr8OELPZFC/U5IZHO0o1bafXWQ I/iqAA2tPeHQ289XyyHRSqL+qQHfDwP75gB0uUcu43lSieu0bNwkCI7IotHtC5vi dePV4pzyj+Yjyicx4NcrurWW5BeLafe8l1wvzUNS7SmrtUr3ZMJkj6qIVbVq6hq5 GvGw6+527FSIwn0TUGC2 =+P5T -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
