Live data from Hacker News

Go is moving to GitHub

groups.google.com

141–150 of 244 posts

Re: Go is moving to GitHub

#141

Earlier quoted context omitted.

What are gits huge problems and what other technology solves those? Not trying to put you on the spot, just curious.

IMO the main problem is that the command vocabulary is a mess. Do I need a soft, mixed or hard reset? Can I use "reset" to revert a single file, or do I need "checkout" for that? After years of using and loving git, this still confuses me. It's all logical in terms of git internals, but I'm not thinking in those terms when I want to revert something.

There are countless git frontends (easygit and git legit) that come to mind, and yet they all see negligible use.

I think the cognitive load of using git is overrated. Yes, it could probably be simpler. No, you probably can't make simple and intuitive for everyone while retaining all the features.

Given that it's also easy to work with e.g. subversion or mercurial and a git bridge, so you can use the client of your choice with a git server, and yet no one seems to do that is an indication that git is sufficiently simple to use.

Re: Go is moving to GitHub

#142
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.…

Another monopoly in the making: "github cuz everyone is on github".

Re: Go is moving to GitHub

#143

Now all we need is Jeff Bezos to buy Github :-) That would be funny. But on the story this is a great move, Github is much nicer than Google Code and more actively supported. I had not heard of Gerrit before and that was a really pleasant discovery. Now to figure out how to get that setup at the office.

Gerrit is an absolute treasure of a tool. I shudder everytime I make a pull request in Github because Gerrit's contribution model is so much better for my workflow.

It has some hairy points though. I have never liked it's review per commit model (yes, I know you can circumvent this by using merge commits).

I think the Github style works, assuming you have a sufficiently good CI system that can also receive GitHub web hooks.

Re: Go is moving to GitHub

#144
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.…

Many good things were probably enabled by their decision to put a not-too-small price tag for private repositories.

The money from private side has allowed them to run excellent public service without ads. And the good public service has certainly fuelled the growth on the private side.

Re: Go is moving to GitHub

#145

Earlier quoted context omitted.

IMO the main problem is that the command vocabulary is a mess. Do I need a soft, mixed or hard reset? Can I use "reset" to revert a single file, or do I need "checkout" for that? After years of using and loving git, this still confuses me. It's all logical in terms of git internals, but I'm not thinking in those terms when I want to revert something.

There are countless git frontends (easygit and git legit) that come to mind, and yet they all see negligible use. I think the cognitive load of using git is overrated. Yes, it could probably be simpler. No, you probably can't make simple and intuitive for everyone while retaining all the features. Given that it's also easy to work with e.g. subversion or mercurial and a git bridge, so you can use the client of your c…

> yet they all see negligible use.

Evidence? Using my own anecdotal evidence, I strongly disagree.

I checked volume for GUI-related keywords[1] against CLI-related keywords[2].

The GUI-related keywords get ~34,000 searches per month. The CLI-related keywords get ~4,500. My methodology and data aren't perfect, but it's something at least.

Your premises are:

    - People use tools that are sufficiently simple.
    - People use git CLI instead of git GUIs.
And your argument is:

    - Git CLI is sufficiently simple.
Your first premise is just wrong. People use complicated things all the time because they don't know about simpler things. People also often think things are simple and then use them wrong. In my experience, a LOT of people use git wrong/dangerously.

I've addressed your second premise above. There isn't (and may never be) good data there, though.

[1] git gui; smartgit; git client; git tower; github gui; git frontend

[2] git command; git "command line"; git cli

Re: Go is moving to GitHub

#146

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…

At least for code review, the problem isn't pull requests as-such. The features that drive me to use other tools (on top of guthub hosting, often) are things like:

* The ability to mark which commits/files have been reviewed and so track progress.

* The ability to distinguish resolved and unresolved issues

* The ability to assign a reviewer based on which code is being altered in the PR.

* Useful handling of history rewriting during review.

I also think that the PR model could be implemented in a way that would make for better collaboration. At the moment, if someone submits a PR that has some issues and you want to help them fix those issues it's a huge pain because the commits typically live in their fork to which others usually don't have push access. It would be a considerable improvement if PR branches were set up in such a way that both the original submitter and the people with commit access to upstream could push to the review branch.

Re: Go is moving to GitHub

#147
post #139

Earlier quoted context omitted.

What problems have the lack of generics caused you in development?

Last time I used a language without generics I had to cast web form values (we used a library with a general-purpose representation of "form control backed by object"). Sometimes these were incorrect, and had to be debugged. More than that, when working on the form code I had to constantly keep track of the types of things in my head, because there was no way to have the computer do it for me (we did try Hungarian no…

"a language" means it presumably was not Go, and is therefore irrelevant. All languages are different.

Re: Go is moving to GitHub

#148

Earlier quoted context omitted.

> I think this is Google quietly admitting that Google Code is all but dead. Go was on Mercurial before so it was already away from any Google own source control system.

> Go was on Mercurial before so it was already away from any Google own source control system. How being on Mercurial implies that it was "away from Google code" ? It is in fact hosted on Google code currently ( https://code.google.com/p/go/ ) PS: Google code supports: subversion, mercurial and even git ( https://code.google.com/p/support/wiki/GettingStarted#Workin... )

I think he meant that it wasn't on their internal source control system, which is one massive repo.

Re: Go is moving to GitHub

#149

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…

So, I'm no Jira fan either, but the code review side of github is definitely it's weakest point. They only just rolled out side by side reviews, something that I would have said was essential from day 1.

The fact that every comment on a review turns into a separate email is insanity, and just fills up your inbox with crap (one email for all of one person's comments on a review makes a ton more sense).

I hope they make it better, it definitely seems like a place where some TLC can go a long way.

Post reply on HN