All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Smirnov <divis1969@gmail.com>
To: git@vger.kernel.org
Subject: Git drawbacks?
Date: Fri, 6 Nov 2009 16:17:30 +0000 (UTC)	[thread overview]
Message-ID: <loom.20091106T160709-387@post.gmane.org> (raw)

Hi,

Sorry if I selected the wrong place to discuss the drawbacks of the Git. Just 
point to the proper one...

I'm just trying to select the best VCS for me personally.
I have a very small experience with Git but I see is also not very sutable for 
me.

First, it seems to be very hard to setup some really big project (like Android, 
for example). Otherwise, why do they need to invent 'repo'? What purpose it 
solves? It looks like it
1. Integrates few subcomponents (projects) and checkout the code in the proper 
configuration. The question is why this is not the Git task? For me, it looks 
like the ClearCase client spec.
2.? What others (except integration with review tool)? 

The next issue with git is its clone. Why do I need the whole set of revisions? 
Why do I need to get 1GB of Android? You could say this should happen once. I 
would agree but when I tried to resync the Android tree after 2 months, I was 
struggled with many errors (both git and repo). Finally, I had decided to sync 
again. :-)
There is one point against clone. The typical situation in my office is to have 
few Perforce clients with the same or slightly  different code. This is just 
wasting a space since you need them all but versions of many files are the same. 
I'm trying to imagine the same situation with Git. Are there any benefits? It 
seems, no. Moreover, I will have not only few working trees but few repository 
clones!

It is obvious that configuration management with Git is very difficult (for ex, 
http://groups.google.com/group/repo-
discuss/browse_thread/thread/2fa368ed7cac5d79/64ced51656240ddc?
lnk=gst&q=create+android+bare+repository#64ced51656240ddc)

Let's consider the foolwing use case. Suppose I'm intending to create a new 
product that consists of specific versions (or branches) of some subcomponents 
(or directories). How can I do this with Git? Subsequent changes could either be 
submitted to the appropriate component branch or branched to the new one (this 
way is possible with Git, of course, if I will branch the code I need to this 
new branch).

So, I'm wondering, why Git (or any other VCS) is not trying to solve these 
problems? Perhaps, there is a simple solution with Git I'm not aware of?

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. :-)

Dmitry

             reply	other threads:[~2009-11-06 16:25 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-06 16:17 Dmitry Smirnov [this message]
2009-11-06 16:49 ` Git drawbacks? 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
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.20091106T160709-387@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.