Re: Git drawbacks?

From: Dmitry Potapov <dpotapov@gmail.com>
Date: Nov 9, 2009, 15:48 UTC
Message-ID: <20091109154816.GH27126@dpotapov.dyndns.org>
In-Reply-To: <loom.20091109T084539-720@post.gmane.org>

On Mon, Nov 09, 2009 at 07:53:24AM +0000, Dmitry Smirnov wrote:

Show 10 quoted lines

>  <david <at> lang.hm> writes:
> 
> > going back to the initial poster's comments. if the android repo is 1G, 
> > eliminating the history will probably have significantly less impact than 
> > you expect it to. 
> 
> Do you have 2 or more copies of the same repository at the same time?
> If yes, can I skip cloning new copy from network? 
> Or even skip cloning it at all? 
> Is it possible with Git to chekout into two (few) working trees?

Jacob has already mentioned git-new-workdir from Git contrib, but there are other ways to do the same or almost the same....

First of all, you can always copy your directory and thus creating another clone. It is very simple and straightforward solution, but it takes extra space due an extra copy of the repository. Usually, it is not a big issue in practice, because your working tree tends to be larger than the repository itself...

However, if you want to save disk space, you can use local clone. When you clone your (like: git clone old_dir new_dir), git tries to use hard links if it is possible. So, it may save disk space. However, if you repack your original repo then a new pack will be created, and saving from using the hard link will be lost. To prevent that from happening, you can tell to the garbage collector to keep the main existing pack by create a file that has the same name as the pack file plus the .keep suffix:

   touch .git/objects/pack-<SHA-1>.keep

then all changes will be put into a separate pack.

There is one more way to save disk space is to use git clone --shared. It does not require hard links, but it has some caveats. If you want to use it, then read the documentation carefully and make sure you understand all implications.

Actually, in most use cases, there is no reason to have more than one working tree. Git is designed to work well with plenty branches and one working tree. So, switching between two branches and recompiling a few changed files is much faster then going to another directory and try to work there, because when you go to another directory, you may hit cold cache and disk is *slow*... Another thing is that you can do a lot of things without checking out some branch. You can grep any revision in your repository, you can insect any file from it, etc and you do not have to checkout this revision in your working tree.

Dmitry