5 ms·

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/Doo

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- 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 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 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://www.iodoom3.org/ (http://news.ycombinator.com/item?id=3277150 http://news.ycombinator.com/item?id=3277150) (https://github.com/TimeDoctor/iodoom3 https://github.com/TimeDoctor/iodoom3)

timdorr 15y ago
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
- albertzeyer 15y ago
  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.
  - uxp 15y ago
    Here's the original repo with Fabien Sanglard's patch applied on top of it. https://github.com/uxp/doom3.gpl 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.
lloeki 15y ago
> 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.
- zbowling 15y ago
  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/ http://zbowling.github.com/blog/2011/11/25/github/
  - lloeki 15y ago
    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 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?")
deleted 15y ago
[deleted]

timdorr 15y ago

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

albertzeyer 15y ago
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.
- uxp 15y ago
  Here's the original repo with Fabien Sanglard's patch applied on top of it. https://github.com/uxp/doom3.gpl 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.

lloeki 15y ago

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

zbowling 15y ago
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/ http://zbowling.github.com/blog/2011/11/25/github/
- lloeki 15y ago
  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 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?")

deleted 15y ago

[deleted]