6 ms·

GitHub forking has one big flaw

207 points by bpierre 15y ago

xerxes2001 15y ago
"Not all forks are equal and no one repo is necessarily any more important than any other (including the original repo)." 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!?
- masklinn 15y ago
  > 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). That's TFA's whole point...
k33n 15y ago
What's with people declaring things they don't like, or could be improved as "broken"? GitHub's forking is not "horribly broken". I like the ideas in this article, but they are just that: ideas.
- endgame 15y ago
  Hyperbole pulls clicks.
- bryanlarsen 15y ago
  Maybe github is not "horribly broken", but there are a lot of broken projects on github with the problem he describes.
jarjoura 15y ago
I most definitely want to see the parent repository. It is extremely valuable. Especially when I come across a repository that hasn't been updated in a couple years and by clicking on the parent I can see that the fork was just there for some short-lived reason. 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.
- bryanlarsen 15y ago
  But what if it's the parent repository that hasn't been updated for a couple of years? I've run across this scenario many times.
- dedward 15y ago
  Consider before github's neato fork network view..... Oss projects still had branches and forks and experiments all over the world privately and publicly.... Github just makes it easier, and keeps improving.
joevandyk 15y ago
You can use repository labels on Github. Here is a "root" repository with a note saying to use another one: https://github.com/rails/dynamic_form https://github.com/rails/dynamic_form https://img.skitch.com/20111126-daej32y71sjau9sm3a5t356gac.png https://img.skitch.com/20111126-daej32y71sjau9sm3a5t356gac.p...
- bryanlarsen 15y ago
  That's part of the solution, but labels aren't ubiquitous: https://github.com/rails/dynamic_form/network/members https://github.com/rails/dynamic_form/network/members
mise 15y ago
With regards to people forking a private repo, I'm still not not sure how to work with "collaborators". 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.
- tux1968 15y ago
  From your description it sounds like you're talking about self-hosted repo's not Github. For that you have a couple of options, you can use a gatekeeper such as Gitosis and assign permissions. Or, simply have people pull through a read only mechanism (like git daemon) rather than giving them ssh or other writeable access. Edit: My bad.. n/m
- grncdr 15y ago
  That's what "collaborator" means in Github parlance. If you don't want people to have this permission, don't make them collaborators. If you want people to be collaborators but work mostly on their own fork and send pull requests, ask them.
billpatrianakos 15y ago
I disagree but think this is all a matter of personal preference. There's a choice to be made here. Usually the original project is updated more often and is more useful to the most people. That's generally speaking, of course. A lot of forks are for niche situations or for experimenting like the author says. I much prefer to know the hierarchy of a project and it's forks rather than just seeing a list of forks and not knowing which is the original. Plus, you can use repo labels on GitHub. 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.
- zbowling 15y ago
  Sorry. I didn't expect this to be trending on HackerNews or I would of done another pass over it for grammar. Edit: fixed https://github.com/zbowling/zbowling.github.com/commit/84ece6f3e0262db11e835a85fccb8358214d9289 https://github.com/zbowling/zbowling.github.com/commit/84ece...
  - ionfish 15y ago
    "Would have". :)
    - zbowling 15y ago
      I'm just going to say that I was trolling instead of admit that I made another mistake.
ricardobeat 15y ago
just add a note to the Readme pointing to the new fork that took over?
- zbowling 15y ago
  I thought the same thing. You can switch the "root" if you coordinate with the root repo owner and GitHub support. Often those projects are dead or the maintainer doesn't respond.
nigma 15y ago
I agree that more efforts should be put into making forks purpose and activity more visible and comparable. 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.
justin_vanw 15y ago
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, 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).
- zmanji 15y ago
  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.
  - justin_vanw 15y ago
    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).
- zbowling 15y ago
  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.
46Bit 15y ago
This is git. The point is that it's decentralised.
ryanbraganza 15y ago
I'm impressed that this blogpost wasn't titled "GitHub has one big forking flaw". That aside, I think github's model is largely correct. In git itself, a commit is a child of a parent (or parents).
damncabbage 15y ago
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.)
- zbowling 15y ago
  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.
namidark 15y ago
I disagree with this post entirely. When looking at forks on Github its very easy to tell if someone has done anything meaningful by looking at the network graph and viewing commit messages (of course this is assuming they used sane messages in the first place)
- zbowling 15y ago
  entirely?
fijal 15y ago
For what is worth, the "Before git and mercurial, merging was a nightmare in most monolithic source control systems" seems like a heavy misconception for me. How many people actually tried? The pypy project was using heavy branching and merging on svn and it worked just fine. The only "drawback" was that everyone had to have commit rights to the main repo. I say "drawback" because liberal policies to giving commit rights never ended up badly. Actually newcomers with commit rights are always more careful than old contributors.
darklajid 15y ago
Related to the article, although not directly to the main point ("Should GH bless the root of project forks"): So - I looked at the pull request that was linked to as 'couldn't get our fixes upstream'. 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 small change' better idea class custer method much much better no such thing as an error here. In the end upstream was lost as well, which might or might not be related to patch size and - erm - a little mess? I know Zac is doing some pretty cool stuff, but this seems like dumping code, i.e. looks careless to me.
- zbowling 15y ago
  Yes, this is my biggest issue. I don't squash my commits like I should but this comes from our company repo and just gets imported. I tend to look at the last commit and just compare diffs for feature branch.
  - deleted 15y ago
    [deleted]

