4 ms·

I do enjoy and agree with the pedantry of your point, but it's difficult to accept that, like many people, they _are_ moving to GitHub, and not Git. GitHub is

by zbuf 6y ago

I do enjoy and agree with the pedantry of your point, but it's difficult to accept that, like many people, they _are_ moving to GitHub, and not Git. GitHub is as much a tool here as Git itself. Unfortunate really, as Git should be the panacea of distributed systems, open source. Instead we took that, centralised it all on a single big host, and became dependent on its proprietary features. Still, these systems come and go. Remember SourceForge anyone? But what probably differs today is that these modern services seem so much more complex they have an increasing gravity/lock in effect.

bad_user 6y ago
You can easily mirror your repository on Gitlab or elsewhere and Gitlab even automates that for you. And all developers on a project have a backup on their local computer. It might not track the master/main HEAD from Github, but in the event of a disaster you still have backups to recover from. The nature of git's descentralized nature is misunderstood and I fear the misunderstanding comes from people that did not work with CVS/Subversion. In any case you still need a source of truth from which releases are cut. And Github has been damned convenient to use as one and you can easily take your git repo and move elsewhere if you want to. Sure, you can't migrate the links, the project's stars, etc, but that's not part of git. On the bright side, given you can mirror the code, you can keep the Github repo as read-only, which afaik is what the Linux kernel has done.
- asddubs 6y ago
  can gitlab migrate issues? I know github allows you to export them via the API without too much difficulty, but there isn't too many tools that allow you to manage them once you've done that, from what I've found. there's some abandoned viewer projects, but that's not actually a replacement if you want to keep working on the project
  - Nullabillity 6y ago
    Yes, GitLab's migration tool imports both issues and PRs.
    - richardwhiuk 6y ago
      It loses a lot of metadata in the process.
      - brodock 6y ago
        can you point a few examples? If there is data missing (that can be retrieved via their API) it's something we want to fix for sure.
        richardwhiuk 6y ago
        It doesn't matter if it can be retrieved by the API or not from a user's perspective. Merge requests and comments are no longer authored by the correct user, because there's no user mapping - everything ends up getting authored by the user who performed the import. Inline review comments on MRs appear to be lost or mangled. Review summary comments on MRs appear to be lost or mangled. Dates on MRs are lost. Dates on comments are lost.
- zbuf 6y ago
  Don't worry, I do understand Git, and I think you've completely missed the point I was making and thus fallen for the exact trap that I'm pointing out :) The huge importance of all that data "that's not part of Git", and the workflow and skill set around it. Add to that a growing body of developers who don't actually know Git, but do know how to press the button in GitHub. I don't make any claim for the particular JDK project here, but people _are_ migrating to GitHub, not Git.
nemetroid 6y ago
I agree, but I think the article should have used ”self-hosted Mercurial” once, to clarify.
- giomasce 6y ago
  Yes, as the GP this is my original point. I completely agree that they are moving to GitHub. I don't think there are referentially false sentences in the OP, it's more a remark about the language (which is not a secondary aspect).
pizza234 6y ago
It's not a pedantic point. Since the relationship between the references is wrong (SCM <> hosting service), one can't do an analysis. Putting it in those terms, questions like the storage requirements of an SCM can't be answered (because GH is a hosting service) and usability of a hosting service can't be answered either (because Mercurial is an SCM). Ultimately, it doesn't allow the fundamental question to be answered - was it a matter of SCM, of hosting service, or both? As a matter of fact, the article is imprecise/confusing, as it partly mixes issues that were originally separate (although later it expands on this). See the two separate JEPs: - [JEP 357: Migrate from Mercurial to Git](https://openjdk.java.net/jeps/357 https://openjdk.java.net/jeps/357) - [JEP 369: Migrate to GitHub](https://openjdk.java.net/jeps/369 https://openjdk.java.net/jeps/369) Based on a quick reading, the main driver has been the SCM.
- spareaccnt1024 6y ago
  What's wrong with you people downvoting answers that merely give an opposing view in a non-condescending way. Jeez, this site should remove those buttons.
