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

231–240 of 244 posts

Re: Go is moving to GitHub

#231

Post by Laremere »

sdegutis wrote: post #187

> The world today is quite different from the world then. Not really. Everyone used Git and Github 5 years ago too. That's why it was so annoying that Go chose to use Google Code for everything, although not surprising considering it's a Google project.

Well, at the time of Go's open source announcement, Github was 1.5 years old. Go existed before that too, looking at the dates the first whiteboard doodles about what would become the Go programming language were done about a month before Github development started. Yes, Github was starting to thrive when Go was announced, but you could hardly say it had proven itself as much as it has now.

Re: Go is moving to GitHub

#232

Post by McGlockenshire »

tjgq wrote: post #225
McGlockenshire wrote: post #214

Earlier quoted context omitted.

"facebook 'cause everyone is on facebook." It's the same effect. There are only two things that are going to fix it - either something amazingly better comes along (facebook vs myspace) or the incumbent royally screws up (reddit vs digg).

To be fair, it's not entirely the same sort of thing. Git is an open protocol. Github just happens to be one of many sites hosting git repositories. Moving a repository to another host is trivial; you already have all the data in your local tree. Facebook, on the other hand, is one of a kind. I absolutely must have an account there if I want to do anything Facebook. And good luck getting your data out or interoperati…

This isn't about the technology, it's about the people using it and how they choose to interact with each other.

Re: Go is moving to GitHub

#233

Post by merijnv »

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…

You're not the only one. If you prefer the Mercurial interface, I highly recommend trying out hg-git. It's an extension that does transparent bi-directional conversion between git and mercurial. I've been using it for the past 3 years to interact with GitHub and colleagues in different companies and I have yet to run into significant problems.

There are some minor nits: occasionally I manually need to forward the "master" tag to the latest revision to push it to git and since git doesn't log file moves you can run into "broken" history for a file, where Mercurial doesn't know a file was moved. But in day-to-day use I don't really have any issues.

Re: Go is moving to GitHub

#234

Post by gorhill »

yarou wrote: post #140
enneff wrote: post #60

Earlier quoted context omitted.

We (the Go team) regularly have conversations about all kinds of programming paradigms, because we're into that kind of stuff. Some of us really like functional programming languages. But Go is not that kind of language, so those primitives do not belong there. Go is not everything to everyone, and it would be a mistake to try to make it that way. That doesn't mean that we don't see those things as generally valuable…

A bit OT, but probably the biggest roadblock for me switching over to Go is the wonky syntax. Are there any plans to make Go more accessible to someone coming from more traditional languages? (i.e. like "do" notation in Haskell) I've done the Go tutorial about 5 times last I checked (seriously), and I just can't stomach the syntax. I may be tainted by my years of C, though.

> I just can't stomach the syntax. I may be tainted by my years of C, though.

I can't relate to this.

That's exactly my years of C that makes Go quite attractive to me. The way I see Go is that it allows me to code as close to metal as C, but without the pains of C -- headers, make file/dependencies, memory management, and more.

Re: Go is moving to GitHub

#235

Post by wldcordeiro »

DannyBee wrote: post #228
wldcordeiro wrote: post #207

Earlier quoted context omitted.

If they wanted to they could turn Google Code into a real competitor for Github with full GAE and Compute integration. That would make it an amazing platform.

Who says they won't? :) Seriously though, yes, that would be really cool, but probably not something you could directly transform google code into. Google Code is a pretty legacy codebase in a lot of ways. It would likely require making a new platform to do such a thing.

Oh no doubt the codebase would likely need a massive refactoring (if not even a rewrite) but the name could stay the same.

Re: Go is moving to GitHub

#236

Post by skj »

Spitfire777 wrote: post #219
skj wrote: post #197

Earlier quoted context omitted.

Took a brief look at the front page. - No side-by-side diffs? Didn't see any in screen shots. - The scopes asked for seem very broad. I may be confused, but it seemed like it was asking for write access to all repositories, public and private. I have access to several private repos (but I don't own them) for which this is unacceptable. If the scope is limited to the ones under github.com/me then it's not as big a dea…

Hi skj! - What do you exactly mean by side-by-side diff? Currently you have diff view between the current HEAD of the Pull Request branch by the base commit. - Yes, that is true. This is a known issue mentioned by others and there is definitely a need to fix that. ReviewNinja comes from the GitHub Enterprise context, where you usually can trust the internal tool offering, that's why we kept it simple with the permiss…

Here's a screenshot of some side-by-side diff action: https://fr.atlassian.com/wac/software/fisheye/overview/scree...

Basically, it let's you look at the old code, or look at the new code, or see how they're different, all at the same time.

Inline diffs (github-style) require you to keep a context as you scan through code, and it makes it harder to keep everything in your head.

Re: Go is moving to GitHub

#237

Post by herge »

jbergens wrote: post #163
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.…

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

Kiln is dead slow, and it's review tool is even worse than github.

Re: Go is moving to GitHub

#238

Post by NateDad »

acdha wrote: post #209
NateDad wrote: post #206

Earlier quoted context omitted.

> think most of this could be solved easily by either a compiler option or golint rule You mean like errcheck? https://github.com/kisielk/errcheck I'm not sure if it can find spots where people intentionally throw away an error like in val, _ := foo() Usually people are more concerned with places where people accidentally fail to realize there's an error returned at all, like this: func foo() error { ... } foo() // e…

Ideally that'd move into the standard suite and you'd have to do something like compile with --repeat-the-mistakes-of-c to skip it. I've noticed most of the intention error punts in dense code where it looked like someone got tired of repeating checks and only checked the errors which happened while they were working. I'd bet a read-before-overwrite policy on _ would catch mostly infrequent environmental failures (i.…

Anyone who intentionally throws away errors because they "got tired" of checking errors, isn't someone I'd want on my team, and their code is not something I'd want to depend on, regardless of the language. Hopefully it would get caught in code review. But yes, it would be nice if go vet or go lint caught this syuff. Luckily, someone else wrote errcheck, and that's good enough.

Re: Go is moving to GitHub

#239

Post by coldtea »

skj wrote: post #196
coldtea wrote: post #170

Earlier quoted context omitted.

That they didn't have a say in this matter though, speaks volumes...

It would if the whole idea wasn't based on an assumption with no evidence.

You mean we need evidence to know that moving Go to GitHub would be against the interests of the Google Code people, and that they would protest such a move?

Being cautious is one thing, being a sucker for being too cautious is another.

There are things like obvious conclusions.

Re: Go is moving to GitHub

#240

Post by lmm »

enneff wrote: post #217
lmm wrote: post #138

Earlier quoted context omitted.

The merge history is the true one, it's what you want when browsing backwards to see how particular things changed. Rebase creates fake commits corresponding to a tree that never actually existed anywhere. Your history viewer should be able to linearize the tree for you if you want, but the canonical history in the repository should be the true one.

That's just one workflow. For Go, we will require that contributors (everyone working on Go) prepare their commit at head (or at least make the commit able to be automatically rebased). It makes no sense to have a merge commit for every single commit. That would add no extra information and double the size of the commit log.

It's not a merge commit for every single commit, only for every, well, merge. I sure hope people are writing new features or bugfixes in several commits, not just doing days of work and committing at the end (though I guess that would be a workflow for people who are worried about the size of the commit log).

What's the purpose of keeping a commit history at all? Really, what are your use cases? For me, the history is for looking around and understanding a particular change, or for bisecting to help understand a bug. Both of these use cases are better supported by seeing the tree as it actually was when someone was working on it, than by seeing an artificial, rebased history. What's your use case where the rebased version makes sense?

Post reply on HN