Hi, On Mon, 12 Feb 2007, Rogan Dawes wrote: > Johannes Schindelin wrote: > > > > (my favourite:) > > - use git-split to create a new branch, which only contains doc/. Do work > > only on that branch, and merge into mainline from time to time. > > Your third option sounds quite clever, apart from the problem of attributing a > commit and a commit message to someone, when the actual commit doesn't match > what they actually did :-( This problem is not related to subprojects at all. If the commit message does not match the patch, you are always fscked. > As well as wondering what happens when they check out a few more files. Do we > rewrite those commits as well? What happens if the user has made some commits > already? What happens if they have already sent those upstream? etc. I think you misunderstood. My favourite option would make docs a _separate_ project, with its own history. It just happens to be pulled from time to time, just like git-gui, gitk and git-fast-import in git.git. > I think the best solution is ultimately to make git able to cope with > certain missing objects. Hmm. I am not convinced. On nice thing about git is its level of integrity. Which means that no random objects are missing. > I started writing this in response to another message, but it will do fine > here, too: > > The description I give here will likely horrify people in terms of > communications inefficiency, but I'm sure that can be improved. > > [goes on... and describes the lazy clone!] AFAICT this really is the lazy clone. And it was already determined that it is all to easy to pull in all commit objects by accident. Which boils down to a substantial chunk of the repository. But if you want to play with it: by all means, go ahead. It might just be that you overcome the fundamental difficulties, and we get something nice out of it. Ciao, Dscho - 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