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
next 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.