6 ms·

It bothers me that they repeatedly write about a migration "from Mercurial to GitHub", rather than "from Mercurial to Git". It seems to imply that GitHub hostin

It bothers me that they repeatedly write about a migration "from Mercurial to GitHub", rather than "from Mercurial to Git". It seems to imply that GitHub hosting is the only way to run Git. It's perfectly fine to say that they are moving to GitHub hosting, but not to put it on the same level as Mercurial: Mercurial and Git are applications/protocols, while GitHub is a hosting service. You should compare application with application and hosting service with hosting service.

suyash 6y ago
Good point, people have largely forgotten the distinction between Git and GitHub.
- Abishek_Muthian 6y ago
  Very true and the search engines are to be blamed as well. Recently, I was searching for a Git - fork project (i.e. a project forked from git itself) which allowed separate machine based accounts for Git branches. It was quite famous, I had used it about 4 years back and I don't remember its name now. Now, this is the worst case scenario for the search engines - • 'git fork project' would bring numerous github forked projects. • 'git original source' would bring the mirror of git in github, but then again there are hundreds of fork. After, lot of time spent on this in vain, I gave up. UPDATE: While writing this comment I remembered the USP of that project was 'Branch specific permissions', so I gave a fresh attempt at finding it and I did via SO! It's Gitolite[1]. [1]https://github.com/sitaramc/gitolite https://github.com/sitaramc/gitolite
  - throwaway8941 6y ago
    Have you tried adding -github to your search queries?
    - Abishek_Muthian 6y ago
      Yep, I tried Github as part of the query. Anyways, even without 'GitHub' almost all front page results are from there and that's one of the point I'm trying to make.
      - webmaven 6y ago
        You can also exclude results from the site completely with -site:github.com, though you're still left with the problem that 'git fork' and variants won't really bring up results that are forks of git, but results that are about forking in git. Ultimately, in this case only recalling the USP or a similarly unique phrase was ever going to help you find the result you were looking for.
  - deleted 6y ago
    [deleted]
pjmlp 6y ago
For most people it is. Just like we can discuss all day about POSIX, UNIX and various implementations of them, while most people would relate to Ubuntu.
- mrpippy 6y ago
  Or even worse, describing an entire Linux binary compatibility layer as "Bash on Ubuntu on Windows", like Microsoft originally did. https://blogs.windows.com/windowsdeveloper/2016/03/30/run-bash-on-ubuntu-on-windows/ https://blogs.windows.com/windowsdeveloper/2016/03/30/run-ba...
  - ChrisSD 6y ago
    I'm not sure what's objectionable about that blog post? It describes a common scenario for using the compatibility layer (and indeed the main motivation for creating it). Especially early on when the compatibility layer was only fully tested with a specific version of Ubuntu.
- andialo 6y ago
  And that's exactly the reason why they should mention they are migrating to git hosted on GitHub in that announcement. It's pretty bothering that most people equate a distributed open-source code versioning system with a centralized Microsoft service, isn't it?
  - pjmlp 6y ago
    Agreed, it also irritates me that people equate Linux with UNIX for example, or developers with Linux workflows for that matter.
- chx 6y ago
  > For most people it is. Excluding the contributors to such small projects as KDE, Gnome, Freedesktop, Debian, Arch Linux, Drupal all of which are self hosting Gitlab.
