* Git drawbacks? @ 2009-11-06 16:17 Dmitry Smirnov 2009-11-06 16:49 ` Avery Pennarun 2009-11-11 10:21 ` Dmitry Smirnov 0 siblings, 2 replies; 27+ messages in thread From: Dmitry Smirnov @ 2009-11-06 16:17 UTC (permalink / raw) To: git 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Git drawbacks? 2009-11-06 16:17 Git drawbacks? Dmitry Smirnov @ 2009-11-06 16:49 ` Avery Pennarun 2009-11-06 17:35 ` Dmitry Smirnov 2009-11-11 10:21 ` Dmitry Smirnov 1 sibling, 1 reply; 27+ messages in thread From: Avery Pennarun @ 2009-11-06 16:49 UTC (permalink / raw) To: Dmitry Smirnov; +Cc: git On Fri, Nov 6, 2009 at 11:17 AM, Dmitry Smirnov <divis1969@gmail.com> wrote: > 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: "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. 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 lousy performance isn't the case in git (except in Windows). Are you using Windows, by chance? Have fun, Avery ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Git drawbacks? 2009-11-06 16:49 ` Avery Pennarun @ 2009-11-06 17:35 ` Dmitry Smirnov 2009-11-06 17:41 ` Jacob Helwig 2009-11-06 17:51 ` Avery Pennarun 0 siblings, 2 replies; 27+ messages in thread From: Dmitry Smirnov @ 2009-11-06 17:35 UTC (permalink / raw) To: git > > 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) ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Git drawbacks? 2009-11-06 17:35 ` Dmitry Smirnov @ 2009-11-06 17:41 ` Jacob Helwig 2009-11-06 17:51 ` Avery Pennarun 1 sibling, 0 replies; 27+ messages in thread From: Jacob Helwig @ 2009-11-06 17:41 UTC (permalink / raw) To: Dmitry Smirnov; +Cc: git On Fri, Nov 6, 2009 at 09:35, 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... > 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. > Sounds like you want submodules. Check out the git-submodule(1) manpage. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Git drawbacks? 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:22 ` Dmitry Smirnov 1 sibling, 2 replies; 27+ messages in thread From: Avery Pennarun @ 2009-11-06 17:51 UTC (permalink / raw) To: Dmitry Smirnov; +Cc: git 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Git drawbacks? 2009-11-06 17:51 ` Avery Pennarun @ 2009-11-06 18:57 ` david 2009-11-09 7:53 ` Dmitry Smirnov 2009-11-09 7:22 ` Dmitry Smirnov 1 sibling, 1 reply; 27+ messages in thread From: david @ 2009-11-06 18:57 UTC (permalink / raw) To: Avery Pennarun; +Cc: Dmitry Smirnov, git [-- Attachment #1: Type: TEXT/PLAIN, Size: 2206 bytes --] On Fri, 6 Nov 2009, Avery Pennarun wrote: >>> 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. but is that scale based on the number of files you are tracking, or the number of revisions that exist in the repository. i.e. 10,000 files in the source code with 10 revisions each vs 1,000 files with 100 revisions each. my understanding of git is that it's the number of files, with very little impact due to having lots of revisions. so eliminating 90 revisions of each file would not significantly speed up git in the second case. going back to the initial poster's comments. if the android repo is 1G, eliminating the history will probably have significantly less impact than you expect it to. for source code the compression factor that git is able to get is spectacular. I've seen several cases posted with large projects where the full repo with ALL history is <2x the size of a tar.gz of the latest release. David Lang > 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 > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Git drawbacks? 2009-11-06 18:57 ` david @ 2009-11-09 7:53 ` Dmitry Smirnov 2009-11-09 14:34 ` Jacob Helwig 2009-11-09 15:48 ` Dmitry Potapov 0 siblings, 2 replies; 27+ messages in thread From: Dmitry Smirnov @ 2009-11-09 7:53 UTC (permalink / raw) To: git <david <at> lang.hm> writes: > going back to the initial poster's comments. if the android repo is 1G, > eliminating the history will probably have significantly less impact than > you expect it to. Do you have 2 or more copies of the same repository at the same time? If yes, can I skip cloning new copy from network? Or even skip cloning it at all? Is it possible with Git to chekout into two (few) working trees? ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Git drawbacks? 2009-11-09 7:53 ` Dmitry Smirnov @ 2009-11-09 14:34 ` Jacob Helwig 2009-11-09 15:59 ` Dmitry Smirnov 2009-11-09 15:48 ` Dmitry Potapov 1 sibling, 1 reply; 27+ messages in thread From: Jacob Helwig @ 2009-11-09 14:34 UTC (permalink / raw) To: Dmitry Smirnov; +Cc: git On Sun, Nov 8, 2009 at 23:53, Dmitry Smirnov <divis1969@gmail.com> wrote: > <david <at> lang.hm> writes: > >> going back to the initial poster's comments. if the android repo is 1G, >> eliminating the history will probably have significantly less impact than >> you expect it to. > > Do you have 2 or more copies of the same repository at the same time? > If yes, can I skip cloning new copy from network? > Or even skip cloning it at all? > Is it possible with Git to chekout into two (few) working trees? > Take a look at git-new-workdir. It's in the contrib directory of git.git. This lets you skip re-cloning the same repository over again, if you want a new working copy of it. It'll also give you some space savings, by sharing certain key things in the .git directory between working copies, by using symlinks. It does have a few caveats, however. If you have the same branch checked out in two different working copies created using git-new-workdir, and update the branch in one of them, then the other will appear to have a bunch of staged changes, even though you haven't done anything in it. The branch pointer will have been updated out from underneath it, and it will be "confused". As long as you remember not to update a branch that is checked out in more than one place on your machine, you'll never notice, thuogh. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Git drawbacks? 2009-11-09 14:34 ` Jacob Helwig @ 2009-11-09 15:59 ` Dmitry Smirnov 2009-11-09 16:21 ` Jacob Helwig 0 siblings, 1 reply; 27+ messages in thread From: Dmitry Smirnov @ 2009-11-09 15:59 UTC (permalink / raw) To: git Jacob Helwig <jacob.helwig <at> gmail.com> writes: > It does have a few caveats, however. If you have the same branch > checked out in two different working copies created using >... > place on your machine, you'll never notice, thuogh. So, i cannot recover from this situation by upmerging to the new head? ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Git drawbacks? 2009-11-09 15:59 ` Dmitry Smirnov @ 2009-11-09 16:21 ` Jacob Helwig 0 siblings, 0 replies; 27+ messages in thread From: Jacob Helwig @ 2009-11-09 16:21 UTC (permalink / raw) To: Dmitry Smirnov; +Cc: git On Mon, Nov 9, 2009 at 07:59, Dmitry Smirnov <divis1969@gmail.com> wrote: > Jacob Helwig <jacob.helwig <at> gmail.com> writes: > >> It does have a few caveats, however. If you have the same branch >> checked out in two different working copies created using >>... >> place on your machine, you'll never notice, thuogh. > > > So, i cannot recover from this situation by upmerging to the new head? > If you haven't actually made any changes in the second checkout of the branch, then recovery is a simple reset --hard. If you have made any changes in that working copy, then recovery is a bit more complicated, and it's probably best if I leave that explanation up to someone else, since I'm very careful to avoid this situation in the first place, and have never actually had to recover from it. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Git drawbacks? 2009-11-09 7:53 ` Dmitry Smirnov 2009-11-09 14:34 ` Jacob Helwig @ 2009-11-09 15:48 ` Dmitry Potapov 2009-11-09 16:11 ` Dmitry Smirnov 1 sibling, 1 reply; 27+ messages in thread From: Dmitry Potapov @ 2009-11-09 15:48 UTC (permalink / raw) To: Dmitry Smirnov; +Cc: git On Mon, Nov 09, 2009 at 07:53:24AM +0000, Dmitry Smirnov wrote: > <david <at> lang.hm> writes: > > > going back to the initial poster's comments. if the android repo is 1G, > > eliminating the history will probably have significantly less impact than > > you expect it to. > > Do you have 2 or more copies of the same repository at the same time? > If yes, can I skip cloning new copy from network? > Or even skip cloning it at all? > Is it possible with Git to chekout into two (few) working trees? Jacob has already mentioned git-new-workdir from Git contrib, but there are other ways to do the same or almost the same.... First of all, you can always copy your directory and thus creating another clone. It is very simple and straightforward solution, but it takes extra space due an extra copy of the repository. Usually, it is not a big issue in practice, because your working tree tends to be larger than the repository itself... However, if you want to save disk space, you can use local clone. When you clone your (like: git clone old_dir new_dir), git tries to use hard links if it is possible. So, it may save disk space. However, if you repack your original repo then a new pack will be created, and saving from using the hard link will be lost. To prevent that from happening, you can tell to the garbage collector to keep the main existing pack by create a file that has the same name as the pack file plus the .keep suffix: touch .git/objects/pack-<SHA-1>.keep then all changes will be put into a separate pack. There is one more way to save disk space is to use git clone --shared. It does not require hard links, but it has some caveats. If you want to use it, then read the documentation carefully and make sure you understand all implications. Actually, in most use cases, there is no reason to have more than one working tree. Git is designed to work well with plenty branches and one working tree. So, switching between two branches and recompiling a few changed files is much faster then going to another directory and try to work there, because when you go to another directory, you may hit cold cache and disk is *slow*... Another thing is that you can do a lot of things without checking out some branch. You can grep any revision in your repository, you can insect any file from it, etc and you do not have to checkout this revision in your working tree. Dmitry ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Git drawbacks? 2009-11-09 15:48 ` Dmitry Potapov @ 2009-11-09 16:11 ` Dmitry Smirnov 2009-11-09 18:34 ` Dmitry Potapov 2009-11-09 18:47 ` B Smith-Mannschott 0 siblings, 2 replies; 27+ messages in thread From: Dmitry Smirnov @ 2009-11-09 16:11 UTC (permalink / raw) To: git Dmitry Potapov <dpotapov <at> gmail.com> writes: > Actually, in most use cases, there is no reason to have more than one > working tree. Git is designed to work well with plenty branches and one > working tree. So, switching between two branches and recompiling a few > changed files is much faster then going to another directory and try to > work there, because when you go to another directory, you may hit cold > cache and disk is *slow*... Another thing is that you can do a lot of > things without checking out some branch. You can grep any revision in > your repository, you can insect any file from it, etc and you do not > have to checkout this revision in your working tree. Shouldn't I even worry about my not yet commited changes before switching the branch? I would say that this approach does not work if the build and test could take significant time. While in CR fix I don't want to wait for a build to complete before I countinue with another bug/fix. That is why I'm curious about few working trees... ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Git drawbacks? 2009-11-09 16:11 ` Dmitry Smirnov @ 2009-11-09 18:34 ` Dmitry Potapov 2009-11-10 8:31 ` Dmitry Smirnov 2009-11-09 18:47 ` B Smith-Mannschott 1 sibling, 1 reply; 27+ messages in thread From: Dmitry Potapov @ 2009-11-09 18:34 UTC (permalink / raw) To: Dmitry Smirnov; +Cc: git On Mon, Nov 09, 2009 at 04:11:48PM +0000, Dmitry Smirnov wrote: > Dmitry Potapov <dpotapov <at> gmail.com> writes: > > > > Actually, in most use cases, there is no reason to have more than one > > working tree. Git is designed to work well with plenty branches and one > > working tree. So, switching between two branches and recompiling a few > > changed files is much faster then going to another directory and try to > > work there, because when you go to another directory, you may hit cold > > cache and disk is *slow*... Another thing is that you can do a lot of > > things without checking out some branch. You can grep any revision in > > your repository, you can insect any file from it, etc and you do not > > have to checkout this revision in your working tree. > > Shouldn't I even worry about my not yet commited changes before switching the > branch? You probably want to use 'git stash save' and when you return back you just do 'git stash pop'. Also, keep in mind that you can amend any previous commit using 'git commit --amend'. > > I would say that this approach does not work if the build and test could take > significant time. Yes, but then I do not see any reason to do any time consuming building and testing in the working tree. I create a snapshot of the interesting version using 'git archive' and then run build&test on it... In this way, I can make sure that the archive I deliver is tested properly. If you do your testing in the working tree, sometimes uncommitted or some other files that are left over from previous builds may affect result. So, if it takes considerable time anyhow, why do not do clean build and test? And if you worry about compilation time, you can use ccache. Dmitry ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Git drawbacks? 2009-11-09 18:34 ` Dmitry Potapov @ 2009-11-10 8:31 ` Dmitry Smirnov 2009-11-10 13:45 ` Dmitry Potapov 0 siblings, 1 reply; 27+ messages in thread From: Dmitry Smirnov @ 2009-11-10 8:31 UTC (permalink / raw) To: git Dmitry Potapov <dpotapov <at> gmail.com> writes: > Yes, but then I do not see any reason to do any time consuming building > and testing in the working tree. I create a snapshot of the interesting > version using 'git archive' and then run build&test on it... In this > way, I can make sure that the archive I deliver is tested properly. If > you do your testing in the working tree, sometimes uncommitted or some > other files that are left over from previous builds may affect result. > So, if it takes considerable time anyhow, why do not do clean build and > test? And if you worry about compilation time, you can use ccache. It is not clear for me. Yes, I have to get some fixed version to reproduce the bug reported by someone. Then I need to fix it and commit the change back (on the head). Also, it is obvious to reproduce the issue and test the fix on the tip. Can do this with 'git archive'? BTW, doesn't 'git archive' sync to some version that I probably already have in other clone? ;-) ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Git drawbacks? 2009-11-10 8:31 ` Dmitry Smirnov @ 2009-11-10 13:45 ` Dmitry Potapov 2009-11-10 14:14 ` Dmitry Smirnov 0 siblings, 1 reply; 27+ messages in thread From: Dmitry Potapov @ 2009-11-10 13:45 UTC (permalink / raw) To: Dmitry Smirnov; +Cc: git On Tue, Nov 10, 2009 at 08:31:48AM +0000, Dmitry Smirnov wrote: > Dmitry Potapov <dpotapov <at> gmail.com> writes: > > > Yes, but then I do not see any reason to do any time consuming building > > and testing in the working tree. I create a snapshot of the interesting > > version using 'git archive' and then run build&test on it... In this > > way, I can make sure that the archive I deliver is tested properly. If > > you do your testing in the working tree, sometimes uncommitted or some > > other files that are left over from previous builds may affect result. > > So, if it takes considerable time anyhow, why do not do clean build and > > test? And if you worry about compilation time, you can use ccache. > > It is not clear for me. Yes, I have to get some fixed version to reproduce > the bug reported by someone. Then I need to fix it and commit the change > back (on the head). Also, it is obvious to reproduce the issue and > test the fix on the tip. Can do this with 'git archive'? > BTW, doesn't 'git archive' sync to some version that I probably already > have in other clone? ;-) I am not sure I understood your question. What 'git archive' does is to create a tar or zip archive or any version that you specify. So, you can use it to export the snapshot of any version to a temporary directory for testing if this testing takes a noticeable time and you want to be able to work on something else in meanwhile. If necessary, you can create a temporary branch starting at the intesting point and to add some commits there (such as a new test case to reproduce the problem) and then run test on it. Later, you can either rebase or merge these commits to any branch that needs them. Actually, when someone reports a problem, I do not use 'git archive' because I write a test case for this bug and run it alone, and it does not take much time to run it. But periodically (a few times a day), I run the full test suit, which takes considerable amount of time, so I run this test outside of my working directory, using 'git archive'. Dmitry ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Git drawbacks? 2009-11-10 13:45 ` Dmitry Potapov @ 2009-11-10 14:14 ` Dmitry Smirnov 2009-11-10 16:15 ` Paolo Bonzini 0 siblings, 1 reply; 27+ messages in thread From: Dmitry Smirnov @ 2009-11-10 14:14 UTC (permalink / raw) To: git Dmitry Potapov <dpotapov <at> gmail.com> writes: > I am not sure I understood your question. What 'git archive' does is to > create a tar or zip archive or any version that you specify. So, you can > use it to export the snapshot of any version to a temporary directory > for testing if this testing takes a noticeable time and you want to be > able to work on something else in meanwhile. If necessary, you can > create a temporary branch starting at the intesting point and to add > some commits there (such as a new test case to reproduce the problem) > and then run test on it. Later, you can either rebase or merge these > commits to any branch that needs them. Ok, I got it. So the scenario is something like that: 1. Stash or commit my current changes 2. Sync (reset or checkout) to some other version/branch 3. Create temporary branch 4. Edit and Commit 5. "git archive" to get snapshot 6. Get back to original change This looks reasonable. Until you need to correct the fix and test it again. Perhaps, I have to explain why fix/test cycle is so long. I'm working on mobile platform development. It is not so modular, so I need to build the whole image, then flash the mobile and test it in a real network. This takes much time and need much disk space (about 2GB of source files. In fact, significant number of these files are not needed for the build, but it is too hard to force CM engineers to fix this :-) ) ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Git drawbacks? 2009-11-10 14:14 ` Dmitry Smirnov @ 2009-11-10 16:15 ` Paolo Bonzini 0 siblings, 0 replies; 27+ messages in thread From: Paolo Bonzini @ 2009-11-10 16:15 UTC (permalink / raw) To: git > Perhaps, I have to explain why fix/test cycle is so long. I'm working on mobile > platform development. It is not so modular, so I need to build the whole image, > then flash the mobile and test it in a real network. This takes much time and > need much disk space (about 2GB of source files. In fact, significant number of > these files are not needed for the build, but it is too hard to force CM > engineers to fix this :-) ) In that case I think using multiple working trees, but sharing the pack files is a good idea. Paolo ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Git drawbacks? 2009-11-09 16:11 ` Dmitry Smirnov 2009-11-09 18:34 ` Dmitry Potapov @ 2009-11-09 18:47 ` B Smith-Mannschott 2009-11-09 21:06 ` Dmitry Potapov 2009-11-10 9:08 ` Dmitry Smirnov 1 sibling, 2 replies; 27+ messages in thread From: B Smith-Mannschott @ 2009-11-09 18:47 UTC (permalink / raw) To: Dmitry Smirnov; +Cc: git On Mon, Nov 9, 2009 at 17:11, Dmitry Smirnov <divis1969@gmail.com> wrote: > Dmitry Potapov <dpotapov <at> gmail.com> writes: > > >> Actually, in most use cases, there is no reason to have more than one >> working tree. Git is designed to work well with plenty branches and one >> working tree. So, switching between two branches and recompiling a few >> changed files is much faster then going to another directory and try to >> work there, because when you go to another directory, you may hit cold >> cache and disk is *slow*... Another thing is that you can do a lot of >> things without checking out some branch. You can grep any revision in >> your repository, you can insect any file from it, etc and you do not >> have to checkout this revision in your working tree. > > Shouldn't I even worry about my not yet commited changes before switching the > branch? commit them before you switch. you could: - commit them to the current branch before you switch the branch. - commit them to a new branch before you switch - use git stash to move your changes aside. > I would say that this approach does not work if the build and test could take > significant time. While in CR fix I don't want to wait for a build to complete > before I countinue with another bug/fix. That is why I'm curious about > few working trees... You don't have to wait to comitting to your own branches, but do make sure to run your usual builds and tests before pushing or asking another to pull changes from you. // Ben ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Git drawbacks? 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 9:08 ` Dmitry Smirnov 1 sibling, 1 reply; 27+ messages in thread From: Dmitry Potapov @ 2009-11-09 21:06 UTC (permalink / raw) To: Dmitry Smirnov; +Cc: B Smith-Mannschott, git On Mon, Nov 09, 2009 at 07:47:08PM +0100, B Smith-Mannschott wrote: > > You don't have to wait to comitting to your own branches, but do make > sure to run your usual builds and tests before pushing or asking > another to pull changes from you. Yes, it is one most useful feature of Git that you can commit (save) your changes immediately but amend them later. This helps a lot to make changes smaller, cleaner and easier to review. With many other VCS, a typical policy is that you do not commit your changes unless you have finished and tested them. But it means that your changes are not committed and stored only in the work tree for a long time. Moreover, when you eventually decide that they are good enough to commit, you will produce a huge patch, which will be difficult to review or to bisect history later. With Git you do not have to worry about testing when you can commit your changes. Typically I would commit some my changes as I progress to my goal, but later I will review all commits. Probably, squash some changes with fixes, clean up some other, add better explanations of what is done and why, etc... But I do not have to worry about all those trifles as I write code to see if some feature is worth or not, if this solution works or I should try something else... So, you can always commit your changes as your progress to your goal and review amend them later before publishing. This means that you can have as many work-in-progress branches as you wish, and you do not need a separate work tree for each of them -- everything can be stored in the repository, and you can go to another computer, issue 'git fetch' and continue your work at the exact point where you left it. So, it is very flexible. Dmitry ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Git drawbacks? 2009-11-09 21:06 ` Dmitry Potapov @ 2009-11-10 8:51 ` Dmitry Smirnov 2009-11-10 14:04 ` Dmitry Potapov 0 siblings, 1 reply; 27+ messages in thread From: Dmitry Smirnov @ 2009-11-10 8:51 UTC (permalink / raw) To: git Dmitry Potapov <dpotapov <at> gmail.com> writes: > With many other VCS, a typical policy is that you do not commit your > changes unless you have finished and tested them. But it means that > your changes are not committed and stored only in the work tree for > a long time. Moreover, when you eventually decide that they are good > enough to commit, you will produce a huge patch, which will be difficult > to review or to bisect history later. oh, yes. but this is just a policy. You can make your changes on your branch and commit them (for example, for review). Later someone just need to integrate it on original branch. The same as with Git, isn't it? The problem is just a price to branch. BTW, once I started to talk about review, we can see that most "benefits" of DVCS go away... Just because you still need some central storage to save the record of this review that should be available for SQA later... > So, you can always commit your changes as your progress to your goal and > review amend them later before publishing. This means that you can have > as many work-in-progress branches as you wish, and you do not need a > separate work tree for each of them -- everything can be stored in the > repository, and you can go to another computer, issue 'git fetch' and > continue your work at the exact point where you left it. So, it is very > flexible. As for me, I would not to have more than 4-5 such deferred changes in the same repository. Otherwise, I will be entangled finally :-) ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Git drawbacks? 2009-11-10 8:51 ` Dmitry Smirnov @ 2009-11-10 14:04 ` Dmitry Potapov 2009-11-10 14:54 ` Dmitry Smirnov 0 siblings, 1 reply; 27+ messages in thread From: Dmitry Potapov @ 2009-11-10 14:04 UTC (permalink / raw) To: Dmitry Smirnov; +Cc: git On Tue, Nov 10, 2009 at 08:51:53AM +0000, Dmitry Smirnov wrote: > Dmitry Potapov <dpotapov <at> gmail.com> writes: > > > With many other VCS, a typical policy is that you do not commit your > > changes unless you have finished and tested them. But it means that > > your changes are not committed and stored only in the work tree for > > a long time. Moreover, when you eventually decide that they are good > > enough to commit, you will produce a huge patch, which will be difficult > > to review or to bisect history later. > > oh, yes. but this is just a policy. You can make your changes on your > branch and commit them (for example, for review). Later someone just > need to integrate it on original branch. The same as with Git, > isn't it? The problem is just a price to branch. With some VCSes, it is not just the cost of branch, but it is also name pollution that happens when many branches created. But even the cost of branch creation alone may be high enough to make creating small feature branches impractical. You can try to force that on developers, but they will be frustrated with that pretty soon... And then if you really want to have good and clean history, you need more than just a branch. You should be able to amend your previous commits while you work on some feature. With Git, it is trivial, you just run 'git rebase -i' and may edit some previous commits, correct comments, squash fix-ups, etc... How can you model that? By creating another branch and moving patches to it by hands... Well, it is not very productive time spending, and the cost of branch becomes even more prominent. > BTW, once I started to talk about review, we can see that most > "benefits" of DVCS go away... Just because you still need some > central storage to save the record of this review that should > be available for SQA later... I do not see how any benefit go away because of having some central storage. Most benefits are not due to that you do not have it, but due to cheap branching, easy mirroring, and flexibility in what you want to store and where... > > > So, you can always commit your changes as your progress to your goal and > > review amend them later before publishing. This means that you can have > > as many work-in-progress branches as you wish, and you do not need a > > separate work tree for each of them -- everything can be stored in the > > repository, and you can go to another computer, issue 'git fetch' and > > continue your work at the exact point where you left it. So, it is very > > flexible. > > As for me, I would not to have more than 4-5 such deferred changes in the same > repository. Otherwise, I will be entangled finally :-) A quick look at "What's cooking in git.git" that Junio posted a few days ago reveals that there are at least 43 branches that are cooking now and the total number of branches that have been merged to 'master' over all Git history is 3290. And Git is not the largest project out there... Dmitry ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Git drawbacks? 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 0 siblings, 2 replies; 27+ messages in thread From: Dmitry Smirnov @ 2009-11-10 14:54 UTC (permalink / raw) To: git Dmitry Potapov <dpotapov <at> gmail.com> writes: > And then if you really want > to have good and clean history, you need more than just a branch. You > should be able to amend your previous commits while you work on some > feature. With Git, it is trivial, you just run 'git rebase -i' and may > edit some previous commits, correct comments, squash fix-ups, etc... > How can you model that? By creating another branch and moving patches > to it by hands... Well, it is not very productive time spending, and > the cost of branch becomes even more prominent. This is a cool feature, but it contradicts to my understanding of VCS. It is some kind of re-writing the history of WWII :-) BTW, as I undestood it, it is just a feature that can be implemented in any VCS (if you have access to its internals). > A quick look at "What's cooking in git.git" that Junio posted a few days > ago reveals that there are at least 43 branches that are cooking now and > the total number of branches that have been merged to 'master' over all > Git history is 3290. And Git is not the largest project out there... I meant 4-5 per person (me, precisely speaking) ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Git drawbacks? 2009-11-10 14:54 ` Dmitry Smirnov @ 2009-11-10 16:20 ` Paolo Bonzini 2009-11-10 23:43 ` Dmitry Potapov 1 sibling, 0 replies; 27+ messages in thread From: Paolo Bonzini @ 2009-11-10 16:20 UTC (permalink / raw) To: git On 11/10/2009 03:54 PM, Dmitry Smirnov wrote: > This is a cool feature, but it contradicts to my understanding of VCS. Not really. As long as the history is not public, nobody will notice. It is basically the same as using a centralized svn repository (corresponding to public branches) and quilt for private patch queues. You can push and pop patches as much as you want in quilt, and you can rewrite history as much as you want in git private branches. Now I'm not very proficient with quilt, but if I understood it right, git is much easier to do because you use only one tool and thus you can rely on the same algorithms for merging and conflict reporting also in the case of private branches. I've certainly done some insane reordering of patches and it worked like a charm; also, git keeps a log of the states so it takes a single "git diff" invocation to check that the end result of a reorganization is the same as what you started from. Paolo ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Git drawbacks? 2009-11-10 14:54 ` Dmitry Smirnov 2009-11-10 16:20 ` Paolo Bonzini @ 2009-11-10 23:43 ` Dmitry Potapov 1 sibling, 0 replies; 27+ messages in thread From: Dmitry Potapov @ 2009-11-10 23:43 UTC (permalink / raw) To: Dmitry Smirnov; +Cc: git On Tue, Nov 10, 2009 at 02:54:43PM +0000, Dmitry Smirnov wrote: > Dmitry Potapov <dpotapov <at> gmail.com> writes: > > > And then if you really want > > to have good and clean history, you need more than just a branch. You > > should be able to amend your previous commits while you work on some > > feature. With Git, it is trivial, you just run 'git rebase -i' and may > > edit some previous commits, correct comments, squash fix-ups, etc... > > How can you model that? By creating another branch and moving patches > > to it by hands... Well, it is not very productive time spending, and > > the cost of branch becomes even more prominent. > > This is a cool feature, but it contradicts to my understanding of VCS. Yes, it may *appear* to contradict one of basic axioms of any VCS -- history is immutable, but here is the rule -- you never ever rebase or change in any other way the public history of the official repository. So once your commits hit the master branch, you should never try to change them. This may be enforced through Git hooks. However, when we speak about history of commits in your private feature branch then no one cares about how you have arrived to these series of patches more than in what order you have edited your files. What really matters is the end result -- our patches are clean and easy to review. Now, what is 'public' history or what is not. If no one has seen your commits then it is clearly not public. If your commits are integrated to the main development branch ('master') then they are clearly public. However, many Git users have an international branch (often called as proposed updates or 'pu' for short). The 'pu' branch is regularly rewound, so no one should based their work on it. It is more for review and additional testing of things that may not ready yet. When your branch is merged to 'pu', it considered to be a fair play to re-write your patches. However, you should do that in the way that will not cause problems for people who review your changes. Finally, when you re-write some branch using interactive rebase or something else. Your old changes do not disappear immediately from your repository. Git has 'reflog', which keeps _all_ commits in your local repository for 30 days (or whatever time your choose). So, if you did something wrong during rebase, you can always go back to the original version, though you will hardly ever need that feature unless you do something really stupid... > BTW, as I undestood it, it is just a feature that can be implemented > in any VCS (if you have access to its internals). At least, not so simple. Have you heard about Mercurial? It is another DVCS, which in many aspects similar to Git, but the underlying backend is very different. I do not follow it very closely, but for a long time it did not have 'rebase' and users were advised to use Mercurial Queues instead, which is patch management system on top of Mercurial. While Git has its own implementations of patch management systems on top of Git such as StGit and recently TopGit, I do not think they come even close when it comes to easy to use in everyday work, especially if you do not want to be bothered with thinking about patch management. Much power of Git and its flexibility comes from clean separation of the underlying storage format and repository history. This makes 'rebase' almost trivial in Git (unless you have merges in rebased history and you try to preserve them), while with many other VCSes, those changes will require significant changes to the underlying storage, which may be difficult to implement safely and efficiently. The price that Git has to pay for its flexibility is the need to run the garbage collection to purge loose objects and compact all objects in one compressed pack... Dmitry ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Git drawbacks? 2009-11-09 18:47 ` B Smith-Mannschott 2009-11-09 21:06 ` Dmitry Potapov @ 2009-11-10 9:08 ` Dmitry Smirnov 1 sibling, 0 replies; 27+ messages in thread From: Dmitry Smirnov @ 2009-11-10 9:08 UTC (permalink / raw) To: git B Smith-Mannschott <bsmith.occs <at> gmail.com> writes: > You don't have to wait to comitting to your own branches, but do make > sure to run your usual builds and tests before pushing or asking > another to pull changes from you. Perhaps, I was not clear in my questions. I do not want to build and test to complete before I get back to my stashed or commited changes. I.e. I need to have 2 working trees (perhaps different, but from the same repository): one for build/test and one for another task. Dmitry ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Git drawbacks? 2009-11-06 17:51 ` Avery Pennarun 2009-11-06 18:57 ` david @ 2009-11-09 7:22 ` Dmitry Smirnov 1 sibling, 0 replies; 27+ messages in thread From: Dmitry Smirnov @ 2009-11-09 7:22 UTC (permalink / raw) To: git Avery Pennarun <apenwarr <at> gmail.com> writes: > 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.) Ok. Does that mean that new component2 and common component1 should leave on the new branch (having in mind that old component2 and component1 are still living on previous branch)? So, how many efforts will I need to get both component1 versions in sync (it is supposed that most of the changes in this component are common for both)? Is is supposed that having 2 branches for this component is cheaper (from development cycle POW)? > 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). I'll try to learn it. I suppose, both these tools (repo and git-subtree) are the indication of some contradiction between the tool and SCM practice (especially, for big projects). > > 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. Yes, I just wish to see this feature in some VCS. Why not Git? ;-) > 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. How offten do you use this info? I mean the whole stuff? ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Git drawbacks? 2009-11-06 16:17 Git drawbacks? Dmitry Smirnov 2009-11-06 16:49 ` Avery Pennarun @ 2009-11-11 10:21 ` Dmitry Smirnov 1 sibling, 0 replies; 27+ messages in thread From: Dmitry Smirnov @ 2009-11-11 10:21 UTC (permalink / raw) To: git Dmitry Smirnov <divis1969 <at> gmail.com> writes: Ok, I have heard a lot of perfect words about Git. I'm almost on your side :-) Just need some advice on (small for Git, I hope) problem. I'm trying to import P4 depot into Git (for mirroring purpose). It seems a non-trivial task with the current git-p4 script. Perhaps, I had selected a wrong way: i'm trying to import some client. In fact, as I said in previous mails, typically I have few similar clients. So, maybe it is simpler to import some set of branches (which I suppose a little bit simpler with git-p4). Unfortunaley, the directory structure of the depot differs from client's (i.e. working tree differs from repository tree). For example, //depot/component/version could be mapped to the <root_of_working_tree>/component. Thus if I import //depot/component/version1 and //depot/component/version2 as is, I should be able to checkout either version1 or version2. Note that there could be few components in the same working tree: //depot/component1/version1 (mapped to <root>/component1) //depot/component2/versionX (mapped to <root>/component2) //depot/component3/versionY (mapped to <root>/component3) With Perforce, there could also be a more complex mappings, but maybe we will discuss it later). Is there any way to make this mapping with Git? Should I invent some kind of tool like 'repo' or there is a simpler way? Dmitry ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2009-11-11 10:21 UTC | newest] Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-11-06 16:17 Git drawbacks? Dmitry Smirnov 2009-11-06 16:49 ` 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
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.