Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PHP will switch to git

news.php.net

Post reply on HN
Print view View original

91–100 of 108 posts

Re: PHP will switch to git

#91

Post by Ixiaus »

cageface wrote: post #76
Ixiaus wrote: post #40

Earlier quoted context omitted.

I'm a pious hg user - even gave git a good run (mostly because of Github). I can't get over how amazing mercurial patch-queues are. Big win. I love mercurial's easy plugin development and hooks (thank you Python); I love how many awesome plugins exist for mercurial. On and on and on.

I'm pretty addicted to git's lightweight branching now. Mercurial looks appealing in some ways but, from what I understand, it doesn't support anything similar, at least not in the core.

For heavier work, hg's patch queue's are unmatched. (not to mention you can version the patch queue as well!)

If bookmarks are too lightweight for something (say you have an experimental branch that you want to branch on-top of) patch queues are amazing.

Not to mention their ease of use!!

http://hgbook.red-bean.com/read/managing-change-with-mercuri...

Re: PHP will switch to git

#92

Post by Ixiaus »

eru wrote: post #47
Ixiaus wrote: post #40

Earlier quoted context omitted.

I'm a pious hg user - even gave git a good run (mostly because of Github). I can't get over how amazing mercurial patch-queues are. Big win. I love mercurial's easy plugin development and hooks (thank you Python); I love how many awesome plugins exist for mercurial. On and on and on.

Next time you have to use git: Remember, there are also patch-queues for git.

