Live data from Hacker News

GitHub forking has one big flaw

zbowling.github.com

11–20 of 49 posts

Re: GitHub forking has one big flaw

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

Re: GitHub forking has one big flaw

#12
post #9

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.

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

Re: GitHub forking has one big flaw

#13

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

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

Re: GitHub forking has one big flaw

#14

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

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

Re: GitHub forking has one big flaw

#15

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

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

Re: GitHub forking has one big flaw

#16

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

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

"Would have". :)

Re: GitHub forking has one big flaw

#17
post #16

Earlier quoted context omitted.

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

"Would have". :)

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

Re: GitHub forking has one big flaw

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

Re: GitHub forking has one big flaw

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

Post reply on HN