- bryanrasmussen 6y ago
idclip 6y ago
Its fun for me to say this, but it just goes to show the kind of people behind the project today, i mean, did you see the explosion in versioning ? OJDK/ORACLE duo slowly feeding the hype machine by carefully making moves that all the players look good. You say github, i see a very careful type of microsoft pitch. That all said ... well good on them, its about time.
sradman 6y ago
Project Skara appears to consider this a two step process [1]: > The goal of this Project is to investigate alternative SCM and code review options for the JDK source code, including options based upon Git rather than Mercurial, and including options hosted by third parties. > Two JEPs are planned for this investigation, first JEP 357: Migrate from Mercurial to Git [2] and second JEP 369: Migrate to GitHub. . [3] [1] https://openjdk.java.net/projects/skara/ https://openjdk.java.net/projects/skara/ [2] https://openjdk.java.net/jeps/357 https://openjdk.java.net/jeps/357 [3] https://openjdk.java.net/jeps/369 https://openjdk.java.net/jeps/369
rapnie 6y ago
Yes, this bothers me too. The extra features that Github offers on top of Git are generally referred to as a 'forge' [0]. And talking about forges I hope we will look beyond just Github and consider all of them (gitlab, gitea, sourcehut, gogs, pagure, gitern, etc.) and focus on their interoperability! Just mentioned in another comment, but ForgeFed [1] could be the solution to achieve this, creating a federation of forges where it doesn't matter which software one prefers. [0] https://en.wikipedia.org/wiki/Forge_(software) https://en.wikipedia.org/wiki/Forge_(software) [1] https://forgefed.peers.community https://forgefed.peers.community
gigatexal 6y ago
I get that but I think by saying "Github" instead of "git" one is emphasizing the social and collaborative aspects of Github over plain git. My 2 cents anyway.
- giomasce 6y ago
  That would make it even more wrong, since it seems from the JEPs that, at least for the time being, they're only using GitHub as hosting service. No wikis, PRs, issues and so on.
  - elygre 6y ago
    They will use pull requests, but it is a design goal for the process to be somewhat independent of GitHub. For more detailed information, the OpenJDK mailing lists archive is a good source.
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.
j1elo 6y ago
Well, if they are consciously moving to use the Pull Request, Issue tracker, Actions, Wiki, and other features of GitHub, and incidentally Git as part of the package, then I'd say that yes, they _are_ moving to GitHub, and not just Git. Edit: I was specifically thinking on this main point they mentioned: "Programmatic APIs to enable process assistance and automation of review and processes", which to me means PR and Actions. I was just assuming that they will probably also use the Issues feature too.
akerro 6y ago
OpenJDK said in discussion that they are migrating to GitHub but will try to make their process platform agnostic and not be too attached to GitHub.
krzyk 6y ago
Well, actually there are two JEPs: - Migrate from Mercurial to Git - https://openjdk.java.net/jeps/357 https://openjdk.java.net/jeps/357 - Migrate to GitHub - https://openjdk.java.net/jeps/369 https://openjdk.java.net/jeps/369 And also in JEP 369 at the and there is: > In order to prevent the Skara tooling from depending upon a particular provider's API, support for multiple external providers has been a strict requirement from the beginning. All of the tooling is also required to work with the open-source GitLab Community Edition (GitLab CE).
- WhyNotHugo 6y ago
  I wonder why they didn't pick GitLab though. They just mention it as an alternative, but there's not a single word on why they preferred one over the other.
  - Alupis 6y ago
    Because "Github is where it's at!". They're looking for an instantly-large community with built in support. Everyone has a Github account, but not everyone has a Gitlab account. Yes it's easy to get a Gitlab account for free, but that's still a barrier at the moment.
  - krzyk 6y ago
    They have previously chosen mercurial which didn't won the DVCS battle, so I assume they now bet on a winning horse.
    - WhyNotHugo 6y ago
      Uhm... GitLab also uses Git, not sure what you're talking about.
quicklime 6y ago
I agree. I don't think your point is pedantic, although I think calling GitHub a "hosting service" downplays some major features that GitHub has. For me the big one is code reviews (via pull requests), but it also has GitHub Issues and GitHub Actions, amongst other things. So when someone says they're migrating "from Mercurial to GitHub", I'm left wondering: what were they previously using for code reviews, issue tracking, etc? From the article: > OpenJDK has used the Mercurial source code management solution since 2008 to store source code and conduct code reviews This doesn't make sense. Mercurial doesn't provide a code review feature, and neither does Git. So what do they currently use for code reviews? I had to dig in to the site a bit, but the workflow is described in https://openjdk.java.net/guide/codeReview.html https://openjdk.java.net/guide/codeReview.html. It looks like they use a (Korn!) shell script called "webrev" that will "generate a set of web pages to display the differences", and they then scp over the static html files to a shared public web server. Here's an example I pulled out of their Atom feed: https://cr.openjdk.java.net/~pbansal/8249548/webrev00/ https://cr.openjdk.java.net/~pbansal/8249548/webrev00/. It's not really clear to me how they comment on each others' diffs, but I guess this must be done out-of-band (maybe via email, chat or walking over to their desk). It really feels like Git is a relatively small part of the migration. Mercurial and Git support more-or-less the same set of features, and neither one is really much better than the other (tbh I like Mercurial slightly better). Moving to GitHub as a code review tool (and possibly other things too) is going to have a much larger impact on the developer workflow than the version control tool.
holidayacct 6y ago
They are advertising for GitHub, I still don't know why people feel the need to use Github for well known projects other than the "social" aspect of GitHub. It would be interesting to see if it would be possible to extract the "social" aspect out GitHub and allow people to host git with a distributed social model (i.e. you host your own git on your own decentralized server but your social account and associated comments/metadata are all centralized.)
- swiley 6y ago
  I think a lot of people really like the pull request UI.
