Re: Git drawbacks?

From: Dmitry Smirnov <divis1969@gmail.com>
Date: Nov 6, 2009, 17:35 UTC
Message-ID: <loom.20091106T180313-750@post.gmane.org>
In-Reply-To: <32541b130911060849s2d8f13f5sb9b8390f075f8d15@mail.gmail.com>

> > Here is the wish list for the VCS I would prefer:
> > 1. Atomit commits
> > 2. The possibility to get any slice of the code repository with the

possibility

Show 9 quoted lines

> > to commit my changes on tip or on separate branch.
> > 3. The minimum footprint of the same code on my local machine.
> > 4. No code/history on my machine untill I really need it.
> > 5. Easy mirroring and replication
> >
> > I would say, ClearCase might be my favorite if it is not commercial. 
> 
> #1 and #5 are features of any DVCS, so git already has them.  #2, 3,
> and 4 are all just saying the same thing:

No, #2 is about the repository slicing, branching, merging (SCM in other words). Let's suppose I have the product that have 2 directories: component1 and component2. They were developing together for previous product (on the same branch, for example). Now, I would like to have component1 and replace component2 with some 3rd party component. What should I do with Git to get this? Or maybe I wish to stick with some version of component2 and provide only bug fixes for this product... Or let's take a look at GDB. They are using binutils which are in separate repository (they use CVS, but let's imagine they use Git). How many effors they will need for SCM? For example, they would prefer to stick to some stable version/branch of the binutils but should be able to commit bug fixes.

Once again, perhaps there is some way to do this with Git? I did not yet find it.

> "I can't afford the disk
> space to store the entire repo."  Are you sure this is true, or is it
> a preconception?  Even a 1GB repository is tiny by modern disk
> standards.

oh, yes, since we have big drives and fast internet, we do not have to worry about space and download time... :-)

> My (limited) experience with ClearCase is that it's so slow that you'd
> do *anything* to track fewer files in your working copy, so they put a
> lot of work into exactly that, and no work into performance.

This probably true. Thought I did not have a lot of problems with it unless I use GUI.

>  This
> lousy performance isn't the case in git (except in Windows).  Are you
> using Windows, by chance?

yes. I did not yet noticed any performance problems with Git on windows, except a sync/download time (for android, mostly)