Git Migration: Status Update

13 years ago by Kris Craig — view source

unread

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_)

13 years ago by jeremiah.dodds@gmail.com — view source

unread

Kris Craig kris.craig@gmail.com 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.

13 years ago by Kris Craig — view source

unread

+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 kris.craig@gmail.com 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.

13 years ago by Lester Caine — view source

unread

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

13 years ago by jeremiah.dodds@gmail.com — view source

unread

Lester Caine lester@lsces.co.uk writes:

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!

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).

13 years ago by Lester Caine — view source

unread

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

13 years ago by Jeremiah — view source

unread

Lester Caine lester@lsces.co.uk writes:

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?

I use Hg at work, and while it's a pretty fine DVCS, it's more in line
with SVN's mindset than git's in parts. Namely, Hg focuses, afaict, on
making it easy to move the commit history forward in time by abstracting
over the manipulation of the DAG. Git focuses on manipulation of the
DAG -- the line between locally-visible and remotely-visible stuff is
more blurry in Hg than in git, and it feels like you're using the tool
in unintended ways when you clarify that line in ways Hg doesn't
expect. That's not necessarily a bad thing or whatnot, just a thing.

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?

If the experimental branches are long(er)-lived and worked on or of
interest to people who'd be checking out master, sure. There's
definitely a balancing act -- you don't want 500 experimental branches
laying around yer main repo, but that probably won't happen, in no small
part because when you merge the experimental branch in to a master
release you can just delete it. The commits won't be lost, but it won't
be showing up in git branch -ar or whatnot -- the branch is just a
pointer to a node in the DAG to git.

There isn't the concept of "permanent always-stick-around-branch" like
in Hg, unless you decide to make it so.

For a good example of "hey keep these relevant branches around on
master", take a look at https://github.com/symfony/symfony . There's a
few branches sitting around on their main repo at any point in time --
the master, development branch, maybe some other feature,
whatever. Like you mention, people interested in a particular niche of
the framework are pulling from branches on each others git repositories,
and there are a ridiculous amount of branches in the ecosystem, see
https://github.com/symfony/symfony/network .

For a bad example, look at the git mirrors of emacs (at least the last
time I looked at them). Yeah, there's reasons for it there, but the
point is that having too many of them produces noise. Which is true.

I don't think there are any hard and fast rules here, but at least git
makes it easy to change things up if they lean too far in either
direction.

13 years ago by Jaroslav Hanslik — view source

unread

(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

13 years ago by David Soria Parra — view source

unread

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

(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

13 years ago by Kris Craig — view source

unread

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

(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

13 years ago by Drak — view source

unread

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

13 years ago by Kiall Mac Innes — view source

unread

[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

13 years ago by Kris Craig — view source

unread

[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

13 years ago by David Soria Parra — view source

unread

--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.

13 years ago by Xinchen Hui — view source

unread

Sent from my iPhone

在 2012-3-7，17:12，David Soria Parra dsp@php.net 写道：

--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.
+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.

13 years ago by Kris Craig — view source

unread

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

On Tue, Mar 6, 2012 at 10:09 PM, Kiall Mac Innes kiall@managedit.ie
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.

--

A few points....

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.
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
mucheasier and cleaner if branches are clearly segregated. It also
makes
drafting the changelog a much less cumbersome task.
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.
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.
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.
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

13 years ago by Sebastian Bergmann — view source

unread

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/

13 years ago by Kris Craig — view source

unread

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 sebastian@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 Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/

13 years ago by Richard Lynch — view source

unread

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-xclick&hosted_button_id=FS9NLTNEEKWBE

13 years ago by Kris Craig — view source

unread

+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

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-xclick&hosted_button_id=FS9NLTNEEKWBE

13 years ago by Ryan McCue — view source

unread

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/

13 years ago by Drak — view source

unread

[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

13 years ago by Stefan Marr — view source

unread

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

13 years ago by jeremiah.dodds@gmail.com — view source

unread

Stefan Marr php@stefan-marr.de writes:

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?

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.

13 years ago by David Soria Parra — view source

unread

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

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?
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

Git Migration: Status Update

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL