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

Go is moving to GitHub

groups.google.com

Post reply on HN
Print view View original

171–180 of 244 posts

Re: Go is moving to GitHub

#171

Post by ksherlock »

mholt wrote: post #100
DigitalSea wrote: post #69

I think this is Google quietly admitting that Google Code is all but dead. They will not completely get rid of it, but I would not be surprised if they switch it to read only mode sometime soon. This is a momentous move for Github, especially with Microsoft moving .NET to Github as well. As someone who loves Github immensely, this makes me happy knowing that my favourite service is going to be around for a very long…

> I think this is Google quietly admitting that Google Code is all but dead. Well, I doubt that Google Code engineers or project managers had much, if anything, to do with the decision to move the Go project.

How many google code (project hosting, that is) engineers and project managers can there possibly be? The what's new wiki[1] has no activity in 2014 and only two entries from 2013, both of which are removing functionality (code search and downloads).

[1] https://code.google.com/p/support/wiki/WhatsNew

Re: Go is moving to GitHub

#172

Post by nbouscal »

annnnd wrote: post #168

I think these are two separate issues: 1) Go is moving from Google Code to Github 2) Go is moving from Mercurial to Git To echo another user in the thread: "am I the only one who prefers Mercurial to Git?" In my view Mercurial is on par or even superior to Git, but lacks "Linus made it" fame. Too bad... I have used both Mercurial and Git and find hg command line interface much more intuitive to use. As for GUIs, ther…

I get the impression that people who prefer Mercurial to Git only ever talk about interfaces and not about the underlying model. It seems to me that especially for a tool as important as version control, the underlying model is significantly more important: you can wrap a mediocre interface in a nice one, but if the model isn't very good you're pretty much stuck. That isn't to say that Mercurial's model is bad per se, but it certainly strikes me as significantly less elegant than Git's. (I'd be happy to find out I'm wrong about this - I know Git's model pretty intimately but am only moderately familiar with Mercurial's.)

This problem seems to generalize quite a bit. Emphasis on surface-level characteristics rather than core differences seems to be prevalent in comparisons of databases, programming languages, web frameworks, etc. This seems quite bad, but I have no idea how to fix it.

Re: Go is moving to GitHub

#174

Post by dzsekijo »

nathany wrote: post #53
enneff wrote: post #19

Earlier quoted context omitted.

There are a lot of things lacking about GitHub's code review process (pull requests). Off the top of my head: - Merging a pull request (almost) always creates a merge commit, polluting the change history. Gerrit will automatically rebase the changes atop the master branch head, leaving a nice linear history. - Pull requests require the contributor to create a public fork of the repository they're committing to. I can…

I'm really curious to give Gerrit a try. Is it like the existing Rietveld system used for Go? - I've been using the "apply mail" flow to avoid merge commits and to squash commits when appropriate (based on Nathaniel Talbott's post http://blog.spreedly.com/author/ntalbott/#.VGVhz5PF_Zs ). It will be nice to have something automatic. - At least contributors with the commit bit can just create a feature branch and a pul…

Gerrit is a Rietveld fork, see http://en.wikipedia.org/wiki/Gerrit_(software).

Re: Go is moving to GitHub

#175

Post by coldpie »

pestaa wrote: post #165
jbergens wrote: post #163

Earlier quoted context omitted.

Am I the only one who thinks some more competition would be nice? I would like to see more code move into BitBucket or similar. New version of Kiln will make it possible to use Git and Mercurial against the same repository which sounds like a great feature (not sure if there is a free plan on Kiln yet).

You are not the only one. We finally have decentralized tools only to... put all the eggs back into one basket!

Sorta. The eggs you're placing into github's basket are different from the eggs you've decentralized. I'd argue those eggs (merge requests, issue tracking, discussions) have never really been successfully decentralized.

Re: Go is moving to GitHub

#176

Post by NateDad »

nhaehnle wrote: post #167
natefinch wrote: post #153

Earlier quoted context omitted.

The git CLI is a mess. It's inconsistent even within its own commands. For example, sometimes specifying remote and branch is done as "remote/branch" and sometimes as "remote branch". It even uses different words for the same thing - sometimes remove, sometimes rm sometimes -d. Common actions often require obscure command lines, like "make a new branch" which is git checkout -b instead of just "git branch". The reaso…

> For example, sometimes specifying remote and branch is done as "remote/branch" and sometimes as "remote branch". AFAIK those usages are semantically different, and consistently so. For example, git pull actually is "repository ref" rather than "remote ref", and will go over the network to fetch the current status of ref from the given repository. git merge, on the other hand, is simply "git merge ref"; when ref is…

> those usages are semantically different, and consistently so

They're very close to the same syntax, and the fact that they're significantly different just shows again that the CLI is a mess. If they're so different, they should have significantly different syntax. "space versus slash" is not significantly different. I'm sure I'm not the first person to create a new branch called "upstream/master" :P

The problem with git branch versus git checkout -b is that 99% of the time, what people want to do is create a branch and switch to it. The "create a branch and don't switch to it" could just be a flag on git branch. It DEFINITELY should not be two completely different commands.

> it's pretty obvious if you've taken half an hour to understand the underlying data model of Git

This is the biggest red flag about git's CLI. I shouldn't need to know the implementation to use the UI.

Re: Go is moving to GitHub

#177

Post by danielweber »

annnnd wrote: post #168

I think these are two separate issues: 1) Go is moving from Google Code to Github 2) Go is moving from Mercurial to Git To echo another user in the thread: "am I the only one who prefers Mercurial to Git?" In my view Mercurial is on par or even superior to Git, but lacks "Linus made it" fame. Too bad... I have used both Mercurial and Git and find hg command line interface much more intuitive to use. As for GUIs, ther…

I spend most of my life in Git, simply because that's where the market is. I've had people ask me Git questions during interviews, which is mind-boggling, but there you go.

Each time I've worked with Mercurial it's like a giant weight is lifted off of my shoulders. I feel great joy instead of dread each time I have to go look on Stack Overflow for "wait, just what magic flag combination do I need to use to avoid destroying all my work?"

Re: Go is moving to GitHub

#178

Post by jbergens »

sagichmal wrote: post #132
chrisconroy wrote: post #121

Earlier quoted context omitted.

You must have dealt with a completely different company and product. The public github is a lot better than the enterprise version at least in terms of stability. Still, both lack a lot of basic issue tracker and code review features. Github enterprise was a disaster with just a couple hundred users. Under the load of just a few hundred users it died almost every day. Their support team couldn't figure it out. We had…

> Still, both lack a lot of basic issue tracker and code > review features. I strongly disagree. What you might consider "basic features" I'd consider antifeatures. The bare simplicity of the issue tracker is precisely why I use it for my (large) projects. The PR model of code review scales elegantly to hundreds of contributors. I'd be devastated to see GitHub's collaboration tools move even a step toward the hellsca…

Again, that's the idea with competition in the market. What one group wants may not be what everyone else wants. If enough people really want a specific set of features it would be nice if a vendor/Open Source solutions implemented that feature. There might for exmple be big differences in how enterprises use a tool and how (big) open source project use the same kind of tool.

Re: Go is moving to GitHub

#179

Post by emmelaich »

arh68 wrote: post #77
bbx wrote: post #45

Google hosting Go on GitHub. Microsoft hosting .NET on GitHub. It must feel like an accomplishment to be implicitly endorsed by these companies. Considering open source's history, you'd think its primary management tool would be open source as well. I guess it's GitHub's combination of accessible design + performant version control + lack of ads + reliability that made it the premium source for anything open source.…

I agree. I almost think the name Git Hub is unfortunate at this point: they're doing something so right they could nearly invent their own VCS, use ESR's new tool, or even switch to hg/darcs/etc, and still gain momentum. The Go community seems to be hopping onto a fairly heavy pendulum.

github is great largely because git is the best (d)vcs. Github was the first and the best so they got (and deserve) the lion's share of the market.

Also they got a lot of clients that would have otherwise chosen code.google because Google put up barriers in terms of licences.

Re: Go is moving to GitHub

#180

Post by fiedzia »

foolfoolz wrote: post #63
tkrajcar wrote: post #11

Earlier quoted context omitted.

I'm curious what Gerrit gets them that Github doesn't have natively, too.

I used to work at a company that did 100% of code reviews on gerrit, and by 100% I mean we had a requirement all commits be approved so I spent a lot of time in gerrit. then I moved to company that uses github. it's really a big shift. GitHub is not as intuitive and It has a long learning curve. a lot of it was time needed to adjust but I really miss gerrit. gerrit makes it so clear what commits need reviews. in gith…

Github is simple and good enough for vast majority of users. Gerrit UI sucks. I really cannot express how much I hate it, and how broken and counter-intuitive it is, after working with github. For new users its just unusable. If github would try to impose it on its users, they'd loose 99% of contributions.
Post reply on HN