gjvc 6y ago
> It seems to imply that GitHub hosting is the only way to run Git. The first time I heard about git and github in 2008 I thought this.
pyuser583 6y ago
It also implies that GitHub won’t host Mercurial repos. That is not true either.
JoBrad 6y ago
You’re right about the (false) equivalency. But I think that “github” is well on its way to being the “kleenex” of version control.

suyash 6y ago

Good point, people have largely forgotten the distinction between Git and GitHub.

Abishek_Muthian 6y ago
Very true and the search engines are to be blamed as well. Recently, I was searching for a Git - fork project (i.e. a project forked from git itself) which allowed separate machine based accounts for Git branches. It was quite famous, I had used it about 4 years back and I don't remember its name now. Now, this is the worst case scenario for the search engines - • 'git fork project' would bring numerous github forked projects. • 'git original source' would bring the mirror of git in github, but then again there are hundreds of fork. After, lot of time spent on this in vain, I gave up. UPDATE: While writing this comment I remembered the USP of that project was 'Branch specific permissions', so I gave a fresh attempt at finding it and I did via SO! It's Gitolite[1]. [1]https://github.com/sitaramc/gitolite https://github.com/sitaramc/gitolite
- throwaway8941 6y ago
  Have you tried adding -github to your search queries?
  - Abishek_Muthian 6y ago
    Yep, I tried Github as part of the query. Anyways, even without 'GitHub' almost all front page results are from there and that's one of the point I'm trying to make.
    - webmaven 6y ago
      You can also exclude results from the site completely with -site:github.com, though you're still left with the problem that 'git fork' and variants won't really bring up results that are forks of git, but results that are about forking in git. Ultimately, in this case only recalling the USP or a similarly unique phrase was ever going to help you find the result you were looking for.
- deleted 6y ago
  [deleted]

pjmlp 6y ago

For most people it is. Just like we can discuss all day about POSIX, UNIX and various implementations of them, while most people would relate to Ubuntu.

mrpippy 6y ago
Or even worse, describing an entire Linux binary compatibility layer as "Bash on Ubuntu on Windows", like Microsoft originally did. https://blogs.windows.com/windowsdeveloper/2016/03/30/run-bash-on-ubuntu-on-windows/ https://blogs.windows.com/windowsdeveloper/2016/03/30/run-ba...
- ChrisSD 6y ago
  I'm not sure what's objectionable about that blog post? It describes a common scenario for using the compatibility layer (and indeed the main motivation for creating it). Especially early on when the compatibility layer was only fully tested with a specific version of Ubuntu.
andialo 6y ago
And that's exactly the reason why they should mention they are migrating to git hosted on GitHub in that announcement. It's pretty bothering that most people equate a distributed open-source code versioning system with a centralized Microsoft service, isn't it?
- pjmlp 6y ago
  Agreed, it also irritates me that people equate Linux with UNIX for example, or developers with Linux workflows for that matter.
chx 6y ago
> For most people it is. Excluding the contributors to such small projects as KDE, Gnome, Freedesktop, Debian, Arch Linux, Drupal all of which are self hosting Gitlab.
bryanrasmussen 6y ago

idclip 6y ago

Its fun for me to say this, but it just goes to show the kind of people behind the project today, i mean, did you see the explosion in versioning ? OJDK/ORACLE duo slowly feeding the hype machine by carefully making moves that all the players look good. You say github, i see a very careful type of microsoft pitch. That all said ... well good on them, its about time.

sradman 6y ago

Project Skara appears to consider this a two step process [1]: > The goal of this Project is to investigate alternative SCM and code review options for the JDK source code, including options based upon Git rather than Mercurial, and including options hosted by third parties. > Two JEPs are planned for this investigation, first JEP 357: Migrate from Mercurial to Git [2] and second JEP 369: Migrate to GitHub. . [3] [1] https://openjdk.java.net/projects/skara/ https://openjdk.java.net/projects/skara/ [2] https://openjdk.java.net/jeps/357 https://openjdk.java.net/jeps/357 [3] https://openjdk.java.net/jeps/369 https://openjdk.java.net/jeps/369

rapnie 6y ago

Yes, this bothers me too. The extra features that Github offers on top of Git are generally referred to as a 'forge' [0]. And talking about forges I hope we will look beyond just Github and consider all of them (gitlab, gitea, sourcehut, gogs, pagure, gitern, etc.) and focus on their interoperability! Just mentioned in another comment, but ForgeFed [1] could be the solution to achieve this, creating a federation of forges where it doesn't matter which software one prefers. [0] https://en.wikipedia.org/wiki/Forge_(software) https://en.wikipedia.org/wiki/Forge_(software) [1] https://forgefed.peers.community https://forgefed.peers.community

