Hi Dmitry, On Thu, Oct 30, 2014 at 6:41 PM, Dmitry Oksenchuk <oksenchu...@gmail.com> wrote: > 2014-10-30 19:54 GMT+03:00 Christian Couder <christian.cou...@gmail.com>: >> >> This might be a good idea. Did you already test that the small >> repository is really faster than the full repository? > > Yes, because of such amount of refs, push in "historical" repository > takes 12 sec, push in "working" repository takes 0.4 sec, push in > "joined" repository takes 2 sec. Local operations with history like > log and blame work with the same speed in "joined" repository as in > "historical" repository.
What does "joined" mean? Does it mean joined using grafts? Or joined using replace refs? Or just the unsplit full repository? Also what is interesting is if local operations work with the same speed in the small "working" repository as in the unsplit full repository. >>> Are there any disadvantages of using grafts and replace? Will both of >>> them be supported in future versions of Git? >> >> My opinion is that grafts have no advantage compared to replace refs. >> >> Once you have created your replace refs, they can be managed like >> other git refs, so they are easier to distribute. >> >> Basically if you want to get the full history on a computer you just need to >> do: >> >> git fetch 'refs/replace/*:refs/replace/*' By the way the above should be: git fetch origin 'refs/replace/*:refs/replace/*' > That's true but you still need to have another remote with full > history because it has lots of tags and branches that will be cloned > by initial clone. Yeah, you might want to have another remote for that reason, but this is true with both grafts and replace refs. Best, Christian. -- 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
