Hacker News Reader

Comment by albertzeyer | Hacker News Reader

Why not just get these changes upstream?

Also, instead of forking it on GitHub, he just reuploaded the whole thing again (https://github.com/fabiensanglard/Doom3-for-MacOSX-) so that others cannot easily merge these changes. And neither in his repo nor in his post, there is a reference to the original repo (https://github.com/TTimo/doom3.gpl).

Also, on the original repo, there were already a few fixes for Xcode4 and there is also a pull request with further fixes (https://github.com/TTimo/doom3.gpl/pull/13). I haven't checked it myself but it might actually work already.

Btw., further development is probably going on here: http://www.iodoom3.org/ (http://news.ycombinator.com/item?id=3277150) (https://github.com/TimeDoctor/iodoom3)

View on HN

> Also, instead of forking it on GitHub, he just reuploaded the whole thing again

He responded in his comments:

> If not, the fork will remain buried as a Pull Request with no visibility at all.

Which is loads of bullshit. By design git is decentralized so upstream is a mere convention, where usually the closest to upstream is either the original author's repository or the most active repository.

I was actually writing a blog post on this issue as we speak. GitHub's approach is broken to how they handle forks. It's a long post but I updated it to mention your comment here.

http://zbowling.github.com/blog/2011/11/25/github/

A fork is a mere 'git clone'. The brilliance and simplicity of SHA1s makes linking repos as trivial as a git remote add. I venture it would be quite costly to actively look at every commit of a new repo to match it with every other commit in every other github repo (unless they start maintaining a global index of all SHA1s->repos). So for now Github merely records that one cloned a repo, and I seriously won't blame them for that.

If the guy did things properly, although inconvenient we could just do that to merge back, but apparently what he did was rewrite or recreate history in some way, so that SHA1s changed so it's not even possible to add remote[0]. I guess that even with no common ancestor SHA1s one could still use rebase --onto to replay some part of his history.

Either way I can't tell because the repo is 404 now and I did not have a chance to browse it, let alone clone it.

[0] http://news.ycombinator.com/item?id=3277181

PS: I like some of your ideas, like hiding forks that can be fast-forwarded (i.e they have no changes i.e their HEADs are members of the parent repo), and detecting that one has pushed a repo that is obviously a clone of another, although I'd rather have it be manual (like a message on the github's console saying "we detected that this repo could be a clone of that repo, do you want to mark it as a fork?")

They can easily merge those changes. You just have to use the git command line. It's possible to merge in a separate repo. Like so:

  git remote add d3mac https://github.com/fabiensanglard/Doom3-for-MacOSX-.git
  git fetch d3mac
  git merge d3mac/master

No, you cannot do that easily the way you described:

    $ git fetch d3mac
    warning: no common commits
    $ git merge d3mac/master
    [ many many conflicts ... ]
    CONFLICT (add/add): Merge conflict in neo/ui/Winvar.h
    Automatic merge failed; fix conflicts and then commit the result.

Here's the original repo with Fabien Sanglard's patch applied on top of it.

https://github.com/uxp/doom3.gpl

Just like his concern, I haven't tested building this on windows (VC 2010), so this repo needs to be cleaned up before it should be merged back into the main repo.

Reply on news.ycombinator.com