picca <picca@xxxxxxxxxxxxxxxxxxxxx> writes: > On Tue, 22 Jan 2008 01:20:41 -0800 > Junio C Hamano <gitster@xxxxxxxxx> wrote: > > > If I were you I'd probably just keep git.git as a submodule in > > your project and have two symlinks from your toplevel pointing > > at git.git/strbuf.[ch] (or from src/ to ../git.git/strbuf.[ch]). > > So submodule is a requirement to achieved this comportment ? If you want to have strbuf.[ch] automatically tracked from git.git the you would have to have git.git project somehow embedded in your repository. Using submodules is one solution. Currently there is no way to do "sparse checkout", i.e. automatically checkout only needed files (even if git.git clone has all the objects), but feel free to implement it... ;-) (just kidding). Or you can try to convince strbuf authors to make it into separate project, which would be fetched into git.git like gitk was. And you could then pull from this project directly or indirectly (submodule) into your project. > If someone want to clone my project.git, must he also clone the > git.git project or he loose the ability to follow by it's own the > strbuf.[ch] file ? True. > > Or "merge -s subtree". > > I read the git help merge -s explanation but I do not understand how > it can help in my case. Using subtree merge strategy you can join histories of your project and git.git, embedding git.git as a subdirectory like gitk and git-gui are now in git.git. It is an alternative to using submodules. -- Jakub Narebski Poland ShadeHawk on #git - 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