207 points by bpierre 15y ago

xerxes2001 15y ago

"Not all forks are equal and no one repo is necessarily any more important than any other (including the original repo)." 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!?

masklinn 15y ago
> 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). That's TFA's whole point...

k33n 15y ago

What's with people declaring things they don't like, or could be improved as "broken"? GitHub's forking is not "horribly broken". I like the ideas in this article, but they are just that: ideas.

endgame 15y ago
Hyperbole pulls clicks.
bryanlarsen 15y ago
Maybe github is not "horribly broken", but there are a lot of broken projects on github with the problem he describes.

jarjoura 15y ago

I most definitely want to see the parent repository. It is extremely valuable. Especially when I come across a repository that hasn't been updated in a couple years and by clicking on the parent I can see that the fork was just there for some short-lived reason. 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.

bryanlarsen 15y ago
But what if it's the parent repository that hasn't been updated for a couple of years? I've run across this scenario many times.
dedward 15y ago
Consider before github's neato fork network view..... Oss projects still had branches and forks and experiments all over the world privately and publicly.... Github just makes it easier, and keeps improving.

joevandyk 15y ago

You can use repository labels on Github. Here is a "root" repository with a note saying to use another one: https://github.com/rails/dynamic_form https://github.com/rails/dynamic_form https://img.skitch.com/20111126-daej32y71sjau9sm3a5t356gac.png https://img.skitch.com/20111126-daej32y71sjau9sm3a5t356gac.p...

bryanlarsen 15y ago
That's part of the solution, but labels aren't ubiquitous: https://github.com/rails/dynamic_form/network/members https://github.com/rails/dynamic_form/network/members

mise 15y ago

With regards to people forking a private repo, I'm still not not sure how to work with "collaborators". 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.

tux1968 15y ago
From your description it sounds like you're talking about self-hosted repo's not Github. For that you have a couple of options, you can use a gatekeeper such as Gitosis and assign permissions. Or, simply have people pull through a read only mechanism (like git daemon) rather than giving them ssh or other writeable access. Edit: My bad.. n/m
grncdr 15y ago
That's what "collaborator" means in Github parlance. If you don't want people to have this permission, don't make them collaborators. If you want people to be collaborators but work mostly on their own fork and send pull requests, ask them.

billpatrianakos 15y ago

I disagree but think this is all a matter of personal preference. There's a choice to be made here. Usually the original project is updated more often and is more useful to the most people. That's generally speaking, of course. A lot of forks are for niche situations or for experimenting like the author says. I much prefer to know the hierarchy of a project and it's forks rather than just seeing a list of forks and not knowing which is the original. Plus, you can use repo labels on GitHub. 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.

zbowling 15y ago
Sorry. I didn't expect this to be trending on HackerNews or I would of done another pass over it for grammar. Edit: fixed https://github.com/zbowling/zbowling.github.com/commit/84ece6f3e0262db11e835a85fccb8358214d9289 https://github.com/zbowling/zbowling.github.com/commit/84ece...
- ionfish 15y ago
  "Would have". :)
  - zbowling 15y ago
    I'm just going to say that I was trolling instead of admit that I made another mistake.

ricardobeat 15y ago

just add a note to the Readme pointing to the new fork that took over?

zbowling 15y ago
I thought the same thing. You can switch the "root" if you coordinate with the root repo owner and GitHub support. Often those projects are dead or the maintainer doesn't respond.

nigma 15y ago

I agree that more efforts should be put into making forks purpose and activity more visible and comparable. 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.

justin_vanw 15y ago

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

zmanji 15y ago
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.
- justin_vanw 15y ago
  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).
zbowling 15y ago
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.

46Bit 15y ago

This is git. The point is that it's decentralised.

ryanbraganza 15y ago

I'm impressed that this blogpost wasn't titled "GitHub has one big forking flaw". That aside, I think github's model is largely correct. In git itself, a commit is a child of a parent (or parents).

damncabbage 15y ago

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

zbowling 15y ago
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.

namidark 15y ago

I disagree with this post entirely. When looking at forks on Github its very easy to tell if someone has done anything meaningful by looking at the network graph and viewing commit messages (of course this is assuming they used sane messages in the first place)

zbowling 15y ago
entirely?

fijal 15y ago

For what is worth, the "Before git and mercurial, merging was a nightmare in most monolithic source control systems" seems like a heavy misconception for me. How many people actually tried? The pypy project was using heavy branching and merging on svn and it worked just fine. The only "drawback" was that everyone had to have commit rights to the main repo. I say "drawback" because liberal policies to giving commit rights never ended up badly. Actually newcomers with commit rights are always more careful than old contributors.

darklajid 15y ago

Related to the article, although not directly to the main point ("Should GH bless the root of project forks"): So - I looked at the pull request that was linked to as 'couldn't get our fixes upstream'. 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 small change' better idea class custer method much much better no such thing as an error here. In the end upstream was lost as well, which might or might not be related to patch size and - erm - a little mess? I know Zac is doing some pretty cool stuff, but this seems like dumping code, i.e. looks careless to me.

zbowling 15y ago
Yes, this is my biggest issue. I don't squash my commits like I should but this comes from our company repo and just gets imported. I tend to look at the last commit and just compare diffs for feature branch.
- deleted 15y ago
  [deleted]