On Fri, Dec 08, 2017 at 03:21:23PM -0800, Junio C Hamano wrote: > Junio C Hamano <gits...@pobox.com> writes: > > > That endgame allows us not force people to grab an essential part of > > the codebase as an external dependency from another place, which > > feels quite bad, especially when their primary interest is not in > > dogfooding submodule but in building a working version of Git. > > > > Removing one and keeping the other between the two will make the > > distribution more streamlined by removing the build-time knob we > > need to tweak, but the one that gets removed does not have to be the > > in-tree one that allows people to "git clone" from just one place. > > Perhaps this may deserve a bit more explanation. > > I wouldn't be so against "let's do submodule-only" if this were not > SHA-1 implementation but something like gitk and git-gui. An optional > part of a system that it is safe to leave to individual builders if > they want to fetch and use that part *is* an ideal target to bind as > a submodule to the system. > > It's just the "default SHA-1 implementation" is at the far opposite > end of the spectrum from "an optional part", and our use of > submodule to bind this code is definitely *not* because it makes > sense to use submodule in that context; it is because developers > (not necessarily those who consume Git sourcecode) *wanted* to use > submodule there, regardless of the real merit of doing so.
Thanks for writing this out. I had a vague feeling that I didn't quite like going the submodule-only direction, but I was having trouble putting into words. It's exactly this. -Peff
