... | @@ -106,7 +106,9 @@ If you use submodules, you deserve what you get :smile:. |
... | @@ -106,7 +106,9 @@ If you use submodules, you deserve what you get :smile:. |
|
More seriously, the change of repository URL risks breaking absolute submodule references. If at *any* commit in your repository, you have a submodule ref with one of the old URLs as address part, your build will fail.
|
|
More seriously, the change of repository URL risks breaking absolute submodule references. If at *any* commit in your repository, you have a submodule ref with one of the old URLs as address part, your build will fail.
|
|
|
|
|
|
To avoid this scenario, we have tried our best to keep mirrors of the old repositories at the same URLs as before. *These are read-only, non-pushable, volatile copies that are kept for backward compatibility of submodule references only*.
|
|
To avoid this scenario, we have tried our best to keep mirrors of the old repositories at the same URLs as before. *These are read-only, non-pushable, volatile copies that are kept for backward compatibility of submodule references only*.
|
|
|
|
|
|
This is the least horrible way we have found till now to keep unbroken builds in case old repository URLs (and commits) are referenced. In particular, remote URLs with intermediate path components other than `/project/` are certain to be *invalid* for any other purpose than the uses former submodule references gave to them.
|
|
This is the least horrible way we have found till now to keep unbroken builds in case old repository URLs (and commits) are referenced. In particular, remote URLs with intermediate path components other than `/project/` are certain to be *invalid* for any other purpose than the uses former submodule references gave to them.
|
|
|
|
|
|
If this sounds terrible, it is, but the sentence at the beginning says it all.
|
|
If this sounds terrible, it is, but the sentence at the beginning says it all.
|
|
|
|
|
|
### Files
|
|
### Files
|
... | | ... | |