All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Potapov <dpotapov@gmail.com>
To: Dmitry Smirnov <divis1969@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: Git drawbacks?
Date: Mon, 9 Nov 2009 18:48:16 +0300	[thread overview]
Message-ID: <20091109154816.GH27126@dpotapov.dyndns.org> (raw)
In-Reply-To: <loom.20091109T084539-720@post.gmane.org>

On Mon, Nov 09, 2009 at 07:53:24AM +0000, Dmitry Smirnov wrote:
>  <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

  parent reply	other threads:[~2009-11-09 15:48 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-06 16:17 Git drawbacks? Dmitry Smirnov
2009-11-06 16:49 ` Avery Pennarun
2009-11-06 17:35   ` Dmitry Smirnov
2009-11-06 17:41     ` Jacob Helwig
2009-11-06 17:51     ` Avery Pennarun
2009-11-06 18:57       ` david
2009-11-09  7:53         ` Dmitry Smirnov
2009-11-09 14:34           ` Jacob Helwig
2009-11-09 15:59             ` Dmitry Smirnov
2009-11-09 16:21               ` Jacob Helwig
2009-11-09 15:48           ` Dmitry Potapov [this message]
2009-11-09 16:11             ` Dmitry Smirnov
2009-11-09 18:34               ` Dmitry Potapov
2009-11-10  8:31                 ` Dmitry Smirnov
2009-11-10 13:45                   ` Dmitry Potapov
2009-11-10 14:14                     ` Dmitry Smirnov
2009-11-10 16:15                       ` Paolo Bonzini
2009-11-09 18:47               ` B Smith-Mannschott
2009-11-09 21:06                 ` Dmitry Potapov
2009-11-10  8:51                   ` Dmitry Smirnov
2009-11-10 14:04                     ` Dmitry Potapov
2009-11-10 14:54                       ` Dmitry Smirnov
2009-11-10 16:20                         ` Paolo Bonzini
2009-11-10 23:43                         ` Dmitry Potapov
2009-11-10  9:08                 ` Dmitry Smirnov
2009-11-09  7:22       ` Dmitry Smirnov
2009-11-11 10:21 ` Dmitry Smirnov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20091109154816.GH27126@dpotapov.dyndns.org \
    --to=dpotapov@gmail.com \
    --cc=divis1969@gmail.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.