Ramkumar Ramachandra wrote:
> When set,
> instead of cloning the given repository as-is, it relocates the gitdir
> of the repository to the path specified by this variable.
Interesting. As the discussion downthread from this illustrated, I am
not convinced this is better than a subcommand of "git submodule" for
that particular purpose, yet.
Is the goal to be able to, under some certain configuration, make
"git clone" + "git add" behave like "git submodule add"?
> I don't like the
> .git/modules nonsense).
As Jeff mentioned, a given repository can be a subproject of multiple
different containing projects, that use different versions of it.
It doesn't make sense for different directories on the filesystem to
share an index anyway.
Do you want the subprojects to be symlinks to the One True Version
of each project? (I can see that working ok in some workflows.) Or
do you want subprojects to be lightweight workdirs like
git-new-workdir creates, with .git/objects pointing to the project's
One True Object Store?
That is the part of this design that seems least well fleshed out to
me at the moment.
I quite like .git/modules/<subproject name> (for some reasons that
I've mentioned in other threads) and don't consider it nonsense, which
makes me assume I don't understand the goal of this patch, either.
Please don't take that personally.
Hope that helps,
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