- zbuf 6y ago
  I should have put a smiley face on the pedantry comment... I get what you're saying, and if this project in question just wants a "hosting service" and to never touch any of its features, then ok. But the broader point is that these are not hosting services; they're full-on toolsets and workflows that people are migrating to (or towards, in this case).

by zbuf 6y ago

bad_user 6y ago

You can easily mirror your repository on Gitlab or elsewhere and Gitlab even automates that for you. And all developers on a project have a backup on their local computer. It might not track the master/main HEAD from Github, but in the event of a disaster you still have backups to recover from. The nature of git's descentralized nature is misunderstood and I fear the misunderstanding comes from people that did not work with CVS/Subversion. In any case you still need a source of truth from which releases are cut. And Github has been damned convenient to use as one and you can easily take your git repo and move elsewhere if you want to. Sure, you can't migrate the links, the project's stars, etc, but that's not part of git. On the bright side, given you can mirror the code, you can keep the Github repo as read-only, which afaik is what the Linux kernel has done.

asddubs 6y ago
can gitlab migrate issues? I know github allows you to export them via the API without too much difficulty, but there isn't too many tools that allow you to manage them once you've done that, from what I've found. there's some abandoned viewer projects, but that's not actually a replacement if you want to keep working on the project
- Nullabillity 6y ago
  Yes, GitLab's migration tool imports both issues and PRs.
  - richardwhiuk 6y ago
    It loses a lot of metadata in the process.
    - brodock 6y ago
      can you point a few examples? If there is data missing (that can be retrieved via their API) it's something we want to fix for sure.
      - richardwhiuk 6y ago
        It doesn't matter if it can be retrieved by the API or not from a user's perspective. Merge requests and comments are no longer authored by the correct user, because there's no user mapping - everything ends up getting authored by the user who performed the import. Inline review comments on MRs appear to be lost or mangled. Review summary comments on MRs appear to be lost or mangled. Dates on MRs are lost. Dates on comments are lost.
zbuf 6y ago
Don't worry, I do understand Git, and I think you've completely missed the point I was making and thus fallen for the exact trap that I'm pointing out :) The huge importance of all that data "that's not part of Git", and the workflow and skill set around it. Add to that a growing body of developers who don't actually know Git, but do know how to press the button in GitHub. I don't make any claim for the particular JDK project here, but people _are_ migrating to GitHub, not Git.

nemetroid 6y ago

I agree, but I think the article should have used ”self-hosted Mercurial” once, to clarify.

giomasce 6y ago
Yes, as the GP this is my original point. I completely agree that they are moving to GitHub. I don't think there are referentially false sentences in the OP, it's more a remark about the language (which is not a secondary aspect).

pizza234 6y ago

It's not a pedantic point. Since the relationship between the references is wrong (SCM <> hosting service), one can't do an analysis. Putting it in those terms, questions like the storage requirements of an SCM can't be answered (because GH is a hosting service) and usability of a hosting service can't be answered either (because Mercurial is an SCM). Ultimately, it doesn't allow the fundamental question to be answered - was it a matter of SCM, of hosting service, or both? As a matter of fact, the article is imprecise/confusing, as it partly mixes issues that were originally separate (although later it expands on this). See the two separate JEPs: - [JEP 357: Migrate from Mercurial to Git](https://openjdk.java.net/jeps/357 https://openjdk.java.net/jeps/357) - [JEP 369: Migrate to GitHub](https://openjdk.java.net/jeps/369 https://openjdk.java.net/jeps/369) Based on a quick reading, the main driver has been the SCM.

spareaccnt1024 6y ago
What's wrong with you people downvoting answers that merely give an opposing view in a non-condescending way. Jeez, this site should remove those buttons.
zbuf 6y ago
I should have put a smiley face on the pedantry comment... I get what you're saying, and if this project in question just wants a "hosting service" and to never touch any of its features, then ok. But the broader point is that these are not hosting services; they're full-on toolsets and workflows that people are migrating to (or towards, in this case).