4 ms·

I'm sorry, but I don't believe I was rambling. There is a flaw in the approach that they are taking. I made this clear several times by pointing out Linus's tal

I'm sorry, but I don't believe I was rambling. There is a flaw in the approach that they are taking. I made this clear several times by pointing out Linus's talk and the background of forking on Git. 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.

soult 15y ago
I could not agree more. 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.
- joevandyk 15y ago
  Look at the Network activity. It shows you the level and dates of commits of all the forked repositories.
  - bryanlarsen 15y ago
    This doesn't always help as much as you would think it should. Often times I've seen a fork with a lot of recent commits, but it's actually a bunch of pseudo-private changes against an old version.
- georgebashi 15y ago
  I find GitPop to be really useful for finding the most popular fork. It shows you the number of watchers, forks and issues for each fork, which makes spotting the "best" one a lot easier. It even has a handy bookmarklet! http://gitpop.heroku.com/ http://gitpop.heroku.com/
- billpatrianakos 15y ago
  In cases where you've moved on and someone else is taking over as a fork, can't you just delete your repo and have the entire hierarchy just shift? I'm honestly asking because I've deleted a ton of repos but none that have been forked so I'm curious.
justin_vanw 15y ago
Well, in my opinion it is rambling. You say there is one big problem, but then your 'problem' isn't clearly a problem. 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.
- zbowling 15y ago
  Not all forks are equal, but GitHub shouldn't treat them differently regardless if they are they are the original fork or not. 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.)
  - billpatrianakos 15y ago
    I think GitHub should treat them differently. Maybe you and I are browsing projects that see completely opposite patterns of creation, forking, and upkeep. I said somewhere here before that the original is usually the best, most reliable, and useful to more people than most others. When I see a list of forks I do browse a few but always end up at the master and the master is usually the best one for me. 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.
billpatrianakos 15y ago
I didn't consider it rambling. Honestly, I feel it's a matter of taste rather than a flaw and I happen to disagree with you. I can't tell you you're right but I also can't say you're wrong. I think Bitabucket and GitHub just have different perspectives on it. GitHub and I seem to agree on the forking issue but that's a coincidence. 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.
- zbowling 15y ago
  Thanks! Very kind words. The one case I didn't link but talked about was my co-worker Michael's snipmate.vim project. https://github.com/msanders/snipmate.vim https://github.com/msanders/snipmate.vim 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 https://github.com/garbas/vim-snipmate
  - billpatrianakos 15y ago
    Couldn't he have given someone permission to take over the original repo via pull requests? I was working on a ruby web app with a guy from Italy and the project is dead but I gave him access to the repo and now he can commit and push all he likes until I get the time to work on it again. Would that work for your friend? Maybe he could appoint someone to take charge of that particular repo and keep the original project alive without giving him access to the whole account. 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.

soult 15y ago

I could not agree more. 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.

joevandyk 15y ago
Look at the Network activity. It shows you the level and dates of commits of all the forked repositories.
- bryanlarsen 15y ago
  This doesn't always help as much as you would think it should. Often times I've seen a fork with a lot of recent commits, but it's actually a bunch of pseudo-private changes against an old version.
georgebashi 15y ago
I find GitPop to be really useful for finding the most popular fork. It shows you the number of watchers, forks and issues for each fork, which makes spotting the "best" one a lot easier. It even has a handy bookmarklet! http://gitpop.heroku.com/ http://gitpop.heroku.com/
billpatrianakos 15y ago
In cases where you've moved on and someone else is taking over as a fork, can't you just delete your repo and have the entire hierarchy just shift? I'm honestly asking because I've deleted a ton of repos but none that have been forked so I'm curious.

justin_vanw 15y ago

Well, in my opinion it is rambling. You say there is one big problem, but then your 'problem' isn't clearly a problem. 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.

zbowling 15y ago
Not all forks are equal, but GitHub shouldn't treat them differently regardless if they are they are the original fork or not. 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.)
- billpatrianakos 15y ago
  I think GitHub should treat them differently. Maybe you and I are browsing projects that see completely opposite patterns of creation, forking, and upkeep. I said somewhere here before that the original is usually the best, most reliable, and useful to more people than most others. When I see a list of forks I do browse a few but always end up at the master and the master is usually the best one for me. 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.

billpatrianakos 15y ago

I didn't consider it rambling. Honestly, I feel it's a matter of taste rather than a flaw and I happen to disagree with you. I can't tell you you're right but I also can't say you're wrong. I think Bitabucket and GitHub just have different perspectives on it. GitHub and I seem to agree on the forking issue but that's a coincidence. 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.

zbowling 15y ago
Thanks! Very kind words. The one case I didn't link but talked about was my co-worker Michael's snipmate.vim project. https://github.com/msanders/snipmate.vim https://github.com/msanders/snipmate.vim 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 https://github.com/garbas/vim-snipmate
- billpatrianakos 15y ago
  Couldn't he have given someone permission to take over the original repo via pull requests? I was working on a ruby web app with a guy from Italy and the project is dead but I gave him access to the repo and now he can commit and push all he likes until I get the time to work on it again. Would that work for your friend? Maybe he could appoint someone to take charge of that particular repo and keep the original project alive without giving him access to the whole account. 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.