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. And that is why I do not feel entirely happy with the step 4/5 and also I feel moderately strongly against the step 5/5. These two steps have a "developer first" smell that disgusts me.
