All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Smirnov <divis1969@gmail.com>
To: git@vger.kernel.org
Subject: Re: Git drawbacks?
Date: Fri, 6 Nov 2009 17:35:46 +0000 (UTC)	[thread overview]
Message-ID: <loom.20091106T180313-750@post.gmane.org> (raw)
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
> > 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)

  reply	other threads:[~2009-11-06 17:36 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 [this message]
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
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=loom.20091106T180313-750@post.gmane.org \
    --to=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.