In general I think it is a mistake to overload "git clone" with the notion of
adding a submodule. If I want to *add* something to a repository, I'll use
some kind of "add" command. To me "git clone" is not the kind of verb I
would expect to add something to some distant-parent .git directory.
Instead of mucking around with"git clone" I would much rather see "git add"
autodetect URLs and do the submodule thing:
git add ssh://host/blammo.git
would clone blammo.git into ./blammo/ and set it up as a submodule inside
$PWD's git repo. (This may benefit from "git clone" learning some kind of
--separate-git-dir option, but that's irrelevant to me.)
On 13-04-15 04:19 AM, Ramkumar Ramachandra wrote:
>
> Why would a user *want* a full clone inside a git worktree?
Please try to be careful with your assumptions.
I could have
~/.git/
to maintain revisions of various personal files, config .dotfiles, scripts in
~/bin/ and so on.
I could also have various projects' repos under ~/Code, where I do my "real"
work:
~/Code/git/.git/
~/Code/DayJob/.git/
~/Code/project-foo/.git/
Now, are these Code/* repos inside ~/.git/'s worktree or not? I'd really
prefer them not to be. I would be especially upset to have some "magic" that
automatically adds new clones inside ~/Code/ to ~/.git/.
M.
--
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
