# Git Migration: Status Update - Thread: https://externals.io/message/58549 - Original archive: https://news-web.php.net/php.internals/58549 - Started by David Soria Parra on 2012-03-03T21:58:19+00:00 - Messages: 26 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/58549.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 --- ## #58549 — David Soria Parra — 2012-03-03T21:58:19+00:00 URL: https://externals.io/message/58549#58549 Hi Internals, with 5.4. out of the door, we can start thinking about moving the php-src repository to git. Commit access to the php-src SVN repository will be disabled on March 15. I will run the final migration on that date and push the php repository to git.php.net. Updates: (1) Pull requests on github.com go to the git-pull mailinglist. Make sure you subscribe to it. (2) Johannes is working on an interface that allows people with valid PHP user accounts to close pull requests. There are a few issues at the moment that we have to fix before: (1) Fix the commit mails to the proposed format. Irker is working on that. (2) Fix the bugsweb integration, so that references to bugs inside the commits will work. Florian is working on it. (3) Karma system fixes. Already done by me. People who have access to the root of a repository are able to do forced pushes. (4) FAQ Please send me questions about workflows, etc. I will try to answer them in the gitfaq to help you out with questions. We need to make sure people know how to commit, where to commit to, etc. I have the workflows in mind, but just not written it down so far. Feel free to help me. If you are not familiar with git, play with it now. We have a playground repository that everybody can use. Go ahead. I would love to see more and more pull requests coming in or patchs send with git format-patch + sendmail. Maintainer can apply those with git am. This helps maintainers as well as reducing the amount of new user accounts needed. So go ahead, send us patches! If you now a lot about git, feel free to answer questions on http://wiki.php.net/vcs/gitfaq and help out. If you have no clue about git and how to work on php from March 15 on write your questions down on http://wiki.php.net/vcs/gitfaq . David (@dsp_) --- ## #58550 — Kris Craig — 2012-03-03T23:24:01+00:00 URL: https://externals.io/message/58549#58550 · In reply to: #58549 Thanks for the update! Quick question: As far as the branching model goes, are we going to stick with the SVN-style of just having a branch for each release version and dumping all the commits directly onto it, or do you plan on switching to a more modern Git-style branching model of merging feature sub-branches into the parent version branches? Or has this issue not been discussed yet? --Kris > Hi Internals, > > with 5.4. out of the door, we can start thinking about moving > the php-src repository to git. Commit access to the php-src SVN > repository will be disabled on March 15. I will run the final > migration on that date and push the php repository to git.php.net. > > Updates: > > (1) Pull requests on github.com go to the git-pull mailinglist. > Make sure you subscribe to it. > > (2) Johannes is working on an interface that allows people with > valid PHP user accounts to close pull requests. > > There are a few issues at the moment that we have to fix before: > > (1) Fix the commit mails to the proposed format. Irker is working on > that. > > (2) Fix the bugsweb integration, so that references to bugs inside > the commits will work. Florian is working on it. > > (3) Karma system fixes. Already done by me. People who have access to > the root of a repository are able to do forced pushes. > > (4) FAQ > Please send me questions about workflows, etc. I will try to > answer them in the gitfaq to help you out with questions. We need > to make sure people know how to commit, where to commit to, etc. > I have the workflows in mind, but just not written it down so far. > Feel free to help me. > > If you are not familiar with git, play with it now. We have a playground > repository that everybody can use. Go ahead. > > I would love to see more and more pull requests coming in or patchs send > with git format-patch + sendmail. Maintainer can apply those with git am. > This helps maintainers as well as reducing the amount of new user accounts > needed. So go ahead, send us patches! > > If you now a lot about git, feel free to answer questions on > http://wiki.php.net/vcs/gitfaq and help out. > > If you have no clue about git and how to work on php from March 15 on > write your questions down on http://wiki.php.net/vcs/gitfaq . > > David (@dsp_) --- ## #58562 — jeremiah.dodds@gmail.com — 2012-03-04T07:53:38+00:00 URL: https://externals.io/message/58549#58562 · In reply to: #58550 Kris Craig writes: > Thanks for the update! > > Quick question: As far as the branching model goes, are we going to stick > with the SVN-style of just having a branch for each release version and > dumping all the commits directly onto it, or do you plan on switching to a > more modern Git-style branching model of merging feature sub-branches into > the parent version branches? Or has this issue not been discussed yet? > > --Kris > > > > The "idiomatic" way to do this would be to have releases done as tags off of the master branch. Other than that, it makes a lot of sense to have a branch for major features / versions, and for people to develop specific features in their own branch, to rebase changes coming from parent branches onto working branches, and then to merge those into their respective parent branches after they're done. I swear that sounds much more complicated than it is. I personally think that php as a whole would *greatly* benefit from adopting this sort of development model -- it's likely that git-savvy new contributors will anyhow, and it makes accepting contributions a hell of a lot less painful. --- ## #58563 — Jaroslav Hanslik — 2012-03-04T09:32:34+00:00 URL: https://externals.io/message/58549#58563 · In reply to: #58549 > > (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 --- ## #58565 — Kris Craig — 2012-03-04T11:31:33+00:00 URL: https://externals.io/message/58549#58565 · In reply to: #58562 +1 what Jeremiah said! I've noticed that people who are accustomed to Subversion tend to go into Git using the SVN branching mindset. While that does technically work in Git, it essentially misses the point. To illustrate, let's say a person from the 16th century travelled forward through time to today. He's been using lanterns and torches all his life to light dark rooms. You then hand him a flashlight, explaining that this new technology is far better. This time traveller then proceeds to dip the end of the flashlight in kerosene and lights it on fire, using it as a torch. Technically, that time traveller would be able to light the room that way, but it would essentially negate the point of using a flashlight to begin with. Using Subversion branching practices in Git is basically the repo version of dipping a flashlight in pitch and setting it ablaze. I count myself lucky in that I started using Git before Subversion. People with that background often have an easier time at first because they aren't burdened with having to un-learn a bunch of "bad habits." If anyone is interested, I would encourage you to take a look at this: http://nvie.com/posts/a-successful-git-branching-model/ This is a widely accepted and efficient branching model that I use on all my projects. Of course, in PHP's case, it would have to be tweaked to account for parallel version development (i.e. phasing out 5.3 while continuing to build 5.4), but that's essentially how it would work. It looks like that's also what Jeremiah was referring to (though please correct me if I'm wrong). And he is right in saying that it's not nearly as confusing as it looks. It's actually really simple once you've grasped the underlying concept. What does everyone think of implementing an approach similar to this model? It would certainly make it much easier to manage in the long-run IMHO. --Kris > Kris Craig writes: > > > […] > stick > > […] > a > > […] > into > > […] > > The "idiomatic" way to do this would be to have releases done as tags > off of the master branch. Other than that, it makes a lot of sense to > have a branch for major features / versions, and for people to develop > specific features in their own branch, to rebase changes coming from > parent branches onto working branches, and then to merge those into > their respective parent branches after they're done. > > I swear that sounds much more complicated than it is. I personally think > that php as a whole would *greatly* benefit from adopting this sort of > development model -- it's likely that git-savvy new contributors will > anyhow, and it makes accepting contributions a hell of a lot less > painful. --- ## #58566 — Lester Caine — 2012-03-04T12:48:06+00:00 URL: https://externals.io/message/58549#58566 · In reply to: #58565 Kris Craig wrote: > I count myself lucky in that I started using Git before Subversion. People > with that background often have an easier time at first because they aren't > burdened with having to un-learn a bunch of "bad habits." I feel I HAVE to comment on that statement. A 'different way of work' is not 'bad habits' ... most of the time I am criticised for my method of working, but it has worked well of a long time now, and it's people who have never used a decent integrated IDE that complain that it's bad. Most of the 'extras' that are being bolted on now, and the changes to a 'git' mentality simply don't live well when one has an existing functional method of working ... but 'bad habits' do not come into it! -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php --- ## #58567 — Stefan Marr — 2012-03-04T13:09:02+00:00 URL: https://externals.io/message/58549#58567 · In reply to: #58549 Hi David: > (1) Pull requests on github.com go to the git-pull mailinglist. > Make sure you subscribe to it. > (2) Johannes is working on an interface that allows people with > valid PHP user accounts to close pull requests. > (2) Fix the bugsweb integration, so that references to bugs inside > the commits will work. Florian is working on it. > (4) FAQ Will there be an integration with pull requests and the bug tracker, or remains attaching patches the preferred way? What is the new preferred replacement for a sparse SVN checkout + single commit per change? As I understand it, currently, we try to have a single commit for all branches (PHP_5_n, and trunk). How is that supposed to be done with git? From reading https://wiki.php.net/rfc/dvcs#workflows, I assume, all branches need to receive separate commits + pushes? Thanks Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 --- ## #58577 — jeremiah.dodds@gmail.com — 2012-03-04T14:47:53+00:00 URL: https://externals.io/message/58549#58577 · In reply to: #58566 Lester Caine writes: > Kris Craig wrote: > > […] > > I feel I HAVE to comment on that statement. A 'different way of work' is not > bad habits' ... most of the time I am criticised for my method of working, but > it has worked well of a long time now, and it's people who have never used a > decent integrated IDE that complain that it's bad. Most of the 'extras' that are > being bolted on now, and the changes to a 'git' mentality simply don't live well > when one has an existing functional method of working ... but 'bad habits' do > not come into it! I'd like to do a little bit of clarification here. Apologies in advance if this is a boring bunch of review for anyone. "Bad habits" in this context is not referring to your workflow using svn being a bad thing. It refers to "not using git in a manner in line with its philosophy", or more generally "using a tool in a manner that is impractical for that tool". Svn is all about preserving commit history. A commit in svn represents a *permanent* point in the global history of a repository. You can make modifications to it, but it's painful because you're not intended to -- and if you feel the need to, you are not using svn "correctly", or you have bad habits when working with svn. Git is also about preserving commit history, but since commits can happen locally and never be shared with anybody, git only cares about it for commits that are shared. The change in mentality, and change in habits largely comes from thinking about the commits that exist only on *your* machine as only *your* commits. This is what all the extra crap that's annoying to wrap your head around is about. While git happens to preserve public commit history, it's more of a result of its primary goals than a goal itself. Its goal is to allow someone working on a codebase to freely experiment and take exploratory lines of development while staying current with what other people are doing. To accomplish the above goal, git makes its primary operations ones that are operations on a DAG that represents commits. If you have a repo with the following history (where letters are commits): A -> B -> C If you want to develop a feature, you make a branch. To git, a branch is just a pointer to a commit, so you end up with a graph like this: A -> B -> C \-> D -> E -> F If work has been done on the same line of development while you've been working on your feature, you could have a graph looking like this: A -> B -> C -> G -> H -> I \-> D -> E -> F Now, if you wanted to share your changes, you *could* merge these branches, but this gives you a graph like this: A -> B -> C -> G -> H -> I --> J \-> D -> E -> F / Which *does* serve your purpose, but it also exposes the fact that your development happened in a separate part of the graph. It's likely that you don't actually care about this, and neither do the people receiving the commits you're sharing. This is what "rebasing" is for. If instead of merging, you rebased your feature branch onto its parent, you'd get a graph like this: A -> B -> C -> G -> H -> I \-> D -> E -> F Git takes the work that's been done since you branched, and makes it so that the commits you made were made after that work was done, as far as the commit history is concerned. When you then share your changes by merging them into the parent branch, git is smart enough to see that this is a linear line of development, and doesn't create a new commit: A -> B -> C -> G -> H -> I -> D -> E -> F You can also tell git to take the *sum* of your changes and combine them into *one* commit on the parent branch instead of the three you made (referred to as squashing), if you don't think that anything but the end result is relevant for the people you're sharing with. Doing this "rebase into my feature branch and then merge into the parent branch" dance means that if conflicts happen, they happen locally, and only with the commits you have made -- which makes them easier to fix. The *ability* of git to do things like this means you can be very fluid with your workflow on your own machine, while not disturbing the workflows of other developers. In svn, the DAG in question still exists conceptually, but it's represented in a different way. Because operations that modify it effect everyone with a checkout, it's very difficult to modify it, and people merge branches with caution. In git, branching tends to be something people do ridiculously often, so much that the history of what branch was made and merged into what and so on becomes noise in a majority of cases. As such, people tend to use a workflow that is a bit different from the svn workflow as far as their machine is concerned, one that lets them keep the commit history that other people may have to go through clean. I hope that clarifies things a bit. It definitely doesn't make grokking things a whole lot easier, and it is certainly *possible* to follow a very svnish workflow using git (and may sometimes make sense to, although I am struggling to thing of such a time). --- ## #58578 — jeremiah.dodds@gmail.com — 2012-03-04T14:51:48+00:00 URL: https://externals.io/message/58549#58578 · In reply to: #58567 Stefan Marr writes: > Hi David: > > > > > […] > > Will there be an integration with pull requests and the bug tracker, or remains attaching patches the preferred way? > > What is the new preferred replacement for a sparse SVN checkout + single commit > per change? I'm not familiar enough with PHPs workflow to answer this in full, but a single commit per change can be done by developing a feature in a branch, and then merging it with the '--squash' option, which does the merge in your working directory, but does not create a commit for it, allowing you to bring in multiple commits from your branch(es) into one commit that is going to be shared in public history. --- ## #58584 — Lester Caine — 2012-03-04T16:41:15+00:00 URL: https://externals.io/message/58549#58584 · In reply to: #58577 jeremiah.dodds@gmail.com wrote: > I hope that clarifies things a bit. It definitely doesn't make grokking > things a whole lot easier, and it is certainly *possible* to follow a > very svnish workflow using git (and may sometimes make sense to, > although I am struggling to thing of such a time). I've been using Hg myself for the 'DVCS' style of working. This allows me to publish my own ports of things which others can follow, but from which I can push things back to the original project as required. I'm still not convinced that the 'production' branches such as PHP5.3 can be run without some element of management, although of cause a release will still be packaged as a tarball set and then frozen. On Hg I just pull a particular tarball ... such as PHP5.3.10 ... as I require it direct from the repo but some of the projects I am working with have now lost the 'master' codebase simply because groups of developers are now doing their own thing. The overall flexibility of DVCS still needs a mindset of maintaining a code base that follows the master route plan? Which may well be a more 'svnish' way of working when testing and committing production ready code? The question I think that needs to be asked is 'should experimental development branches exist in the master code base?' all very easy to do with DVCS, but is it practical. Does it not make sense to clone the experimental work from another source, and keep the main codebase tidy with just proven pushes that follow the production path. There is nothing actually stopping someone producing their own private branch and sharing that while it is being developed, just pushing the results back to the relevant master branch when development work has been completed? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php --- ## #58588 — David Soria Parra — 2012-03-04T21:14:53+00:00 URL: https://externals.io/message/58549#58588 · In reply to: #58567 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Hi David: > > > > > […] > > Will there be an integration with pull requests and the bug > tracker, or remains attaching patches the preferred way? Nobody has worked on that, but it's a possiblity. I would like to see pull requests supported in the bugtracker. > > What is the new preferred replacement for a sparse SVN checkout + > single commit per change? As I understand it, currently, we try to > have a single commit for all branches (PHP_5_n, and trunk). How is > that supposed to be done with git? From reading > https://wiki.php.net/rfc/dvcs#workflows, I assume, all branches > need to receive separate commits + pushes? Sparse checkouts won't work anymore. The proposed workflow is: commit to the lower possible branch, then merge up to the other branches e.g: $ git checkout PHP_5_3 ..hackhack... $ git commit $ git checkout PHP_5_4 $ git merge PHP_5_3 $ git checkout master $ git merge PHP_5_4 There will be situations were we have to cherry pick certain changesets and then make sure that git doesn't get confused. David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPU9tNAAoJEAT0aMuPE7Z1sFcP/3Bc4AFhR0D78PDpovnflR8D KWRNyl6s1w6cwo1P98NhZzIJ9DuxKg0VAkU18YZamDpoghJScJe/W9YFu4xJLuZF oaw/4HhVxiQyi60i+eAADx9rAeanVRPVlBEjB4SOsAuj2Ax9Mx8gcfUHu37X+CiT sXOfL92lDDsHx9kJMM/mHkkXpyf5xfcgUatHoTNiBY7qkmznIvVEto8ohGmjsCbh GUQK5xbIqFzcmuN9uLnfMiDsppL+fFO05VHWJam8KmpoUQ4vNINZZp7zhpjGj5on PGi3Q/5jlAtJvK0utvqpfFbolk+d+54BN6YlnfNEsP/kageNIuR42qq/5SVm6qPa qyDcmrQp5kgyOAy2SwxFYZThEel46FBgu8LmCizh6n/sCgk9hFkg1GSH7lxNA4D5 FASiv1zYDVY2RpnxTyArUmgSdns+k6gXwc2gYZ6CcDJSzTg2jSPnyyjWjbKy5Edd k8NOHxM+GduvHpbQGO1uk2sk3TLY8inWHW22IVtIZ+kiXKPW2daJs8AcKeQqUSUe /mZQ3tci8XlWiaazWbcoU5Zw5iHNp/39BRWkJi2rHCNGFEqrcUOF8o4fo9Txjlwi 7h2vhcl00el1vS5k6vNQhrPd4a98uOc2AQQOJuwlAM2+xXgoxxuGPC0kAfP4n2+s zRsjMjOBD3ZCNypV8U0R =RgaM -----END PGP SIGNATURE --- ## #58589 — David Soria Parra — 2012-03-04T21:30:40+00:00 URL: https://externals.io/message/58549#58589 · In reply to: #58563 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > […] > > > 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 --- ## #58590 — Kris Craig — 2012-03-04T22:41:29+00:00 URL: https://externals.io/message/58549#58590 · In reply to: #58589 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 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > […] > 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 --- ## #58716 — Drak — 2012-03-07T06:03:58+00:00 URL: https://externals.io/message/58549#58716 · In reply to: #58589 > 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 --- ## #58717 — Kiall Mac Innes — 2012-03-07T06:09:17+00:00 URL: https://externals.io/message/58549#58717 · In reply to: #58716 > [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 --- ## #58718 — Kris Craig — 2012-03-07T06:19:11+00:00 URL: https://externals.io/message/58549#58718 · In reply to: #58717 > > > > […] > > > 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 --- ## #58724 — David Soria Parra — 2012-03-07T09:12:18+00:00 URL: https://externals.io/message/58549#58724 · In reply to: #58718 > --f46d044304ec4e135704baa12342 > Content-Type: text/plain; charset=ISO-8859-1 > > > > > […] > 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. --- ## #58733 — Xinchen Hui — 2012-03-07T10:38:49+00:00 URL: https://externals.io/message/58549#58733 · In reply to: #58724 Sent from my iPhone 在 2012-3-7，17:12，David Soria Parra 写道： > > > […] > > 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. --- ## #58736 — Drak — 2012-03-07T12:24:00+00:00 URL: https://externals.io/message/58549#58736 · In reply to: #58717 > > > > […] > > 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 --- ## #58748 — Kris Craig — 2012-03-07T18:46:47+00:00 URL: https://externals.io/message/58549#58748 · In reply to: #58724 > > > […] > wrote: > > […] > sometime > > […] > > 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. > > -- > > > > 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 --- ## #58749 — Sebastian Bergmann — 2012-03-07T18:51:39+00:00 URL: https://externals.io/message/58549#58749 · In reply to: #58748 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 Bergmann Co-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ --- ## #58751 — Kris Craig — 2012-03-07T19:03:53+00:00 URL: https://externals.io/message/58549#58751 · In reply to: #58749 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 wrote: > Am 07.03.2012 19:46, schrieb Kris Craig: > > […] > > 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 Bergmann Co-Founder and Principal Consultant > http://sebastian-bergmann.de/ http://thePHP.cc/ --- ## #58758 — Ryan McCue — 2012-03-07T22:28:53+00:00 URL: https://externals.io/message/58549#58758 · In reply to: #58748 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 Am 07.03.2012 19:46, schrieb Kris Craig: > > […] > > 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-xclick&hosted_button_id=FS9NLTNEEKWBE --- ## #58917 — Kris Craig — 2012-03-13T17:41:57+00:00 URL: https://externals.io/message/58549#58917 · In reply to: #58915 +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 > > > […] > > 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-xclick&hosted_button_id=FS9NLTNEEKWBE --- Next page: https://externals.io/message/58549.md?page=2