gigatexal 6y ago

I get that but I think by saying "Github" instead of "git" one is emphasizing the social and collaborative aspects of Github over plain git. My 2 cents anyway.

giomasce 6y ago
That would make it even more wrong, since it seems from the JEPs that, at least for the time being, they're only using GitHub as hosting service. No wikis, PRs, issues and so on.
- elygre 6y ago
  They will use pull requests, but it is a design goal for the process to be somewhat independent of GitHub. For more detailed information, the OpenJDK mailing lists archive is a good source.

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.

j1elo 6y ago

Well, if they are consciously moving to use the Pull Request, Issue tracker, Actions, Wiki, and other features of GitHub, and incidentally Git as part of the package, then I'd say that yes, they _are_ moving to GitHub, and not just Git. Edit: I was specifically thinking on this main point they mentioned: "Programmatic APIs to enable process assistance and automation of review and processes", which to me means PR and Actions. I was just assuming that they will probably also use the Issues feature too.

akerro 6y ago

OpenJDK said in discussion that they are migrating to GitHub but will try to make their process platform agnostic and not be too attached to GitHub.

krzyk 6y ago

Well, actually there are two JEPs: - Migrate from Mercurial to Git - https://openjdk.java.net/jeps/357 https://openjdk.java.net/jeps/357 - Migrate to GitHub - https://openjdk.java.net/jeps/369 https://openjdk.java.net/jeps/369 And also in JEP 369 at the and there is: > In order to prevent the Skara tooling from depending upon a particular provider's API, support for multiple external providers has been a strict requirement from the beginning. All of the tooling is also required to work with the open-source GitLab Community Edition (GitLab CE).

WhyNotHugo 6y ago
I wonder why they didn't pick GitLab though. They just mention it as an alternative, but there's not a single word on why they preferred one over the other.
- Alupis 6y ago
  Because "Github is where it's at!". They're looking for an instantly-large community with built in support. Everyone has a Github account, but not everyone has a Gitlab account. Yes it's easy to get a Gitlab account for free, but that's still a barrier at the moment.
- krzyk 6y ago
  They have previously chosen mercurial which didn't won the DVCS battle, so I assume they now bet on a winning horse.
  - WhyNotHugo 6y ago
    Uhm... GitLab also uses Git, not sure what you're talking about.

quicklime 6y ago

I agree. I don't think your point is pedantic, although I think calling GitHub a "hosting service" downplays some major features that GitHub has. For me the big one is code reviews (via pull requests), but it also has GitHub Issues and GitHub Actions, amongst other things. So when someone says they're migrating "from Mercurial to GitHub", I'm left wondering: what were they previously using for code reviews, issue tracking, etc? From the article: > OpenJDK has used the Mercurial source code management solution since 2008 to store source code and conduct code reviews This doesn't make sense. Mercurial doesn't provide a code review feature, and neither does Git. So what do they currently use for code reviews? I had to dig in to the site a bit, but the workflow is described in https://openjdk.java.net/guide/codeReview.html https://openjdk.java.net/guide/codeReview.html. It looks like they use a (Korn!) shell script called "webrev" that will "generate a set of web pages to display the differences", and they then scp over the static html files to a shared public web server. Here's an example I pulled out of their Atom feed: https://cr.openjdk.java.net/~pbansal/8249548/webrev00/ https://cr.openjdk.java.net/~pbansal/8249548/webrev00/. It's not really clear to me how they comment on each others' diffs, but I guess this must be done out-of-band (maybe via email, chat or walking over to their desk). It really feels like Git is a relatively small part of the migration. Mercurial and Git support more-or-less the same set of features, and neither one is really much better than the other (tbh I like Mercurial slightly better). Moving to GitHub as a code review tool (and possibly other things too) is going to have a much larger impact on the developer workflow than the version control tool.

holidayacct 6y ago

They are advertising for GitHub, I still don't know why people feel the need to use Github for well known projects other than the "social" aspect of GitHub. It would be interesting to see if it would be possible to extract the "social" aspect out GitHub and allow people to host git with a distributed social model (i.e. you host your own git on your own decentralized server but your social account and associated comments/metadata are all centralized.)

swiley 6y ago
I think a lot of people really like the pull request UI.

gjvc 6y ago

> It seems to imply that GitHub hosting is the only way to run Git. The first time I heard about git and github in 2008 I thought this.

pyuser583 6y ago

It also implies that GitHub won’t host Mercurial repos. That is not true either.

JoBrad 6y ago

You’re right about the (false) equivalency. But I think that “github” is well on its way to being the “kleenex” of version control.