3 ms·

Doesn't that seem like a build tool situation? At that point the other piece of code isn't part of source, it's a source dependency, and no different from a bin

Doesn't that seem like a build tool situation? At that point the other piece of code isn't part of source, it's a source dependency, and no different from a binary dependency at some version so you don't really want the tree, you want the file at some revision and if it's `github` based then you have the natural HTTP endpoint and otherwise it's trivial to proxy as an artifact.

phonebanshee 7y ago
Not really. You often need to make extensive changes in those kinds of external dependencies, so you really do want them in your source tree.
- scarejunba 7y ago
  Oh, interesting. That explains why you want to retain the history, so you can easily merge and stuff too.
MayeulC 7y ago
Well, you are right, but there would still be some advantages to submodules: 1. Check the files hash themselves: while you can definitely put the commit ID in the URL, nothing prevents the remote server (though unlikely if github) to answer with another version of the file (and could even do so selectively for your build server). 2. Simple upgrade path: with submodules, you can just `cd` into them and run `git pull` or `git checkout v11.5.2`, and git itself could inform you that a newer version is available if tracking a branch. I also agree with the contribution aspect, though it is less important in some cases. I take the latest example I have in mind where this could have been useful: For integration into F-Droid, RiotX needed not to include binary artifacts of a library, but the source itself. The source repository is quite big (multiple languages), but the thing of interest is a single java file [1]. They ended up simply copy-pasting the file [2] in their repo, which makes its origin less obvious, and more subject to bit-rot and vulnerabilities. [1]: https://github.com/google/diff-match-patch/blob/master/java/src/name/fraser/neil/plaintext/diff_match_patch.java https://github.com/google/diff-match-patch/blob/master/java/... [2]: https://github.com/vector-im/riotX-android/pull/760 https://github.com/vector-im/riotX-android/pull/760

phonebanshee 7y ago

Not really. You often need to make extensive changes in those kinds of external dependencies, so you really do want them in your source tree.

scarejunba 7y ago
Oh, interesting. That explains why you want to retain the history, so you can easily merge and stuff too.

MayeulC 7y ago

Well, you are right, but there would still be some advantages to submodules: 1. Check the files hash themselves: while you can definitely put the commit ID in the URL, nothing prevents the remote server (though unlikely if github) to answer with another version of the file (and could even do so selectively for your build server). 2. Simple upgrade path: with submodules, you can just `cd` into them and run `git pull` or `git checkout v11.5.2`, and git itself could inform you that a newer version is available if tracking a branch. I also agree with the contribution aspect, though it is less important in some cases. I take the latest example I have in mind where this could have been useful: For integration into F-Droid, RiotX needed not to include binary artifacts of a library, but the source itself. The source repository is quite big (multiple languages), but the thing of interest is a single java file [1]. They ended up simply copy-pasting the file [2] in their repo, which makes its origin less obvious, and more subject to bit-rot and vulnerabilities. [1]: https://github.com/google/diff-match-patch/blob/master/java/src/name/fraser/neil/plaintext/diff_match_patch.java https://github.com/google/diff-match-patch/blob/master/java/... [2]: https://github.com/vector-im/riotX-android/pull/760 https://github.com/vector-im/riotX-android/pull/760