/me did not know this - thank you for the fill in (I'll stop preaching about them for hg then, I thought they were unique to hg!)

Re: PHP will switch to git

#94

Post by georgieporgie »

billybob wrote: post #75
socratic wrote: post #59

Earlier quoted context omitted.

You present an interesting tool for settling such debates. However, I believe the more appropriate URL would be: http://www.indeed.com/jobtrends?q=git%2C+hg%2C+mercurial%2C+... Obviously, cvs and svn will be with us for some time still, but those are not distributed version control systems (DVCS). However, you raise a good question: is distributed version control so much better than centralized version control that w…

"is distributed version control so much better than centralized version control that we will all eventually be using a DVCS?" I can't predict the future, but I do think DVCS is fundamentally superior. Joel Spolsky called it "possibly the biggest advance in software development technology in the ten years I’ve been writing articles here." ( http://www.joelonsoftware.com/items/2010/03/17.html ) Let me describe a key we…

DVCS eliminates this painful choice. Commit as often as you like on your local repo

I use Subversion or CVS. When I'm coding on a team, we're usually working on a branch of the code. Additionally, I'm typically working on my own branch of that branch, which is my own sandbox.

I check in whenever it makes any sense. My only rule is that the code must compile. When I reach a point where I want my peers to receive my code, I merge to the team's branch.

How is my process any different than using Git?

Re: PHP will switch to git

#95

Post by georgieporgie »

urschrei wrote: post #77
georgieporgie wrote: post #51

Earlier quoted context omitted.

Git appears to be fast becoming the standard DVCS. Whenever I read a statement about popularity of technology, the first thing I do is check the job ratios: http://www.indeed.com/jobtrends?q=cvs%2C+subversion%2C+git&#... Git has been picking up speed, but Subversion seems to be (nearly) matching its growth. This makes me feel slightly less bad that all my personal projects are checked into Subversion on Dreamhost. :-…

I can't speak for anyone else, but I would personally be extremely hesitant about taking a job anywhere that doesn't use a DVCS (and, realistically, for 'DVCS' read: Git or Hg). The technology an organisation uses says a lot about its culture. Anyone who hasn't switched to, or isn't in the process of switching to a DVCS is at a huge disadvantage.

Anyone who hasn't switched to, or isn't in the process of switching to a DVCS is at a huge disadvantage.

In what way? I've dabbled with Git, but I don't see any advantage in it versus Subversion.

Re: PHP will switch to git

#96

Post by breck »

jarofgreen wrote: post #70

Some folk jumping to conclusions in the comments here ... The linked message is one post on an internal mailing list. It was intended as a summary of the votes, for the voters. It has no broader context of the situation they face or no links to any debates that might have happened before because of the audience it was aimed at. If anyone from PHP internals wants to tell us about the background of this decision that w…

This discussion has been going on for a about 1.5 months. Even before that actually, but the discussion that led to this move starts here:

http://marc.info/?l=php-internals&m=131275031209004&...

- PHP Internals Lurker

Re: PHP will switch to git

#97

Post by benaston »

georgieporgie wrote: post #95
urschrei wrote: post #77

Earlier quoted context omitted.

I can't speak for anyone else, but I would personally be extremely hesitant about taking a job anywhere that doesn't use a DVCS (and, realistically, for 'DVCS' read: Git or Hg). The technology an organisation uses says a lot about its culture. Anyone who hasn't switched to, or isn't in the process of switching to a DVCS is at a huge disadvantage.

Anyone who hasn't switched to, or isn't in the process of switching to a DVCS is at a huge disadvantage. In what way? I've dabbled with Git, but I don't see any advantage in it versus Subversion.

Are you serious? With a DVCS you can commit to a personal repository offline, this in itself is a killer feature. Git also tracks content rather than files which makes renaming so much less problematic when it comes to subsequent merges (and who likes merges?). Git has the concept of stashing changes enabling rapid context switches without losing work in progress. It is significantly faster. It uses less disk space for branches. Creating branches is much quicker due to a fundamentally different way of branching. Finally, it has a killer app in GitHub. What more do you want?

Re: PHP will switch to git

#98

Post by georgebashi »

eru wrote: post #47
Ixiaus wrote: post #40

Earlier quoted context omitted.

I'm a pious hg user - even gave git a good run (mostly because of Github). I can't get over how amazing mercurial patch-queues are. Big win. I love mercurial's easy plugin development and hooks (thank you Python); I love how many awesome plugins exist for mercurial. On and on and on.

Next time you have to use git: Remember, there are also patch-queues for git.

Which do you use? I've had a quick google and only found Guilt as a serious contender, and that doesn't seem to quite do what hg patch queues do (especially wrt publishing queues). I'm interested as it seems like quite a common workflow (for me at least) that doesn't really fit into the Git model.

Re: PHP will switch to git

#99

Post by georgieporgie »

benaston wrote: post #97
georgieporgie wrote: post #95

Earlier quoted context omitted.

Anyone who hasn't switched to, or isn't in the process of switching to a DVCS is at a huge disadvantage. In what way? I've dabbled with Git, but I don't see any advantage in it versus Subversion.

Are you serious? With a DVCS you can commit to a personal repository offline, this in itself is a killer feature. Git also tracks content rather than files which makes renaming so much less problematic when it comes to subsequent merges (and who likes merges?). Git has the concept of stashing changes enabling rapid context switches without losing work in progress. It is significantly faster. It uses less disk space f…

Are you serious?

Was that necessary?

As I said to billybob, when I work in cvs or Subversion, my team is working on a branch. Personally, I work on a branch of that branch. I check in anytime I like. When I want my teammates to receive my code, I merge back to the team branch. So, I don't really get the 'sandbox' advantage of git.

Speed and disk space have never been an issue for me with cvs or Subversion. The content-tracking sounds interesting, but really, I don't rename files all that often.

it has a killer app in GitHub

That doesn't have any sway on my choice of version control. I sometimes retrieve files from GitHub, but that's about it.

I don't know, I haven't heard anything really compelling about git. People who use it seem really excited about it, but not for any reasons that strike me as particularly objective.

Re: PHP will switch to git

#100

Post by benaston »

georgieporgie wrote: post #99
benaston wrote: post #97

Earlier quoted context omitted.

Are you serious? With a DVCS you can commit to a personal repository offline, this in itself is a killer feature. Git also tracks content rather than files which makes renaming so much less problematic when it comes to subsequent merges (and who likes merges?). Git has the concept of stashing changes enabling rapid context switches without losing work in progress. It is significantly faster. It uses less disk space f…

Are you serious? Was that necessary? As I said to billybob, when I work in cvs or Subversion, my team is working on a branch. Personally, I work on a branch of that branch. I check in anytime I like. When I want my teammates to receive my code, I merge back to the team branch. So, I don't really get the 'sandbox' advantage of git. Speed and disk space have never been an issue for me with cvs or Subversion. The conten…

Please accept my apologies, my original response was a little OTT. The objective reasons for making the switch are:

- its a lot faster (IIRC creating a branch in subversion is the same as a copy operation) - the merging algorithm is better (this is so important IMO) - you get to commit when disconnected from the network - because it is faster and uses significantly less space, you can improve the way you segregate changes, giving you more (and improved) options when it comes to your branching strategy

Post reply on HN