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

21–30 of 49 posts

Re: GitHub forking has one big flaw

#21

Post by zmanji »

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…

HN does have sub-domain support if the link is posterous or a few other sites. I don't know why it is not enabled for all links though.

Re: GitHub forking has one big flaw

#22

Post by zbowling »

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

Re: GitHub forking has one big flaw

#23

Post by justin_vanw »

zmanji wrote: post #21
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…

HN does have sub-domain support if the link is posterous or a few other sites. I don't know why it is not enabled for all links though.

PG: Make the decision on what sites to show subdomains on at page render time, based on a flat file list of domains. Have a job run every now and then that checks submitted urls, and creates the flat file list of domains, including any domain with more than N different subdomains submitted, where N is high (maybe 400 different sub domains or something). If this file would be large, just build it based on the last M submitted urls (nobody will be browsing the older ones anyway, so if a domain comes and goes oh well).

Re: GitHub forking has one big flaw

#28

Post by soult »

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

Re: GitHub forking has one big flaw

#29

Post by justin_vanw »

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…

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.

Re: GitHub forking has one big flaw

#30

Post by damncabbage » 

  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 
  on pages.
My misgivings with the "root repo" aspect of this post aside, this suggestion is great; I'd really love to see this picked up by the GitHub guys.

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

Post reply on HN