
GitHub forking has one big flaw - bpierre
http://zbowling.github.com/blog/2011/11/25/github/
======
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.)

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

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

~~~
bryanlarsen
Maybe github is not "horribly broken", but there are a lot of broken projects
on github with the problem he describes.

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

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

------
joevandyk
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://img.skitch.com/20111126-daej32y71sjau9sm3a5t356gac.p...](https://img.skitch.com/20111126-daej32y71sjau9sm3a5t356gac.png)

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

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

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

~~~
zbowling
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
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
Look at the Network activity. It shows you the level and dates of commits of
all the forked repositories.

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

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

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

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

------
namidark
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
entirely?

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

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

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

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

------
billpatrianakos
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
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/84ece...](https://github.com/zbowling/zbowling.github.com/commit/84ece6f3e0262db11e835a85fccb8358214d9289)

~~~
ionfish
"Would have". :)

~~~
zbowling
I'm just going to say that I was trolling instead of admit that I made another
mistake.

~~~
botj
"admitting" :).

------
46Bit
This is git. The point is that it's decentralised.

