{"thread":{"id":"21504","subject":"Git drawbacks?","startedAt":"2009-11-06T16:17:30Z","lastAt":"2009-11-11T10:21:18Z","messageCount":27,"participants":["Dmitry Smirnov","Avery Pennarun","Jacob Helwig","david@lang.hm","Dmitry Potapov","B Smith-Mannschott","Paolo Bonzini"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"126988","messageId":"loom.20091106T160709-387@post.gmane.org","threadId":"21504","inReplyTo":null,"subject":"Git drawbacks?","fromName":"Dmitry Smirnov","fromEmail":"divis1969@gmail.com","sentAt":"2009-11-06T16:17:30Z","receivedAt":"2009-11-06T16:17:30Z","isPatch":false,"sender":{"key":"divis1969@gmail.com","avatar":null},"body":"Hi,\n\nSorry if I selected the wrong place to discuss the drawbacks of the Git. Just \npoint to the proper one...\n\nI'm just trying to select the best VCS for me personally.\nI have a very small experience with Git but I see is also not very sutable for \nme.\n\nFirst, it seems to be very hard to setup some really big project (like Android, \nfor example). Otherwise, why do they need to invent 'repo'? What purpose it \nsolves? It looks like it\n1. Integrates few subcomponents (projects) and checkout the code in the proper \nconfiguration. The question is why this is not the Git task? For me, it looks \nlike the ClearCase client spec.\n2.? What others (except integration with review tool)? \n\nThe next issue with git is its clone. Why do I need the whole set of revisions? \nWhy do I need to get 1GB of Android? You could say this should happen once. I \nwould agree but when I tried to resync the Android tree after 2 months, I was \nstruggled with many errors (both git and repo). Finally, I had decided to sync \nagain. :-)\nThere is one point against clone. The typical situation in my office is to have \nfew Perforce clients with the same or slightly different code. This is just \nwasting a space since you need them all but versions of many files are the same. \nI'm trying to imagine the same situation with Git. Are there any benefits? It \nseems, no. Moreover, I will have not only few working trees but few repository \nclones!\n\nIt is obvious that configuration management with Git is very difficult (for ex, \nhttp://groups.google.com/group/repo-\ndiscuss/browse_thread/thread/2fa368ed7cac5d79/64ced51656240ddc?\nlnk=gst&q=create+android+bare+repository#64ced51656240ddc)\n\nLet's consider the foolwing use case. Suppose I'm intending to create a new \nproduct that consists of specific versions (or branches) of some subcomponents \n(or directories). How can I do this with Git? Subsequent changes could either be \nsubmitted to the appropriate component branch or branched to the new one (this \nway is possible with Git, of course, if I will branch the code I need to this \nnew branch).\n\nSo, I'm wondering, why Git (or any other VCS) is not trying to solve these \nproblems? Perhaps, there is a simple solution with Git I'm not aware of?\n\nHere is the wish list for the VCS I would prefer:\n1. Atomit commits\n2. The possibility to get any slice of the code repository with the possibility \nto commit my changes on tip or on separate branch.\n3. The minimum footprint of the same code on my local machine.\n4. No code/history on my machine untill I really need it.\n5. Easy mirroring and replication\n\nI would say, ClearCase might be my favorite if it is not commercial. :-)\n\nDmitry\n"},{"id":"126989","messageId":"32541b130911060849s2d8f13f5sb9b8390f075f8d15@mail.gmail.com","threadId":"21504","inReplyTo":"loom.20091106T160709-387@post.gmane.org","subject":"Re: Git drawbacks?","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2009-11-06T16:49:36Z","receivedAt":"2009-11-06T16:49:36Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Fri, Nov 6, 2009 at 11:17 AM, Dmitry Smirnov wrote:\n> Here is the wish list for the VCS I would prefer:\n> 1. Atomit commits\n> 2. The possibility to get any slice of the code repository with the possibility\n> to commit my changes on tip or on separate branch.\n> 3. The minimum footprint of the same code on my local machine.\n> 4. No code/history on my machine untill I really need it.\n> 5. Easy mirroring and replication\n>\n> I would say, ClearCase might be my favorite if it is not commercial. :-)\n\n#1 and #5 are features of any DVCS, so git already has them. #2, 3,\nand 4 are all just saying the same thing: \"I can't afford the disk\nspace to store the entire repo.\" Are you sure this is true, or is it\na preconception? Even a 1GB repository is tiny by modern disk\nstandards.\n\nMy (limited) experience with ClearCase is that it's so slow that you'd\ndo *anything* to track fewer files in your working copy, so they put a\nlot of work into exactly that, and no work into performance. This\nlousy performance isn't the case in git (except in Windows). Are you\nusing Windows, by chance?\n\nHave fun,\n\nAvery\n"},{"id":"126991","messageId":"loom.20091106T180313-750@post.gmane.org","threadId":"21504","inReplyTo":"32541b130911060849s2d8f13f5sb9b8390f075f8d15@mail.gmail.com","subject":"Re: Git drawbacks?","fromName":"Dmitry Smirnov","fromEmail":"divis1969@gmail.com","sentAt":"2009-11-06T17:35:46Z","receivedAt":"2009-11-06T17:35:46Z","isPatch":false,"sender":{"key":"divis1969@gmail.com","avatar":null},"body":"> > Here is the wish list for the VCS I would prefer:\n> > 1. Atomit commits\n> > 2. The possibility to get any slice of the code repository with the \npossibility\n> > to commit my changes on tip or on separate branch.\n> > 3. The minimum footprint of the same code on my local machine.\n> > 4. No code/history on my machine untill I really need it.\n> > 5. Easy mirroring and replication\n> >\n> > I would say, ClearCase might be my favorite if it is not commercial. \n> \n> #1 and #5 are features of any DVCS, so git already has them. #2, 3,\n> and 4 are all just saying the same thing:\n\nNo, #2 is about the repository slicing, branching, merging (SCM in other words). \nLet's suppose I have the product that have 2 directories: component1 and \ncomponent2. They were developing together for previous product (on the same \nbranch, for example). Now, I would like to have component1 and replace \ncomponent2 with some 3rd party component. What should I do with Git to get this? \nOr maybe I wish to stick with some version of component2 and provide only bug \nfixes for this product...\nOr let's take a look at GDB. They are using binutils which are in separate \nrepository (they use CVS, but let's imagine they use Git). How many effors they \nwill need for SCM? For example, they would prefer to stick to some stable \nversion/branch of the binutils but should be able to commit bug fixes.\n\nOnce again, perhaps there is some way to do this with Git? I did not yet find \nit.\n\n> \"I can't afford the disk\n> space to store the entire repo.\" Are you sure this is true, or is it\n> a preconception? Even a 1GB repository is tiny by modern disk\n> standards.\n\noh, yes, since we have big drives and fast internet, we do not have to worry \nabout space and download time... :-)\n\n> My (limited) experience with ClearCase is that it's so slow that you'd\n> do *anything* to track fewer files in your working copy, so they put a\n> lot of work into exactly that, and no work into performance.\n\nThis probably true. Thought I did not have a lot of problems with it unless I \nuse GUI.\n\n> This\n> lousy performance isn't the case in git (except in Windows). Are you\n> using Windows, by chance?\n\nyes. I did not yet noticed any performance problems with Git on windows, except \na sync/download time (for android, mostly)\n"},{"id":"126992","messageId":"8c9a060911060941w2eea5b04m1bd8dfe7a4d5ea70@mail.gmail.com","threadId":"21504","inReplyTo":"loom.20091106T180313-750@post.gmane.org","subject":"Re: Git drawbacks?","fromName":"Jacob Helwig","fromEmail":"jacob.helwig@gmail.com","sentAt":"2009-11-06T17:41:05Z","receivedAt":"2009-11-06T17:41:05Z","isPatch":false,"sender":{"key":"jacob.helwig@gmail.com","avatar":"https://avatars.githubusercontent.com/u/14557?v=4"},"body":"On Fri, Nov 6, 2009 at 09:35, Dmitry Smirnov wrote:\n> No, #2 is about the repository slicing, branching, merging (SCM in other words).\n> Let's suppose I have the product that have 2 directories: component1 and\n> component2. They were developing together for  previous product (on the same\n> branch, for example). Now, I would like to have component1 and replace\n> component2 with some 3rd party component. What should I do with Git to get this?\n> Or maybe I wish to stick with some version of component2 and provide only bug\n> fixes for this product...\n> Or let's take a look at GDB. They are using binutils which are in separate\n> repository (they use CVS, but let's imagine they use Git). How many effors they\n> will need for SCM? For example, they would prefer to stick to some stable\n> version/branch of the binutils but should be able to commit bug fixes.\n>\n> Once again, perhaps there is some way to do this with Git? I did not yet find\n> it.\n>\n\nSounds like you want submodules. Check out the git-submodule(1) manpage.\n"},{"id":"126993","messageId":"32541b130911060951q3358ce9ahe28fb0cf902853f2@mail.gmail.com","threadId":"21504","inReplyTo":"loom.20091106T180313-750@post.gmane.org","subject":"Re: Git drawbacks?","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2009-11-06T17:51:42Z","receivedAt":"2009-11-06T17:51:42Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Fri, Nov 6, 2009 at 12:35 PM, Dmitry Smirnov wrote:\n> No, #2 is about the repository slicing, branching, merging (SCM in other words).\n> Let's suppose I have the product that have 2 directories: component1 and\n> component2. They were developing together for  previous product (on the same\n> branch, for example). Now, I would like to have component1 and replace\n> component2 with some 3rd party component. What should I do with Git to get this?\n> Or maybe I wish to stick with some version of component2 and provide only bug\n> fixes for this product...\n\nThere are three methods I know of to manage this:\n\n1) Just commit whatever version of a subproject you want as a subtree\nof your current project, and if you want to replace/delete/upgrade it,\njust do that. (You rarely want to track the actual *history* of the\nthird party tool, just the history of versions *you* used, which is\neasy to do.)\n\n2) Use git-submodule to link repositories together. (Arguably, one\nmajor reason 'repo' was written is that git-submodule is too\ncomplicated, though.)\n\n3) Try my git-subtree tool, which basically makes it easier to\nsplit/join repositories (similar to #1) without losing the history\n(similar to #2).\n\n>> This\n>> lousy performance isn't the case in git (except in Windows).  Are you\n>> using Windows, by chance?\n>\n> yes. I did not yet noticed any performance problems with Git on windows, except\n> a sync/download time (for android, mostly)\n\nBasically, performance is linear with the number of files in your\nrepo. If you can check out just a \"slice\" of your repo (say 10% of\nthe whole), you'll have faster performance (eg. 10x) from any VCS.\n\ngit on Linux is so fast that this isn't very necessary most of the\ntime. But git on Windows isn't really any faster than other VCSes on\nWindows, so the time-per-file is much greater, and thus the penalty\nfor huge repositories is much worse. Doing things like switching\nbranches, which is near-instantaneous on Linux even with tens of\nthousands of files, really crawls on Windows.\n\nSo I can see an argument that Windows users would want arbitrary\n\"slices\" much more often than Linux+git users, but I think this is\nlargely due to performance, not because people really *want* to be\nstuck with a restricted view of the repo.\n\nHave fun,\n\nAvery\n"},{"id":"126999","messageId":"alpine.DEB.2.00.0911061051540.3216@asgard.lang.hm","threadId":"21504","inReplyTo":"32541b130911060951q3358ce9ahe28fb0cf902853f2@mail.gmail.com","subject":"Re: Git drawbacks?","fromName":"","fromEmail":"david@lang.hm","sentAt":"2009-11-06T18:57:58Z","receivedAt":"2009-11-06T18:57:58Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Fri, 6 Nov 2009, Avery Pennarun wrote:\n\n>>> This\n>>> lousy performance isn't the case in git (except in Windows).  Are you\n>>> using Windows, by chance?\n>>\n>> yes. I did not yet noticed any performance problems with Git on windows, except\n>> a sync/download time (for android, mostly)\n>\n> Basically, performance is linear with the number of files in your\n> repo. If you can check out just a \"slice\" of your repo (say 10% of\n> the whole), you'll have faster performance (eg. 10x) from any VCS.\n>\n> git on Linux is so fast that this isn't very necessary most of the\n> time. But git on Windows isn't really any faster than other VCSes on\n> Windows, so the time-per-file is much greater, and thus the penalty\n> for huge repositories is much worse. Doing things like switching\n> branches, which is near-instantaneous on Linux even with tens of\n> thousands of files, really crawls on Windows.\n\nbut is that scale based on the number of files you are tracking, or the \nnumber of revisions that exist in the repository.\n\ni.e. 10,000 files in the source code with 10 revisions each vs 1,000 \nfiles with 100 revisions each.\n\nmy understanding of git is that it's the number of files, with very little \nimpact due to having lots of revisions. so eliminating 90 revisions of \neach file would not significantly speed up git in the second case.\n\ngoing back to the initial poster's comments. if the android repo is 1G, \neliminating the history will probably have significantly less impact than \nyou expect it to. for source code the compression factor that git is able \nto get is spectacular. I've seen several cases posted with large projects \nwhere the full repo with ALL history is <2x the size of a tar.gz of the \nlatest release.\n\nDavid Lang\n\n> So I can see an argument that Windows users would want arbitrary\n> \"slices\" much more often than Linux+git users, but I think this is\n> largely due to performance, not because people really *want* to be\n> stuck with a restricted view of the repo.\n>\n> Have fun,\n>\n> Avery\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n>"},{"id":"127124","messageId":"loom.20091109T080510-448@post.gmane.org","threadId":"21504","inReplyTo":"32541b130911060951q3358ce9ahe28fb0cf902853f2@mail.gmail.com","subject":"Re: Git drawbacks?","fromName":"Dmitry Smirnov","fromEmail":"divis1969@gmail.com","sentAt":"2009-11-09T07:22:17Z","receivedAt":"2009-11-09T07:22:17Z","isPatch":false,"sender":{"key":"divis1969@gmail.com","avatar":null},"body":"Avery Pennarun gmail.com> writes:\n\n> There are three methods I know of to manage this:\n> \n> 1) Just commit whatever version of a subproject you want as a subtree\n> of your current project, and if you want to replace/delete/upgrade it,\n> just do that. (You rarely want to track the actual *history* of the\n> third party tool, just the history of versions *you* used, which is\n> easy to do.)\n\nOk. Does that mean that new component2 and common component1 should leave on the \nnew branch (having in mind that old component2 and component1 are still living \non previous branch)? So, how many efforts will I need to get both component1 \nversions in sync (it is supposed that most of the changes in this component are \ncommon for both)? Is is supposed that having 2 branches for this component is \ncheaper (from development cycle POW)?\n\n> 2) Use git-submodule to link repositories together. (Arguably, one\n> major reason 'repo' was written is that git-submodule is too\n> complicated, though.)\n\n> 3) Try my git-subtree tool, which basically makes it easier to\n> split/join repositories (similar to #1) without losing the history\n> (similar to #2).\n\nI'll try to learn it.\n\nI suppose, both these tools (repo and git-subtree) are the indication of some \ncontradiction between the tool and SCM practice (especially, for big projects).\n\n> \n> Basically, performance is linear with the number of files in your\n> repo. If you can check out just a \"slice\" of your repo (say 10% of\n> the whole), you'll have faster performance (eg. 10x) from any VCS.\n\nYes, I just wish to see this feature in some VCS. Why not Git? ;-)\n\n> So I can see an argument that Windows users would want arbitrary\n> \"slices\" much more often than Linux+git users, but I think this is\n> largely due to performance, not because people really *want* to be\n> stuck with a restricted view of the repo.\n\nHow offten do you use this info? I mean the whole stuff?\n"},{"id":"127127","messageId":"loom.20091109T084539-720@post.gmane.org","threadId":"21504","inReplyTo":"alpine.DEB.2.00.0911061051540.3216@asgard.lang.hm","subject":"Re: Git drawbacks?","fromName":"Dmitry Smirnov","fromEmail":"divis1969@gmail.com","sentAt":"2009-11-09T07:53:24Z","receivedAt":"2009-11-09T07:53:24Z","isPatch":false,"sender":{"key":"divis1969@gmail.com","avatar":null},"body":" lang.hm> writes:\n\n> going back to the initial poster's comments. if the android repo is 1G, \n> eliminating the history will probably have significantly less impact than \n> you expect it to. \n\nDo you have 2 or more copies of the same repository at the same time?\nIf yes, can I skip cloning new copy from network? \nOr even skip cloning it at all? \nIs it possible with Git to chekout into two (few) working trees?\n"},{"id":"127139","messageId":"8c9a060911090634p4e036208mfb3160eb4c4430e9@mail.gmail.com","threadId":"21504","inReplyTo":"loom.20091109T084539-720@post.gmane.org","subject":"Re: Git drawbacks?","fromName":"Jacob Helwig","fromEmail":"jacob.helwig@gmail.com","sentAt":"2009-11-09T14:34:47Z","receivedAt":"2009-11-09T14:34:47Z","isPatch":false,"sender":{"key":"jacob.helwig@gmail.com","avatar":"https://avatars.githubusercontent.com/u/14557?v=4"},"body":"On Sun, Nov 8, 2009 at 23:53, Dmitry Smirnov wrote:\n>   lang.hm> writes:\n>\n>> going back to the initial poster's comments. if the android repo is 1G,\n>> eliminating the history will probably have significantly less impact than\n>> you expect it to.\n>\n> Do you have 2 or more copies of the same repository at the same time?\n> If yes, can I skip cloning new copy from network?\n> Or even skip cloning it at all?\n> Is it possible with Git to chekout into two (few) working trees?\n>\n\nTake a look at git-new-workdir. It's in the contrib directory of\ngit.git. This lets you skip re-cloning the same repository over\nagain, if you want a new working copy of it. It'll also give you some\nspace savings, by sharing certain key things in the .git directory\nbetween working copies, by using symlinks.\n\nIt does have a few caveats, however. If you have the same branch\nchecked out in two different working copies created using\ngit-new-workdir, and update the branch in one of them, then the other\nwill appear to have a bunch of staged changes, even though you haven't\ndone anything in it. The branch pointer will have been updated out\nfrom underneath it, and it will be \"confused\". As long as you\nremember not to update a branch that is checked out in more than one\nplace on your machine, you'll never notice, thuogh.\n"},{"id":"127166","messageId":"20091109154816.GH27126@dpotapov.dyndns.org","threadId":"21504","inReplyTo":"loom.20091109T084539-720@post.gmane.org","subject":"Re: Git drawbacks?","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2009-11-09T15:48:16Z","receivedAt":"2009-11-09T15:48:16Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Mon, Nov 09, 2009 at 07:53:24AM +0000, Dmitry Smirnov wrote:\n> lang.hm> writes:\n> \n> > going back to the initial poster's comments. if the android repo is 1G, \n> > eliminating the history will probably have significantly less impact than \n> > you expect it to. \n> \n> Do you have 2 or more copies of the same repository at the same time?\n> If yes, can I skip cloning new copy from network? \n> Or even skip cloning it at all? \n> Is it possible with Git to chekout into two (few) working trees?\n\nJacob has already mentioned git-new-workdir from Git contrib, but\nthere are other ways to do the same or almost the same....\n\nFirst of all, you can always copy your directory and thus creating\nanother clone. It is very simple and straightforward solution, but\nit takes extra space due an extra copy of the repository. Usually,\nit is not a big issue in practice, because your working tree tends\nto be larger than the repository itself...\n\nHowever, if you want to save disk space, you can use local clone. When\nyou clone your (like: git clone old_dir new_dir), git tries to use hard\nlinks if it is possible. So, it may save disk space. However, if you\nrepack your original repo then a new pack will be created, and saving\nfrom using the hard link will be lost. To prevent that from happening,\nyou can tell to the garbage collector to keep the main existing pack by\ncreate a file that has the same name as the pack file plus the .keep\nsuffix:\n\n touch .git/objects/pack-.keep\n\nthen all changes will be put into a separate pack.\n\nThere is one more way to save disk space is to use git clone --shared.\nIt does not require hard links, but it has some caveats. If you want to\nuse it, then read the documentation carefully and make sure you understand\nall implications.\n\n\nActually, in most use cases, there is no reason to have more than one\nworking tree. Git is designed to work well with plenty branches and one\nworking tree. So, switching between two branches and recompiling a few\nchanged files is much faster then going to another directory and try to\nwork there, because when you go to another directory, you may hit cold\ncache and disk is *slow*... Another thing is that you can do a lot of\nthings without checking out some branch. You can grep any revision in\nyour repository, you can insect any file from it, etc and you do not\nhave to checkout this revision in your working tree.\n\n\nDmitry\n"},{"id":"127167","messageId":"loom.20091109T165620-587@post.gmane.org","threadId":"21504","inReplyTo":"8c9a060911090634p4e036208mfb3160eb4c4430e9@mail.gmail.com","subject":"Re: Git drawbacks?","fromName":"Dmitry Smirnov","fromEmail":"divis1969@gmail.com","sentAt":"2009-11-09T15:59:32Z","receivedAt":"2009-11-09T15:59:32Z","isPatch":false,"sender":{"key":"divis1969@gmail.com","avatar":null},"body":"Jacob Helwig gmail.com> writes:\n\n> It does have a few caveats, however. If you have the same branch\n> checked out in two different working copies created using\n>...\n> place on your machine, you'll never notice, thuogh.\n\n\nSo, i cannot recover from this situation by upmerging to the new head?\n"},{"id":"127169","messageId":"loom.20091109T170054-451@post.gmane.org","threadId":"21504","inReplyTo":"20091109154816.GH27126@dpotapov.dyndns.org","subject":"Re: Git drawbacks?","fromName":"Dmitry Smirnov","fromEmail":"divis1969@gmail.com","sentAt":"2009-11-09T16:11:48Z","receivedAt":"2009-11-09T16:11:48Z","isPatch":false,"sender":{"key":"divis1969@gmail.com","avatar":null},"body":"Dmitry Potapov gmail.com> writes:\n\n\n> Actually, in most use cases, there is no reason to have more than one\n> working tree. Git is designed to work well with plenty branches and one\n> working tree. So, switching between two branches and recompiling a few\n> changed files is much faster then going to another directory and try to\n> work there, because when you go to another directory, you may hit cold\n> cache and disk is *slow*... Another thing is that you can do a lot of\n> things without checking out some branch. You can grep any revision in\n> your repository, you can insect any file from it, etc and you do not\n> have to checkout this revision in your working tree.\n\nShouldn't I even worry about my not yet commited changes before switching the \nbranch?\n\nI would say that this approach does not work if the build and test could take\nsignificant time. While in CR fix I don't want to wait for a build to complete\nbefore I countinue with another bug/fix. That is why I'm curious about \nfew working trees...\n"},{"id":"127170","messageId":"8c9a060911090821h678ace9bg978c185bda94e3f4@mail.gmail.com","threadId":"21504","inReplyTo":"loom.20091109T165620-587@post.gmane.org","subject":"Re: Git drawbacks?","fromName":"Jacob Helwig","fromEmail":"jacob.helwig@gmail.com","sentAt":"2009-11-09T16:21:28Z","receivedAt":"2009-11-09T16:21:28Z","isPatch":false,"sender":{"key":"jacob.helwig@gmail.com","avatar":"https://avatars.githubusercontent.com/u/14557?v=4"},"body":"On Mon, Nov 9, 2009 at 07:59, Dmitry Smirnov wrote:\n> Jacob Helwig gmail.com> writes:\n>\n>> It does have a few caveats, however.  If you have the same branch\n>> checked out in two different working copies created using\n>>...\n>> place on your machine, you'll never notice, thuogh.\n>\n>\n> So, i cannot recover from this situation by upmerging to the new head?\n>\n\nIf you haven't actually made any changes in the second checkout of the\nbranch, then recovery is a simple reset --hard. If you have made any\nchanges in that working copy, then recovery is a bit more complicated,\nand it's probably best if I leave that explanation up to someone else,\nsince I'm very careful to avoid this situation in the first place, and\nhave never actually had to recover from it.\n"},{"id":"127181","messageId":"20091109183404.GI27126@dpotapov.dyndns.org","threadId":"21504","inReplyTo":"loom.20091109T170054-451@post.gmane.org","subject":"Re: Git drawbacks?","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2009-11-09T18:34:04Z","receivedAt":"2009-11-09T18:34:04Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Mon, Nov 09, 2009 at 04:11:48PM +0000, Dmitry Smirnov wrote:\n> Dmitry Potapov gmail.com> writes:\n> \n> \n> > Actually, in most use cases, there is no reason to have more than one\n> > working tree. Git is designed to work well with plenty branches and one\n> > working tree. So, switching between two branches and recompiling a few\n> > changed files is much faster then going to another directory and try to\n> > work there, because when you go to another directory, you may hit cold\n> > cache and disk is *slow*... Another thing is that you can do a lot of\n> > things without checking out some branch. You can grep any revision in\n> > your repository, you can insect any file from it, etc and you do not\n> > have to checkout this revision in your working tree.\n> \n> Shouldn't I even worry about my not yet commited changes before switching the \n> branch?\n\nYou probably want to use 'git stash save' and when you return back you\njust do 'git stash pop'. Also, keep in mind that you can amend any\nprevious commit using 'git commit --amend'.\n\n> \n> I would say that this approach does not work if the build and test could take\n> significant time.\n\nYes, but then I do not see any reason to do any time consuming building\nand testing in the working tree. I create a snapshot of the interesting\nversion using 'git archive' and then run build&test on it... In this\nway, I can make sure that the archive I deliver is tested properly. If\nyou do your testing in the working tree, sometimes uncommitted or some\nother files that are left over from previous builds may affect result.\nSo, if it takes considerable time anyhow, why do not do clean build and\ntest? And if you worry about compilation time, you can use ccache.\n\n\nDmitry\n"},{"id":"127185","messageId":"28c656e20911091047r353e9451hd856b99541fbd5ff@mail.gmail.com","threadId":"21504","inReplyTo":"loom.20091109T170054-451@post.gmane.org","subject":"Re: Git drawbacks?","fromName":"B Smith-Mannschott","fromEmail":"bsmith.occs@gmail.com","sentAt":"2009-11-09T18:47:08Z","receivedAt":"2009-11-09T18:47:08Z","isPatch":false,"sender":{"key":"bsmith.occs@gmail.com","avatar":"https://gravatar.com/avatar/46449e07c27bb8a30e4d50c08859f7210d47f6e84526b0a3b903641231dfc1bd?d=mp&s=160"},"body":"On Mon, Nov 9, 2009 at 17:11, Dmitry Smirnov wrote:\n> Dmitry Potapov gmail.com> writes:\n>\n>\n>> Actually, in most use cases, there is no reason to have more than one\n>> working tree. Git is designed to work well with plenty branches and one\n>> working tree. So, switching between two branches and recompiling a few\n>> changed files is much faster then going to another directory and try to\n>> work there, because when you go to another directory, you may hit cold\n>> cache and disk is *slow*... Another thing is that you can do a lot of\n>> things without checking out some branch. You can grep any revision in\n>> your repository, you can insect any file from it, etc and you do not\n>> have to checkout this revision in your working tree.\n>\n> Shouldn't I even worry about my not yet commited changes before switching the\n> branch?\n\ncommit them before you switch. you could:\n\n- commit them to the current branch before you switch the branch.\n- commit them to a new branch before you switch\n- use git stash to move your changes aside.\n\n> I would say that this approach does not work if the build and test could take\n> significant time. While in CR fix I don't want to wait for a build to complete\n> before I countinue with another bug/fix. That is why I'm curious about\n> few working trees...\n\nYou don't have to wait to comitting to your own branches, but do make\nsure to run your usual builds and tests before pushing or asking\nanother to pull changes from you.\n\n// Ben\n"},{"id":"127200","messageId":"20091109210631.GJ27126@dpotapov.dyndns.org","threadId":"21504","inReplyTo":"28c656e20911091047r353e9451hd856b99541fbd5ff@mail.gmail.com","subject":"Re: Git drawbacks?","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2009-11-09T21:06:31Z","receivedAt":"2009-11-09T21:06:31Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Mon, Nov 09, 2009 at 07:47:08PM +0100, B Smith-Mannschott wrote:\n> \n> You don't have to wait to comitting to your own branches, but do make\n> sure to run your usual builds and tests before pushing or asking\n> another to pull changes from you.\n\nYes, it is one most useful feature of Git that you can commit (save)\nyour changes immediately but amend them later. This helps a lot to\nmake changes smaller, cleaner and easier to review.\n\nWith many other VCS, a typical policy is that you do not commit your\nchanges unless you have finished and tested them. But it means that\nyour changes are not committed and stored only in the work tree for\na long time. Moreover, when you eventually decide that they are good\nenough to commit, you will produce a huge patch, which will be difficult\nto review or to bisect history later.\n\nWith Git you do not have to worry about testing when you can commit your\nchanges. Typically I would commit some my changes as I progress to my\ngoal, but later I will review all commits. Probably, squash some changes\nwith fixes, clean up some other, add better explanations of what is done\nand why, etc... But I do not have to worry about all those trifles as\nI write code to see if some feature is worth or not, if this solution\nworks or I should try something else...\n\nSo, you can always commit your changes as your progress to your goal and\nreview amend them later before publishing. This means that you can have\nas many work-in-progress branches as you wish, and you do not need a\nseparate work tree for each of them -- everything can be stored in the\nrepository, and you can go to another computer, issue 'git fetch' and\ncontinue your work at the exact point where you left it. So, it is very\nflexible.\n\n\nDmitry\n"},{"id":"127227","messageId":"loom.20091110T092404-595@post.gmane.org","threadId":"21504","inReplyTo":"20091109183404.GI27126@dpotapov.dyndns.org","subject":"Re: Git drawbacks?","fromName":"Dmitry Smirnov","fromEmail":"divis1969@gmail.com","sentAt":"2009-11-10T08:31:48Z","receivedAt":"2009-11-10T08:31:48Z","isPatch":false,"sender":{"key":"divis1969@gmail.com","avatar":null},"body":"Dmitry Potapov gmail.com> writes:\n \n> Yes, but then I do not see any reason to do any time consuming building\n> and testing in the working tree. I create a snapshot of the interesting\n> version using 'git archive' and then run build&test on it... In this\n> way, I can make sure that the archive I deliver is tested properly. If\n> you do your testing in the working tree, sometimes uncommitted or some\n> other files that are left over from previous builds may affect result.\n> So, if it takes considerable time anyhow, why do not do clean build and\n> test? And if you worry about compilation time, you can use ccache.\n\nIt is not clear for me. Yes, I have to get some fixed version to reproduce\nthe bug reported by someone. Then I need to fix it and commit the change \nback (on the head). Also, it is obvious to reproduce the issue and \ntest the fix on the tip. Can do this with 'git archive'?\nBTW, doesn't 'git archive' sync to some version that I probably already \nhave in other clone? ;-)\n"},{"id":"127228","messageId":"loom.20091110T093334-810@post.gmane.org","threadId":"21504","inReplyTo":"20091109210631.GJ27126@dpotapov.dyndns.org","subject":"Re: Git drawbacks?","fromName":"Dmitry Smirnov","fromEmail":"divis1969@gmail.com","sentAt":"2009-11-10T08:51:53Z","receivedAt":"2009-11-10T08:51:53Z","isPatch":false,"sender":{"key":"divis1969@gmail.com","avatar":null},"body":"Dmitry Potapov gmail.com> writes:\n\n> With many other VCS, a typical policy is that you do not commit your\n> changes unless you have finished and tested them. But it means that\n> your changes are not committed and stored only in the work tree for\n> a long time. Moreover, when you eventually decide that they are good\n> enough to commit, you will produce a huge patch, which will be difficult\n> to review or to bisect history later.\n\noh, yes. but this is just a policy. You can make your changes on your \nbranch and commit them (for example, for review). Later someone just \nneed to integrate it on original branch. The same as with Git, \nisn't it? The problem is just a price to branch.\nBTW, once I started to talk about review, we can see that most \n\"benefits\" of DVCS go away... Just because you still need some \ncentral storage to save the record of this review that should \nbe available for SQA later...\n \n> So, you can always commit your changes as your progress to your goal and\n> review amend them later before publishing. This means that you can have\n> as many work-in-progress branches as you wish, and you do not need a\n> separate work tree for each of them -- everything can be stored in the\n> repository, and you can go to another computer, issue 'git fetch' and\n> continue your work at the exact point where you left it. So, it is very\n> flexible.\n\nAs for me, I would not to have more than 4-5 such deferred changes in the same \nrepository. Otherwise, I will be entangled finally :-)\n"},{"id":"127231","messageId":"loom.20091110T100345-116@post.gmane.org","threadId":"21504","inReplyTo":"28c656e20911091047r353e9451hd856b99541fbd5ff@mail.gmail.com","subject":"Re: Git drawbacks?","fromName":"Dmitry Smirnov","fromEmail":"divis1969@gmail.com","sentAt":"2009-11-10T09:08:30Z","receivedAt":"2009-11-10T09:08:30Z","isPatch":false,"sender":{"key":"divis1969@gmail.com","avatar":null},"body":"B Smith-Mannschott gmail.com> writes:\n \n> You don't have to wait to comitting to your own branches, but do make\n> sure to run your usual builds and tests before pushing or asking\n> another to pull changes from you.\n\nPerhaps, I was not clear in my questions. \nI do not want to build and test to complete before I get back to my stashed\nor commited changes. I.e. I need to have 2 working trees (perhaps different, but \nfrom the same repository): one for build/test and one for another task.\n\nDmitry\n"},{"id":"127244","messageId":"20091110134540.GK27126@dpotapov.dyndns.org","threadId":"21504","inReplyTo":"loom.20091110T092404-595@post.gmane.org","subject":"Re: Git drawbacks?","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2009-11-10T13:45:40Z","receivedAt":"2009-11-10T13:45:40Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Tue, Nov 10, 2009 at 08:31:48AM +0000, Dmitry Smirnov wrote:\n> Dmitry Potapov gmail.com> writes:\n> \n> > Yes, but then I do not see any reason to do any time consuming building\n> > and testing in the working tree. I create a snapshot of the interesting\n> > version using 'git archive' and then run build&test on it... In this\n> > way, I can make sure that the archive I deliver is tested properly. If\n> > you do your testing in the working tree, sometimes uncommitted or some\n> > other files that are left over from previous builds may affect result.\n> > So, if it takes considerable time anyhow, why do not do clean build and\n> > test? And if you worry about compilation time, you can use ccache.\n> \n> It is not clear for me. Yes, I have to get some fixed version to reproduce\n> the bug reported by someone. Then I need to fix it and commit the change \n> back (on the head). Also, it is obvious to reproduce the issue and \n> test the fix on the tip. Can do this with 'git archive'?\n> BTW, doesn't 'git archive' sync to some version that I probably already \n> have in other clone? ;-)\n\nI am not sure I understood your question. What 'git archive' does is to\ncreate a tar or zip archive or any version that you specify. So, you can\nuse it to export the snapshot of any version to a temporary directory\nfor testing if this testing takes a noticeable time and you want to be\nable to work on something else in meanwhile. If necessary, you can\ncreate a temporary branch starting at the intesting point and to add\nsome commits there (such as a new test case to reproduce the problem)\nand then run test on it. Later, you can either rebase or merge these\ncommits to any branch that needs them.\n\nActually, when someone reports a problem, I do not use 'git archive'\nbecause I write a test case for this bug and run it alone, and it does\nnot take much time to run it. But periodically (a few times a day), I\nrun the full test suit, which takes considerable amount of time, so I\nrun this test outside of my working directory, using 'git archive'.\n\n\nDmitry\n"},{"id":"127246","messageId":"20091110140428.GL27126@dpotapov.dyndns.org","threadId":"21504","inReplyTo":"loom.20091110T093334-810@post.gmane.org","subject":"Re: Git drawbacks?","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2009-11-10T14:04:28Z","receivedAt":"2009-11-10T14:04:28Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Tue, Nov 10, 2009 at 08:51:53AM +0000, Dmitry Smirnov wrote:\n> Dmitry Potapov gmail.com> writes:\n> \n> > With many other VCS, a typical policy is that you do not commit your\n> > changes unless you have finished and tested them. But it means that\n> > your changes are not committed and stored only in the work tree for\n> > a long time. Moreover, when you eventually decide that they are good\n> > enough to commit, you will produce a huge patch, which will be difficult\n> > to review or to bisect history later.\n> \n> oh, yes. but this is just a policy. You can make your changes on your \n> branch and commit them (for example, for review). Later someone just \n> need to integrate it on original branch. The same as with Git, \n> isn't it? The problem is just a price to branch.\n\nWith some VCSes, it is not just the cost of branch, but it is also name\npollution that happens when many branches created. But even the cost of\nbranch creation alone may be high enough to make creating small feature\nbranches impractical. You can try to force that on developers, but they\nwill be frustrated with that pretty soon... And then if you really want\nto have good and clean history, you need more than just a branch. You\nshould be able to amend your previous commits while you work on some\nfeature. With Git, it is trivial, you just run 'git rebase -i' and may\nedit some previous commits, correct comments, squash fix-ups, etc...\nHow can you model that? By creating another branch and moving patches\nto it by hands... Well, it is not very productive time spending, and\nthe cost of branch becomes even more prominent.\n\n> BTW, once I started to talk about review, we can see that most \n> \"benefits\" of DVCS go away... Just because you still need some \n> central storage to save the record of this review that should \n> be available for SQA later...\n\nI do not see how any benefit go away because of having some central\nstorage. Most benefits are not due to that you do not have it, but due\nto cheap branching, easy mirroring, and flexibility in what you want to\nstore and where...\n\n> \n> > So, you can always commit your changes as your progress to your goal and\n> > review amend them later before publishing. This means that you can have\n> > as many work-in-progress branches as you wish, and you do not need a\n> > separate work tree for each of them -- everything can be stored in the\n> > repository, and you can go to another computer, issue 'git fetch' and\n> > continue your work at the exact point where you left it. So, it is very\n> > flexible.\n> \n> As for me, I would not to have more than 4-5 such deferred changes in the same \n> repository. Otherwise, I will be entangled finally :-)\n\nA quick look at \"What's cooking in git.git\" that Junio posted a few days\nago reveals that there are at least 43 branches that are cooking now and\nthe total number of branches that have been merged to 'master' over all\nGit history is 3290. And Git is not the largest project out there...\n\n\nDmitry\n"},{"id":"127247","messageId":"loom.20091110T150242-922@post.gmane.org","threadId":"21504","inReplyTo":"20091110134540.GK27126@dpotapov.dyndns.org","subject":"Re: Git drawbacks?","fromName":"Dmitry Smirnov","fromEmail":"divis1969@gmail.com","sentAt":"2009-11-10T14:14:32Z","receivedAt":"2009-11-10T14:14:32Z","isPatch":false,"sender":{"key":"divis1969@gmail.com","avatar":null},"body":"Dmitry Potapov gmail.com> writes:\n\n> I am not sure I understood your question. What 'git archive' does is to\n> create a tar or zip archive or any version that you specify. So, you can\n> use it to export the snapshot of any version to a temporary directory\n> for testing if this testing takes a noticeable time and you want to be\n> able to work on something else in meanwhile. If necessary, you can\n> create a temporary branch starting at the intesting point and to add\n> some commits there (such as a new test case to reproduce the problem)\n> and then run test on it. Later, you can either rebase or merge these\n> commits to any branch that needs them.\n\nOk, I got it. So the scenario is something like that:\n1. Stash or commit my current changes\n2. Sync (reset or checkout) to some other version/branch\n3. Create temporary branch \n4. Edit and Commit\n5. \"git archive\" to get snapshot\n6. Get back to original change\n\nThis looks reasonable. Until you need to correct the fix and test it again.\n\nPerhaps, I have to explain why fix/test cycle is so long. I'm working on mobile \nplatform development. It is not so modular, so I need to build the whole image, \nthen flash the mobile and test it in a real network. This takes much time and \nneed much disk space (about 2GB of source files. In fact, significant number of \nthese files are not needed for the build, but it is too hard to force CM \nengineers to fix this :-) )\n"},{"id":"127248","messageId":"loom.20091110T154312-665@post.gmane.org","threadId":"21504","inReplyTo":"20091110140428.GL27126@dpotapov.dyndns.org","subject":"Re: Git drawbacks?","fromName":"Dmitry Smirnov","fromEmail":"divis1969@gmail.com","sentAt":"2009-11-10T14:54:43Z","receivedAt":"2009-11-10T14:54:43Z","isPatch":false,"sender":{"key":"divis1969@gmail.com","avatar":null},"body":"Dmitry Potapov gmail.com> writes:\n\n> And then if you really want\n> to have good and clean history, you need more than just a branch. You\n> should be able to amend your previous commits while you work on some\n> feature. With Git, it is trivial, you just run 'git rebase -i' and may\n> edit some previous commits, correct comments, squash fix-ups, etc...\n> How can you model that? By creating another branch and moving patches\n> to it by hands... Well, it is not very productive time spending, and\n> the cost of branch becomes even more prominent.\n\nThis is a cool feature, but it contradicts to my understanding of VCS. \nIt is some kind of re-writing the history of WWII :-) \nBTW, as I undestood it, it is just a feature that can be implemented \nin any VCS (if you have access to its internals).\n\n> A quick look at \"What's cooking in git.git\" that Junio posted a few days\n> ago reveals that there are at least 43 branches that are cooking now and\n> the total number of branches that have been merged to 'master' over all\n> Git history is 3290. And Git is not the largest project out there...\n\nI meant 4-5 per person (me, precisely speaking)\n"},{"id":"127250","messageId":"hdc3ir$k81$1@ger.gmane.org","threadId":"21504","inReplyTo":"loom.20091110T150242-922@post.gmane.org","subject":"Re: Git drawbacks?","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2009-11-10T16:15:23Z","receivedAt":"2009-11-10T16:15:23Z","isPatch":false,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"\n> Perhaps, I have to explain why fix/test cycle is so long. I'm working on mobile\n> platform development. It is not so modular, so I need to build the whole image,\n> then flash the mobile and test it in a real network. This takes much time and\n> need much disk space (about 2GB of source files. In fact, significant number of\n> these files are not needed for the build, but it is too hard to force CM\n> engineers to fix this :-) )\n\nIn that case I think using multiple working trees, but sharing the pack \nfiles is a good idea.\n\nPaolo\n"},{"id":"127252","messageId":"hdc3ss$nnr$1@ger.gmane.org","threadId":"21504","inReplyTo":"loom.20091110T154312-665@post.gmane.org","subject":"Re: Git drawbacks?","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2009-11-10T16:20:43Z","receivedAt":"2009-11-10T16:20:43Z","isPatch":false,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"On 11/10/2009 03:54 PM, Dmitry Smirnov wrote:\n> This is a cool feature, but it contradicts to my understanding of VCS.\n\nNot really. As long as the history is not public, nobody will notice.\n\nIt is basically the same as using a centralized svn repository \n(corresponding to public branches) and quilt for private patch queues. \nYou can push and pop patches as much as you want in quilt, and you can \nrewrite history as much as you want in git private branches.\n\nNow I'm not very proficient with quilt, but if I understood it right, \ngit is much easier to do because you use only one tool and thus you can \nrely on the same algorithms for merging and conflict reporting also in \nthe case of private branches. I've certainly done some insane \nreordering of patches and it worked like a charm; also, git keeps a log \nof the states so it takes a single \"git diff\" invocation to check that \nthe end result of a reorganization is the same as what you started from.\n\nPaolo\n"},{"id":"127281","messageId":"20091110234331.GM27126@dpotapov.dyndns.org","threadId":"21504","inReplyTo":"loom.20091110T154312-665@post.gmane.org","subject":"Re: Git drawbacks?","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2009-11-10T23:43:31Z","receivedAt":"2009-11-10T23:43:31Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Tue, Nov 10, 2009 at 02:54:43PM +0000, Dmitry Smirnov wrote:\n> Dmitry Potapov gmail.com> writes:\n> \n> > And then if you really want\n> > to have good and clean history, you need more than just a branch. You\n> > should be able to amend your previous commits while you work on some\n> > feature. With Git, it is trivial, you just run 'git rebase -i' and may\n> > edit some previous commits, correct comments, squash fix-ups, etc...\n> > How can you model that? By creating another branch and moving patches\n> > to it by hands... Well, it is not very productive time spending, and\n> > the cost of branch becomes even more prominent.\n> \n> This is a cool feature, but it contradicts to my understanding of VCS. \n\nYes, it may *appear* to contradict one of basic axioms of any VCS --\nhistory is immutable, but here is the rule -- you never ever rebase or\nchange in any other way the public history of the official repository.\nSo once your commits hit the master branch, you should never try to\nchange them. This may be enforced through Git hooks.\n\nHowever, when we speak about history of commits in your private feature\nbranch then no one cares about how you have arrived to these series of\npatches more than in what order you have edited your files. What really\nmatters is the end result -- our patches are clean and easy to review.\n\nNow, what is 'public' history or what is not. If no one has seen your\ncommits then it is clearly not public. If your commits are integrated\nto the main development branch ('master') then they are clearly public.\nHowever, many Git users have an international branch (often called as\nproposed updates or 'pu' for short). The 'pu' branch is regularly\nrewound, so no one should based their work on it. It is more for review\nand additional testing of things that may not ready yet. When your\nbranch is merged to 'pu', it considered to be a fair play to re-write\nyour patches. However, you should do that in the way that will not\ncause problems for people who review your changes.\n\nFinally, when you re-write some branch using interactive rebase or\nsomething else. Your old changes do not disappear immediately from your\nrepository. Git has 'reflog', which keeps _all_ commits in your local\nrepository for 30 days (or whatever time your choose). So, if you did\nsomething wrong during rebase, you can always go back to the original\nversion, though you will hardly ever need that feature unless you do\nsomething really stupid...\n\n\n> BTW, as I undestood it, it is just a feature that can be implemented \n> in any VCS (if you have access to its internals).\n\nAt least, not so simple. Have you heard about Mercurial? It is another\nDVCS, which in many aspects similar to Git, but the underlying backend\nis very different. I do not follow it very closely, but for a long time\nit did not have 'rebase' and users were advised to use Mercurial Queues\ninstead, which is patch management system on top of Mercurial. While Git\nhas its own implementations of patch management systems on top of Git\nsuch as StGit and recently TopGit, I do not think they come even close\nwhen it comes to easy to use in everyday work, especially if you do not\nwant to be bothered with thinking about patch management.\n\nMuch power of Git and its flexibility comes from clean separation of the\nunderlying storage format and repository history. This makes 'rebase'\nalmost trivial in Git (unless you have merges in rebased history and you\ntry to preserve them), while with many other VCSes, those changes will\nrequire significant changes to the underlying storage, which may be\ndifficult to implement safely and efficiently. The price that Git has to\npay for its flexibility is the need to run the garbage collection to\npurge loose objects and compact all objects in one compressed pack...\n\n\nDmitry\n"},{"id":"127313","messageId":"loom.20091111T105932-300@post.gmane.org","threadId":"21504","inReplyTo":"loom.20091106T160709-387@post.gmane.org","subject":"Re: Git drawbacks?","fromName":"Dmitry Smirnov","fromEmail":"divis1969@gmail.com","sentAt":"2009-11-11T10:21:18Z","receivedAt":"2009-11-11T10:21:18Z","isPatch":false,"sender":{"key":"divis1969@gmail.com","avatar":null},"body":"Dmitry Smirnov gmail.com> writes:\n\n\nOk, I have heard a lot of perfect words about Git. I'm almost on your side :-)\n\nJust need some advice on (small for Git, I hope) problem. \nI'm trying to import P4 depot into Git (for mirroring purpose).\nIt seems a non-trivial task with the current git-p4 script.\nPerhaps, I had selected a wrong way: i'm trying to import some client.\n\nIn fact, as I said in previous mails, typically I have few similar clients.\nSo, maybe it is simpler to import some set of branches (which I suppose a little \nbit simpler with git-p4).\n\nUnfortunaley, the directory structure of the depot differs from client's (i.e. \nworking tree differs from repository tree).\nFor example,\n//depot/component/version could be mapped to the \n/component.\n\nThus if I import //depot/component/version1 and //depot/component/version2\nas is, I should be able to checkout either version1 or version2.\nNote that there could be few components in the same working tree:\n\n//depot/component1/version1 (mapped to /component1)\n//depot/component2/versionX (mapped to /component2)\n//depot/component3/versionY (mapped to /component3)\n\nWith Perforce, there could also be a more complex mappings, but maybe we will \ndiscuss it later).\n\nIs there any way to make this mapping with Git? Should I invent some kind of \ntool like 'repo' or there is a simpler way?\n\n\nDmitry\n\n \n"}]}