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.
Their website design is beautiful, consistent, making it delightful to use everyday. They fix issues quickly, are reliable, and have top notch customer support. They try to be at the top of their game and offer features to make our work easier (while maintaining simplicity, similar to Go). You can edit posts to fix typos, and GitHub Flavored Markdown is efficient to write. They have the best API and docs I've come across.
It helps that once you're familiar with the workflow, if another project you want to make a contribution to on GitHub, it's super convenient (unlike in the past, think SourceForge and others). Even if you're not, the web flow makes it easy to press edit and go from there.
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 to reboot the servers constantly.
We begged them to add an option to reject force push to master. They refused. We ended up monkey patching their obscured source to add the feature, but it broke on upgrades and was hard to maintain. This is something probably every single customer of theirs wants, and it should take one engineer less than a day to implement.
They only just added side by side diff support. IMHO this is a basic, core feature for any kind of code review workflow. I'm holding my breath for proper syntax highlighting while in diff view.
We've since moved on to Atlassian Stash. While it isn't perfect, it's a dream compared to Github enterprise and a lot less $$$ to boot.
> 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 hellscape that is JIRA.
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.
Beanstalk - private repo hosting for business - just released a brand new code review tool that we've been beta testing for a while now. It's rather nice and addresses many of the rough edges of pull requests. It's definitely for same-company teams as opposed to large open-source collaborative projects, though.
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.
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.
I agree with that, but just to be clear, Stash is independent of Jira (though they do integrate) and has a simple pull request model. It's actually very nice to use (pretty much just like BitBucket).
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).
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.
I agree. I almost think the name GitHub 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.
The best-engineered technology rarely becomes the most popular. I think git has some huge problems, but now it's ubiquitous. Everyone has at least a basic knowledge of it, and that makes it the best technology. Switching to something else would be a step backward.
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.
And this will never get fixed so long as people keep denying there's a problem. Even when people want to fix stuff like this it's hard to transition well from where you are to where you want to be, but at the moment people seem to be able to use this poorly evolved interface daily without noticing these ridiculous and uneccesary inconsistancies.
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.
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 reason people don't use other git frontends is that a vast majority of the help topics already out there only reference git itself. So if you want help for rebase, for example, if you're using some frontend that re-kajiggers the command line, all that help is now useless, or even worse, potentially downright incorrect.
> 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 of the form remote/branch, it will merge the current local state of remote/branch, which should be the state from the last git fetch. git merge does not access the network.
So: semantic differences, represented via different command line syntaxes. It's actually pretty reasonable, and it's pretty obvious if you've taken half an hour to understand the underlying data model of Git.
> Common actions often require obscure command lines, like "make a new branch" which is git checkout -b instead of just "git branch".
Actually, "git branch" is the command to create a new branch. "git checkout -b" is a shortcut for "create a new branch and move to that branch".
> 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.
> This is the biggest red flag about git's CLI. I shouldn't need to know the implementation to use the UI.
This speaks to a fundamental misunderstanding of the nature of Git. You need to know the model of anything to be able to use it properly- you've mixed up Git's model with its "implementation" (probably because Git's model is so lightweight and exposes a lot of its fundamental workings, [as is right for proper usability][1]). This is like saying you shouldn't have to know what files and folders are to open a document in Word, Yes, you should.
I have a good grasp of git CLI but bugger all understanding of it's internals, so you certainly don't need to know.
It seems fairly likely that what is considered a reasonable interface or a bad interface has a high level of subjectivity. Why bother getting bogged down with such debate? If you dislike git, use something else. If git is forced upon you, write some simple wrappers which provide the interface you want for your top few most used operations, or ask for help to do so from the people forcing you to use it.
Or just hang around hacker news and complain without anything changing. It's certainly my favourite method of avoiding work :)
I can't understand why they haven't tried to fix their CLI syntax. Besides having to remember when to do origin <space> branch and origin/branch, there is also how do you set the upstream branch, there's a couple of ways there.
And then creating a branch and switching to it. Is it 'git branch -c foobar' or 'git checkout -c foobar'. Was it -c for create? why not allow it on both? And its so easy to fix these things.
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.
You misread me, and it is my fault. I wrote "front ends" meaning CLI front ends, and gave two examples. You read that as "GUI front ends" and replied accordingly.
So, let me restate my argument (which I suspect you may still disagree with - but hopefully this time you'll disagree with what I actually meant to claim...)
The main complaint that I have heard about git is that its command line is an incoherent inconsistent unusable mess. My opinion is that is true, it perceived to be a much bigger problem than in really is - there are lots of CLI alternatives to working with git, and their use is negligible compared to actual git CLI use. Therefore, I suspect, a perfect git CLI would not have made a big difference in adoption.
The other thing is git is incredibly flexible. Almost no one uses all the options, but much like Microsoft Word, everyone uses a different 20%. And I suspect any system with this level of flexibility is likely to be complex. Which is not to say git is at an optimum; only to say that there's a reason there's not an accepted "perfect" CLI (for git or another VCS) - inherent complexity associated with flexibility.
The format that git stores it's data in is great, the tool most commonly used to access that data is a bit of a mess.
So there's no reason not to use git with a different UI and there are a lot of UIs for git.
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 interoperating with other social networks.
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.
Naked Objective-C is not much interesting or useful without accompanying frameworks (Foundation, Cocoa, AppKit etc). Just like publishing only C# compiler without all of .Net framework would be.
To clarify. Because of this lawsuit, Apple moved facetime away from being peer-to-peer to now being routed through Apple's servers. Since they have to use the centralized model, opening up the protocol for others to use would also require using Apple's servers to play nicely. So Apple would be footing the bill.
Thanks; it's just a present irritant because the Hangouts client for iPad is presently broken (no video), and Skype doesn't support video conference calls in their tablet clients, so I don't have a free cross-platform multi-way tablet-based video-chat protocol that works, and another entry in that space would be convenient.
Let me second this question. I have heard the equivalent of, "It's too early to be talking yet about whether we will or won't open source Swift; let's talk about that later," but I didn't interpret that to mean, "We're going to open source Swift later."
It's a really great collaboration tool. I think git itself could use some work in certain ways, but Github really makes it hard to go to any other web-based version control + pull request type tools.
Use go for a few month, loving it. but I miss not having exception compare to Python.
Is the golang spec still tightly controlled by 3 wisemen in Google and no feature is allowed to add to the language without all three in total agreement?
BTW, I like 98% of their language decide choices and absolutely LOVE the compilation speed of the program.
No, it's not controlled by them anymore. Possibly in the early days it was, but now it's much more community controlled.
You'll never get exceptions in Go. No one who has used go for a significant period of time wants exceptions. Error values are far superior (given the other features of the language, like multiple returns and interfaces for the error types).
You should continue to use Go, I don't think you'll miss exceptions after long. I understand the view, though... first time I saw Go I thought "No exceptions? Pass!". But I got over it, and now I've seen the error of my ways :) There's an amazing freedom that comes with knowing that random functions you call can't exit your function without your control.
> You'll never get exceptions in Go. No one who has used go for a significant period of time wants exceptions
If by exception you mean Java's implementation, yes.
If by exception you mean not allowing programmers to ignore error values, as most Go programs seems to do at least once, no.
I think most of this could be solved easily by either a compiler option or golint rule flagging any time someone does the classic `res, _ := foo()` punt without checking the value before the end of the block or the next time that variable is assigned to. That'd satisfy the “stop repeating C's mistakes” goal most people have without requiring the other changes which true exceptions would require.
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.e. the kind of stuff which only breaks when you're out of space, file handles, etc.).
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.
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'm impressed.