Forks are almost to easy to create. Forks get created
constantly and go no where.
I would love if GitHub supported a model where if I
forked a repo at a version and made no changes, it
treated it like a private repo. It shouldn’t be visible
to anyone except me (unless someone hits the url
directly) until I push my first commit that is different
than the upstream. At that point it should flip to
public. This would clean up some of the fork soup we see
(As mentioned in one of the post's comments, some popular projects have a lot of empty forks, which makes viewing one of their Network screens an absolute nightmare to browse when looking for active forks.)
The network graph they render already does this to some extent.
I think the argument can be made that this is exactly why git is cool. Which repository is considered the "master" repository becomes a "social decision" instead of a technical one (by means of the admin rights). However, GitHub emphasizes the role of the "original" repository by mentioning it everywhere (as pointed out by the author).
In my opinion, it is a fair point to argue that adding a description to forks would be useful. But to say that the GitHub model is fundamentally flawed takes is a step too far for me.
The article also mentions that it would be great to have more options regarding pull requests. This is indeed something that I would also find useful. Maybe there could be the "standard" pull request, but optionally the user could propose a fullow-up action on the pull request!?
That's TFA's whole point...
I agree that sometimes I find it frustrating why a fork exists, but usually just looking at it in the network view is more than enough and is exactly what makes git/github so amazing.
That aside, I think github's model is largely correct. In git itself, a commit is a child of a parent (or parents).
He isn't arguing there is an actual flaw, he is arguing that the feature isn't identical to what he hypothetically wants He doesn't give practical problems with it, just hypothetical problems.
For example, he says it's hard to tell 'the importance' of a fork. The importance of a fork is whether or not it is the original project, or a fork. If it's the original project, it's what you were looking for. If not, it's not, unless you were looking for a modification or feature missing in the original. In the latter case, you don't need to see the 'importance', whatever that means, you need to see the diff. Or have someone recommending it.
Anyway, the post just rambles for pages.
Speaking of flaws, HN has one big flaw, which is not showing sub-domains (and thus tricking me into clicking this link, thinking it was an official github thing).
When I make an argument, I try to be thorough and show evidence, then propose a solution rather than just complaining.
I agree with you that the project is important if it's important. That is exactly what I want. Let the community decide. I hate GitHub implying that my fork is any more or less important unilaterally because I was just the original or not. I document evidence that people follow that link even when the parent is a dead project I put in place.
This one issue has really been festering at me for the last couple years on GitHub. As the number of projects grow, more projects are starting to bitrot and the problem is only getting bigger.
When I find a new cool library or program on github I often have trouble finding the "official" or "best" version. Many times it is of course the root repository of all forks, but often the original developer moved on and someone else picked up his work. If there are only 2 or 3 forks I can check them all, but more is impractical.
When I put stuff on github myself I often lose interest in the software, but someone was nice enough to fork the project and keep working on it. Unfortunately my project will still always be displayed as the most important version.
Some software developers have decided to create a shared account (or, since Github now supports this too, an "Organization") to prevent this problem (see for example github.com/ruby/). When one developer decides to leave the Ruby developement team, he is simply removed from the shared account/organization, but the project URL stays the same.
You did try to talk it out and give some concrete examples. I've seen big whine-athons before and your post does not qualify as that as far as I'm concerned.
I think there's the possibility that project owners may start to delete forks and create entirely new repos when the bit rot issue starts to affect the repo they originally forked from. This has it's own set of problems and I might be a little too optimistic but I happen to think there's a chance we'll take matters into our own hands on that issue. Also, I would venture to guess that abandoned projects probably weren't so great to begin with and maybe the bitrot issue won't affect them as much? Like node.js isn't likely to go away and if it or a popular project like it is abandoned the authors would probably announce it and add it to the readme and so everyone will know to start looking at forks over the original.
Anyway, the HN community obviously thought this was important or good enough to be on the front page so you must have done something right. I'm sure if you were really rambling you'd just be lost in the "new" section. I don't always agree with what gets on the front page and I didn't agree with this being there at first either but now I'm starting to come around.
The one case I didn't link but talked about was my co-worker Michael's snipmate.vim project.
He stopped working on it because he felt it was dead end to keep supporting it since vim plugins are so hacky, but the community loves his plugin. It's has a massive number of forks and patches but he hasn't touched it since 2009.
This fork has taken up most of the new development on the project and really has pushed it hard to almost a 1.0 now: https://github.com/garbas/vim-snipmate
Although I agree that something like this should be built into Github.
Edit: after reading some other comments I'd also like to suggest that creating an organization would help. Once the project is abandoned by the creator someone else can take over and the creator just drops off. Of course this only works if people put it into practice but it can possibly mitigate some of the problems you have.
If people would be thinking of these things and put these solutions into practice then your criticisms would be a little less necessary. But alas, you can't always rely on people. It really comes down to a choice the way I see it. The way things are and the way you wish they were both have merit. What if GitHub just supported viewing forks differently? It would be cool to see a list of forks without a master for some and a hierarchy for others depending on how you want to filter the page. That would be cool and do a bit of good.
You list all the reasons you fork code, and I'm not sure why you did that. If it's to support your assertion that "all forks being equal" is a problem, that is even more rambling, because you give 4 examples of things which are of no importance to anyone but you. And this is already partly below the fold! So, if by rambling I mean "Lengthy and confused or inconsequential", I'm justified.
To correct this, you must establish immediately after you claim that 'all forks being equal' is a problem that there exists at least 2 classes of forks that should not be treated equally. You should give an actual example, so that it is clear that this is not just a hypothetical problem that doesn't happen in practice.
The only exception is if the fork contains no changes of it's own and could be fast-forward merged into the fork you are viewing. (They do this already in the graph they render under the network view.)
If I had to pick one day to do things I'd keep them as is. But having some sort of filtering mechanism where we can sort by hierarchy, activity, most recent commit, and others would be absolution that makes everyone happy. I wonder how feasible that is.
And again, I have to defend you against this rambling attack... This was a blog post, not a book submitted for publishing, not a thesis paper, not scientific research - it was a personal blog and you've got your own writing style like all of us do. You stated a position, gave examples, supported your arguments and I'd say that maybe you could have gotten to certain points sooner or maybe not. It doesn't matter. If some people can't be bothered to read a little bit then they can just move on to another post and not bother to go around insulting people who are just sharing a thought. Don't take shit from people, man.
I don't know the project, but I was totally lost when I read the commit messages in the pull request. Samples:
I fixed something
class custer method
much much better
no such thing as an error here.
I know Zac is doing some pretty cool stuff, but this seems like dumping code, i.e. looks careless to me.
For me the GitHub network graph is invaluable when it comes to assessing forks activity and their potential usefulness. Very often my first action after coming across a fork is to navigate to the parent repository, but the very second one is clicking on "show me the fork graph".
The network graph, while still having it's flaws, is a tremendous advantage over Bitbucket and provides some overview on where currently the development is happening and what people are working on.
I want them to fork and "pull request", but it seems they can just push back into my master at will.
Maybe I'm looking at it the wrong way.
Edit: My bad.. n/m
I forked HTML5 Boilerplate and created my own custom boilerplate plus CSS framework from it. While I want people to use it and think its valuable I must admit that my humble little project is not half as good as the original it was forked from. I'd want people to know that my fork is a descendant of the original and be informed before deciding to use mine. That's why I deleted my fork and just created a new repo (though I do make sure I let people know what the basis for it was).
Does that make sense? Would a lot of people agree this isn't a flaw but just a matter of personal preference? I've only been using version control (Git is the only system I've tried) for about 4 months or so, so maybe my view is flawed due to lack of experience or proficiency.
On a side note, I noticed a lot of grammatical errors that really really bugged me. I hate to nitpick but I can't help myself. I hope the author corrects his use of "then" instead of "than" and the incorrect usage of "very" where it should read "vary" especially. Not trying to be a dick, just wanna be helpful.
Edit: fixed https://github.com/zbowling/zbowling.github.com/commit/84ece...