

I Don’t Git GitHub Yet, But I Hope I Will - edw519
http://rickross.developerblogs.com/2009/12/25/i-dont-git-github-yet-but-i-hope-i-will/

======
jrockway
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."

~~~
tolenka
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.

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

~~~
tolenka
_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.

~~~
FooBarWidget
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.

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

~~~
pjhyett
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.

~~~
cmelbye
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.

------
pohl
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...](http://ftp.gnu.org/non-
gnu/cvs/source/stable/1.11.21/cederqvist-1.11.21.pdf)

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.

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

