Re: Git drawbacks?
- From
Avery Pennarun <apenwarr@gmail.com>
- Date
- Nov 6, 2009, 17:51 UTC
- Message-ID
- <32541b130911060951q3358ce9ahe28fb0cf902853f2@mail.gmail.com>
- In-Reply-To
- <loom.20091106T180313-750@post.gmane.org>
On Fri, Nov 6, 2009 at 12:35 PM, Dmitry Smirnov <divis1969@gmail.com> wrote:
Show 7 quoted lines
> 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).
Show 6 quoted lines
>> 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