I Don’t Git GitHub Yet, But I Hope I Will | Hacker News Reader

I Don’t Git GitHub Yet, But I Hope I Will

rickross.developerblogs.com

26 pointsedw51912 comments

The point is that without Github, these independent streams wouldn't exist anywhere public. With Github, you can integrate these changes.

Without Github, people would either not contribute, or "contribute" in private, and then one day maybe ask for a commit bit. With Github, people can click a button and instantly start working on your project publicly. You can review their changes whenever you want, and you can integrate them whenever you want. Or, you can ignore them.

The point is, you lower the barrier to public contribution, and get more information as a result. The author seems to see this as a bad thing. This is similar to calling the act of sweeping some dust under a rug "abstraction". "If you can't see it, it's organized."

I'm not convinced that Github itself is a net-win for the mainline projects -- without Github, your only options for long-term sustainability of a fork are to submit your patches to the project or to expend considerably more effort maintaining a local vendor branch.

If you need to add a feature to a project, that requirement isn't going to disappate just because Github does not exist -- you will almost certainly implement it regardless, and the path of least resistance will be submitting (and having it accepted) upstream.

With Github, it becomes much, much easier to create a fork, hack out what you need, and maintain that fork indefinitely in a form that can't be pulled back in without further polish/review that will likely never happen.

Uh, so? Have you ever worked anywhere that uses open source software? Often, these places have their own slightly-hacked version of everything. There is no chance the original project will ever see any of these changes; not because of legal restrictions to contributing or whatever, but because the fork-ers have no interest in publishing their changes. It would involve time and effort.

With Github, the path of least resistance is to publish your changes. If they are good, someone can clean them up and submit them properly. If they are not that good, then they can stay in the branch indefinitely.

Remember, all public contribution to open source is good. Wishing that volunteers trying to scratch their own itch would do it in a way more convenient for you is unrealistic.

(I watch my projects and pull in good branches from time to time. Sure, I have to change some stuff. But for 10 minutes of tweaking, I get days worth of work for free. So I love Github.)

Remember, all public contribution to open source is good. Wishing that volunteers trying to scratch their own itch would do it in a way more convenient for you is unrealistic.

Perhaps I have unduly high standards for contributors, but I find that cleaning up other people's incomplete or unpolished code is often difficult, time consuming, and often takes longer than just writing the feature myself.

Whereas, if the contributor opened a dialog with me, I could help guide them towards something acceptable upstream with much less effort.

Sure you can have high standards for contributors. But if said contributor can't be bothered to cleanup his patch for upstream submission, then the absence of Github won't encourage him to suddenly cleanup his patch. He'd most likely keep his changes private. Remember, people are lazy and not going through the whole cleanup/submission route is definitely easier.

With Github at the very least you can see that those people exist and what they've been up to. To me this is still better than the alternative.

"Whereas, if the contributor opened a dialog with me, I could help guide them towards something acceptable upstream with much less effort."

Perhaps, but some people really aren't all that interested in such a dialog.

I confess to forking code in order to make changes that follow the principle of Make James Happy. I am often not interested in pushing anything back to the master branch, nor in coding things "just so" in order to fit into some project's coding standards. It's a matter of expediency.

(Yes, I do also submit patches to projects when I run into bugs I think I can fix. But here I'm referring to wanting a lib or app to take a different approach to things and to do things the right way, i.e. as James sees fit. :) )

In the past I would slurp down code as a tarball or maybe svn, and I'd go about my private alterations in secret. Now, I push my quirky changes back into the daylight. The upshot is that if anyone finds my changes useful they are free to take them and apply as they wish, with no cost to me.

It's a big improvement over the past, and observing that it still does not make things as easy as possible for the owners of the upstream projects is seeing the glass as half empty.

Bingo!

I've noticed one of the few perfect divisions of coding labor in this process: the forker can more easily write the new feature with their subject knowledge, and the maintainer can more easily integrate the new feature with their domain knowledge. They each have their own independent motivations that result in the same goal by using their complimentary skills.

I've been on both sides of that trade, and it's always much nicer when I have a counterpart.

The author is making the mistake of looking to github to explain git, but that's backwards. First you need to understand what a sea change git is to your daily development (compared to subversion anyway). Offline or peer-to-peer development, painless merging, extremely fast, conceptually simple repository model, etc.

If that stuff doesn't blow you away in practice then it's silly to think that github will make any sense at all.

I agree, but it's also in our best interest to educate people about Git that show up to GitHub without any prior knowledge. Sounds like we need to do a better job of that.

That would actually be really good. Easy tutorials to do common and uncommon tasks in git for users that don't know it yet would be really useful.

One could start by understanding CVS first, I guess. One of the most important sections of "The Cederqvist Document" is "What CVS is Not", in which he discusses how CVS is not a substitute for management, nor is it a substitute for developer communication.

http://ftp.gnu.org/non-gnu/cvs/source/stable/1.11.21/cederqv...

This reality carries forward to SVN, certainly. I see no reason not to keep this same perspective in the Git/GitHub world, or to the Mercurial/Bitbucket world.

I wonder how dumb posts like this end up on HN...

Reply on news.ycombinator.com