Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitHub forking has one big flaw

zbowling.github.com

Post reply on HN
Print view View original

31–40 of 49 posts

Re: GitHub forking has one big flaw

#31

Post by zbowling »

damncabbage wrote: post #30

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…

Exactly. Branches do this already (they hide if they can be fast-forwarded). If you can fast-forward merge a fork into the local one, it should be hidden when I viewing the network page, just like local branches.

The network graph they render already does this to some extent.

Re: GitHub forking has one big flaw

#32

Post by joevandyk »

soult wrote: post #28
zbowling wrote: post #22

Earlier quoted context omitted.

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 th…

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…

Look at the Network activity. It shows you the level and dates of commits of all the forked repositories.

Re: GitHub forking has one big flaw

#33

Post by billpatrianakos »

zbowling wrote: post #22
justin_vanw wrote: post #20

Rarely has one blog post complained for so long about something that matters so little. 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, o…

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 th…

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.

Re: GitHub forking has one big flaw

#34

Post by zbowling »

justin_vanw wrote: post #29
zbowling wrote: post #22

Earlier quoted context omitted.

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 th…

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…

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

Re: GitHub forking has one big flaw

#35

Post by zbowling »

billpatrianakos wrote: post #33
zbowling wrote: post #22

Earlier quoted context omitted.

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 th…

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…

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

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

Re: GitHub forking has one big flaw

#36

Post by georgebashi »

soult wrote: post #28
zbowling wrote: post #22

Earlier quoted context omitted.

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 th…

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…

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/

Re: GitHub forking has one big flaw

#37

Post by billpatrianakos »

zbowling wrote: post #35
billpatrianakos wrote: post #33

Earlier quoted context omitted.

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…

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 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…

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.

Re: GitHub forking has one big flaw

#38

Post by sant0sk1 »

justin_vanw wrote: post #20

Rarely has one blog post complained for so long about something that matters so little. 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, o…

wrt subdomains: they're actually in the page source, but not shown. This makes it trivial to enable them via JS. Here's an example using dotjs, but it'd be just as easy via Greasemonkey or otherwise:

https://github.com/sant0sk1/dotfiles/blob/master/js/news.yco...

Re: GitHub forking has one big flaw

#39

Post by bryanlarsen »

joevandyk wrote: post #32
soult wrote: post #28

Earlier quoted context omitted.

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…

Look at the Network activity. It shows you the level and dates of commits of all the forked repositories.

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.

Re: GitHub forking has one big flaw

#40

Post by bostonvaulter2 »

zbowling wrote: post #35
billpatrianakos wrote: post #33

Earlier quoted context omitted.

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…

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 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…

Git Pop looks like it can help you see garbas' repo. It trimmed the list of repos from 335 to 7.

http://gitpop.heroku.com/?url=https://github.com/msanders/sn...

Although I agree that something like this should be built into Github.

Post reply on HN