GitHub forking has one big flaw • Hacker News Board

Re: GitHub forking has one big flaw

#41

Post by billpatrianakos » Sun, Nov 27, 2011, 2:41 AM UTC

zbowling wrote: post #34

justin_vanw wrote: post #29

Earlier quoted context omitted.

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

I think GitHub should treat them differently. Maybe you and I are browsing projects that see completely opposite patterns of creation, forking, and upkeep. I said somewhere here before that the original is usually the best, most reliable, and useful to more people than most others. When I see a list of forks I do browse a few but always end up at the master and the master is usually the best one for me.

If I had to pick one day to do things I'd keep them as is. But having some sort of filtering mechanism where we can sort by hierarchy, activity, most recent commit, and others would be absolution that makes everyone happy. I wonder how feasible that is.

And again, I have to defend you against this rambling attack... This was a blog post, not a book submitted for publishing, not a thesis paper, not scientific research - it was a personal blog and you've got your own writing style like all of us do. You stated a position, gave examples, supported your arguments and I'd say that maybe you could have gotten to certain points sooner or maybe not. It doesn't matter. If some people can't be bothered to read a little bit then they can just move on to another post and not bother to go around insulting people who are just sharing a thought. Don't take shit from people, man.

Re: GitHub forking has one big flaw

#42

Post by billpatrianakos » Sun, Nov 27, 2011, 2:44 AM UTC

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…

In cases where you've moved on and someone else is taking over as a fork, can't you just delete your repo and have the entire hierarchy just shift? I'm honestly asking because I've deleted a ton of repos but none that have been forked so I'm curious.

Re: GitHub forking has one big flaw

#43

Post by namidark » Sun, Nov 27, 2011, 4:19 AM UTC

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)

Re: GitHub forking has one big flaw

#44

Post by zbowling » Sun, Nov 27, 2011, 6:34 AM UTC

namidark wrote: post #43

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)

entirely?

Re: GitHub forking has one big flaw

#45

Post by dedward » Sun, Nov 27, 2011, 6:59 AM UTC

jarjoura wrote: post #4

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

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.

Re: GitHub forking has one big flaw

#46

Post by fijal » Sun, Nov 27, 2011, 9:38 AM UTC

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.

Re: GitHub forking has one big flaw

#47

Post by darklajid » Sun, Nov 27, 2011, 1:54 PM UTC

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.

Re: GitHub forking has one big flaw

#48

Post by zbowling » Sun, Nov 27, 2011, 6:31 PM UTC

darklajid wrote: post #47

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…

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.

Re: GitHub forking has one big flaw

#49

Post by [deleted] » Mon, Nov 28, 2011, 2:22 AM UTC

zbowling wrote: post #48

darklajid wrote: post #47

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…

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]