Am 28.03.2013 11:01, schrieb Ramkumar Ramachandra:
> Jonathan Nieder wrote:
>> Do you mean that you wish you could ignore subrepository boundaries
>> and use commands like
>> git clone --recurse-submodules http://git.zx2c4.com/cgit
>> cd cgit
>> vi git/cache.h
>> ... edit edit edit ...
>> git add --recurse-submodules git/cache.h
>> git commit --recurse-submodules
>> git push --recurse-submodules
>> , possibly with configuration to allow the --recurse-submodules to be
>> implied, and have everything work out well?
> Do you realize how difficult this is to implement? We'll need to
> patch all the git commands to essentially do what we'd get for free if
> the submodule were a tree object instead of a commit object (although
> I'm not saying that's the Right thing to do). Some caveats:
> - If we maintain one global index, and try to emulate git-subtree
> using submodules, we've lost. It's going to take freakin' ages to
> stat billions of files across hundreds of nested sumodules. One major
> advantage of having repository boundaries is separate object stores,
> indexes, worktrees: little ones that git is designed to work with.
Are you aware that current Git code already stats all files across
all submodules recursive by default? So (again) no problem here, we
do that already (unless configured otherwise).
> - Auto-splitting commits that touch multiple submodules/ superproject
> at once. Although git-subtree does this, I think it's horribly ugly.
You don't like it, but what technical argument is hidden here I'm
> - Auto-propagating commits upwards to the superproject is another big
> challenge. I think the current design of anchoring to a specific
> commit SHA-1 has its usecases, but is unwieldy when things become big.
> We have to fix that first.
What??? Again there is nothing to "fix" here, "anchoring to a specific
commit SHA-1" is *the* most prominent use case (think reproducibility
of the whole work tree), floating submodules are the oddball here.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html