Jonathan Nieder wrote:
> That sounds similar to what Junio does with the Meta subdirectory in
> his git development worktree. I don't think submodules are a good
> fit, but it might make sense to start respecting a .motd file to allow
> the following in a hypothetical world where everyone who clones git
> uses the same scripts Junio does:
> $ git clone git://repo.or.cz/git.git
> Cloning into 'git'...
> remote: Counting objects: 151283, done.
> remote: Compressing objects: 100% (38546/38546), done.
> remote: Total 151283 (delta 111004), reused 151073 (delta 110797)
> Receiving objects: 100% (151283/151283), 36.39 MiB | 7.66 MiB/s, done.
> Resolving deltas: 100% (111004/111004), done.
> Don't forget to "git clone -b todo git://repo.or.cz/git.git git/Meta"
> for maintenance scripts.
Nope, it's not mandatory for everyone to use dotfiles.git in exactly
the same way either. In other words: I'm not sitting in an office and
working with my colleagues on exactly the same things, in exactly the
same way; wasn't that the Subversion age? Some might decide to
initialize a few submodules, change the URLs of some, and remove some.
I'd want my private fork to have commits changing "initialize
submodule quux" to "don't initialize submodule quux", and be able to
rebase that on top of upstream. Why are you leaning towards solutions
for very narrow usecases?
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