Re: Git drawbacks?

[Avery Pennarun <apenwarr@gmail.com>]

On Fri, Nov 6, 2009 at 12:35 PM, Dmitry Smirnov <divis1969@gmail.com> wrote:
> 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...

There are three methods I know of to manage this:

1) Just commit whatever version of a subproject you want as a subtree
of your current project, and if you want to replace/delete/upgrade it,
just do that.  (You rarely want to track the actual *history* of the
third party tool, just the history of versions *you* used, which is
easy to do.)

2) Use git-submodule to link repositories together.  (Arguably, one
major reason 'repo' was written is that git-submodule is too
complicated, though.)

3) Try my git-subtree tool, which basically makes it easier to
split/join repositories (similar to #1) without losing the history
(similar to #2).

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

Basically, performance is linear with the number of files in your
repo.  If you can check out just a "slice" of your repo (say 10% of
the whole), you'll have faster performance (eg. 10x) from any VCS.

git on Linux is so fast that this isn't very necessary most of the
time.  But git on Windows isn't really any faster than other VCSes on
Windows, so the time-per-file is much greater, and thus the penalty
for huge repositories is much worse.  Doing things like switching
branches, which is near-instantaneous on Linux even with tens of
thousands of files, really crawls on Windows.

So I can see an argument that Windows users would want arbitrary
"slices" much more often than Linux+git users, but I think this is
largely due to performance, not because people really *want* to be
stuck with a restricted view of the repo.

Have fun,

Avery