4 ms·

Show HN: Point your repos to their new home

23 points by yogsototh 8y ago

deleted 8y ago
[deleted]
jarfil 8y ago
You know git is distributed? You can keep all your repos both on GitLab, GitHub, as many local machines as you want... etc. all at the same time.
- 18nleung 8y ago
  Most orgs like having a single source of truth for their projects, though (for instance, the Linux kernel GitHub repo is simply a mirror). In fact, if anything, this project could set up mirroring so repos are mirrored from GitLab to GitHub, etc.
  - palunon 8y ago
    But then, the Linux kernel really have multiple sources of truth, depending on what version you are talking about (Linus branch, mainline, vendor forks, etc) The main point isn't about the source code, it's about all the rest : bug report, discussions, planning..
- arfar 8y ago
  I think is more about the political statement of leaving GitHub rather than the practicalities of code management.
captn3m0 8y ago
don't do this please. I run my own gitea instance, and for repos that are in multiple places, I leave a note in the readme as to what the canonical URL is. If someone wants to open a PR or an issue on Github I don't wanna be hostile by having them create another account just to ask a question. Once the patch is merged, it gets pushed on all remotes. If you have a large project with lots of contributors and activity, and you actively want to discourage contributions in the wrong place, you can disable issues or PRs for that one repo. Also, people browse code using GitHub clients, serving an empty Readme is not a good idea to break that behaviour.
- pc86 8y ago
  TIL not accepting PRs and issues on every platform is "hostile."
  - always_good 8y ago
    Disabling issues can feel hostile, though I understand why large projects might do it because idiots abuse the system. But when I go to a project on Github to report an issue and I can't, then I can't help but think "well fuck you too."
    - fluxsauce 8y ago
      As someone who runs a couple small projects with large userbases, having multiple issue queues across multiple platforms is a massive organizational hassle. Having one canonical place for issues makes life easier for all parties. With that said, if you disable issues on a system, make sure you have prominent documentation that says "Submit issues to XXX". Otherwise, it's confusing.
      - jstanley 8y ago
        > Having one canonical place for issues makes life easier for all parties. It makes life easier for you. It doesn't make life easier for the casual user of your software who just wants to report one issue.
        fluxsauce 8y ago
        And for the users. Given that it's fairly technical software, it's reasonable to expect that folks would search the issue queue before submitting an issue. If the issue queue was split across multiple sources, issues would exist in one system and not the other. Sorry if you disagree, but giving clear instructions about how to report issues and limiting vectors is fair, logical, and incredibly common and a best practice.
        lhorie 8y ago

23 points by yogsototh 8y ago

deleted 8y ago

[deleted]

You know git is distributed? You can keep all your repos both on GitLab, GitHub, as many local machines as you want... etc. all at the same time.

18nleung 8y ago
Most orgs like having a single source of truth for their projects, though (for instance, the Linux kernel GitHub repo is simply a mirror). In fact, if anything, this project could set up mirroring so repos are mirrored from GitLab to GitHub, etc.
- palunon 8y ago
  But then, the Linux kernel really have multiple sources of truth, depending on what version you are talking about (Linus branch, mainline, vendor forks, etc) The main point isn't about the source code, it's about all the rest : bug report, discussions, planning..
arfar 8y ago
I think is more about the political statement of leaving GitHub rather than the practicalities of code management.

captn3m0 8y ago

don't do this please. I run my own gitea instance, and for repos that are in multiple places, I leave a note in the readme as to what the canonical URL is. If someone wants to open a PR or an issue on Github I don't wanna be hostile by having them create another account just to ask a question. Once the patch is merged, it gets pushed on all remotes. If you have a large project with lots of contributors and activity, and you actively want to discourage contributions in the wrong place, you can disable issues or PRs for that one repo. Also, people browse code using GitHub clients, serving an empty Readme is not a good idea to break that behaviour.

pc86 8y ago
TIL not accepting PRs and issues on every platform is "hostile."
- always_good 8y ago
  Disabling issues can feel hostile, though I understand why large projects might do it because idiots abuse the system. But when I go to a project on Github to report an issue and I can't, then I can't help but think "well fuck you too."
  - fluxsauce 8y ago
    As someone who runs a couple small projects with large userbases, having multiple issue queues across multiple platforms is a massive organizational hassle. Having one canonical place for issues makes life easier for all parties. With that said, if you disable issues on a system, make sure you have prominent documentation that says "Submit issues to XXX". Otherwise, it's confusing.
    - jstanley 8y ago
      > Having one canonical place for issues makes life easier for all parties. It makes life easier for you. It doesn't make life easier for the casual user of your software who just wants to report one issue.
      - fluxsauce 8y ago
        And for the users. Given that it's fairly technical software, it's reasonable to expect that folks would search the issue queue before submitting an issue. If the issue queue was split across multiple sources, issues would exist in one system and not the other. Sorry if you disagree, but giving clear instructions about how to report issues and limiting vectors is fair, logical, and incredibly common and a best practice.
      - lhorie 8y ago