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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html