5 ms·

Ever had an upstream gitsubmodule move or shut down? I can't go back 6 months in my SCM and rebuild exactly what I had because the repo is gone now. This is bad

Ever had an upstream gitsubmodule move or shut down? I can't go back 6 months in my SCM and rebuild exactly what I had because the repo is gone now. This is bad and against the concept of having an SCM in the first place. There is a horrible habit of people forking projects on github just so their submodule stay stable. It's broken.

nodemaker 14y ago
>There is a horrible habit of people forking projects on github just so their submodule stay stable. It's broken. Yes I do this and I hate doing it!
pyre 14y ago
> There is a horrible habit of people forking > projects on github just so their submodule > stay stable. It's broken. People are forking projects on github in that way because it's a quick, easy, cheap way to create a mirror/hosted copy of the repository they want to use. I don't see how this is an example of how git-submodule is broken. If you want to use someone else's code, that is under someone else's control in your repository without creating your own backup of said code, then you're the one taking the risk by not creating said backup. If the git-submodule is mission-critical to you then you should either: 1. Always keep a separate mirror of the 3rd party repo. or 2. Mirror the 3rd party repo to a hosted location, so that your submodule can point to the mirror instead of the source (basically creating a caching layer under your control). This is no different than the guy that keeps all of his email in Gmail, then complains because Google shut down his account that 'email is broken' because it's possible for this to happen.
- zbowling 14y ago
  Sure. Why I explained the work around. Subtree includes the full history of the other project without work-arounds
  - pyre 14y ago
    subtree also includes the full history of the other project in your project's history unless you squash all of the commits (and if you squash them, then you haven't stored the full history). There might also be licensing reasons for wanting to keep the repositories separate, but not.
Confusion 14y ago
Which is why you should only use submodules with repositories under your control. At my work we happily use git submodules. Much better than svn externals and much better than any alternative that existed so far.

nodemaker 14y ago

>There is a horrible habit of people forking projects on github just so their submodule stay stable. It's broken. Yes I do this and I hate doing it!

pyre 14y ago

> There is a horrible habit of people forking > projects on github just so their submodule > stay stable. It's broken. People are forking projects on github in that way because it's a quick, easy, cheap way to create a mirror/hosted copy of the repository they want to use. I don't see how this is an example of how git-submodule is broken. If you want to use someone else's code, that is under someone else's control in your repository without creating your own backup of said code, then you're the one taking the risk by not creating said backup. If the git-submodule is mission-critical to you then you should either: 1. Always keep a separate mirror of the 3rd party repo. or 2. Mirror the 3rd party repo to a hosted location, so that your submodule can point to the mirror instead of the source (basically creating a caching layer under your control). This is no different than the guy that keeps all of his email in Gmail, then complains because Google shut down his account that 'email is broken' because it's possible for this to happen.

zbowling 14y ago
Sure. Why I explained the work around. Subtree includes the full history of the other project without work-arounds
- pyre 14y ago
  subtree also includes the full history of the other project in your project's history unless you squash all of the commits (and if you squash them, then you haven't stored the full history). There might also be licensing reasons for wanting to keep the repositories separate, but not.

Confusion 14y ago

Which is why you should only use submodules with repositories under your control. At my work we happily use git submodules. Much better than svn externals and much better than any alternative that existed so far.