{"thread":{"id":"13604","subject":"Git-new-workdir","startedAt":"2008-05-21T18:21:22Z","lastAt":"2008-05-21T19:43:46Z","messageCount":7,"participants":["Craig L. Ching","Luciano Rocha","Brandon Casey"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"77404","messageId":"63BEA5E623E09F4D92233FB12A9F794301FC8B1D@emailmn.mqsoftware.com","threadId":"13604","inReplyTo":null,"subject":"Git-new-workdir","fromName":"Craig L. Ching","fromEmail":"cching@mqsoftware.com","sentAt":"2008-05-21T18:21:22Z","receivedAt":"2008-05-21T18:21:22Z","isPatch":false,"sender":{"key":"cching@mqsoftware.com","avatar":null},"body":"Hi all,\n\nI'm a bit of a newbie to Git, but I have started using it in earnest for\nthe past couple of months. I had asked on IRC about a potential problem\nI saw with git and how it fit into our workflow. We currently use CVS\nand have used it for the past ten years. A lot of us have grown\naccustomed to keeping multiple builds around for different things, e.g.\ndefects we're working on, new features, etc., we do a lot of task\nswitching and very rarely can we work on something start to finish\nwithout being interrupted with something else. The normal workflow of\ngit seems to cut across that need to keep many builds around.\nGenerally, building our software is not trivial and takes a fair amount\nof time, so just \"git checkout\" out a new branch and rebuilding is not\nreally an option for us. I jumped on IRC while back and the contrib\ngit-new-workdir was sugggested, but with the caveat that I should try\nand think outside the box before I adopted git-new-workdir. So, I come\nhere, after using Git for a couple of months and not seeing a way around\nthis, asking if I'm missing something? Should I be using\ngit-new-workdir? Or is there a better way that I have yet to see? I'm\nsure the kernel developers must have this need as well, so it's quite\npossible I'm missing something. I appreciate all feedback!\n\nCheers,\nCraig\n"},{"id":"77406","messageId":"20080521184446.GA23924@bit.office.eurotux.com","threadId":"13604","inReplyTo":"63BEA5E623E09F4D92233FB12A9F794301FC8B1D@emailmn.mqsoftware.com","subject":"Re: Git-new-workdir","fromName":"Luciano Rocha","fromEmail":"luciano@eurotux.com","sentAt":"2008-05-21T18:44:46Z","receivedAt":"2008-05-21T18:44:46Z","isPatch":false,"sender":{"key":"luciano@eurotux.com","avatar":null},"body":"On Wed, May 21, 2008 at 01:21:22PM -0500, Craig L. Ching wrote:\n> Hi all,\n> \n> I'm a bit of a newbie to Git, but I have started using it in earnest for\n> the past couple of months. I had asked on IRC about a potential problem\n> I saw with git and how it fit into our workflow. We currently use CVS\n> and have used it for the past ten years. A lot of us have grown\n> accustomed to keeping multiple builds around for different things, e.g.\n> defects we're working on, new features, etc., we do a lot of task\n> switching and very rarely can we work on something start to finish\n> without being interrupted with something else. The normal workflow of\n> git seems to cut across that need to keep many builds around.\n> Generally, building our software is not trivial and takes a fair amount\n> of time, so just \"git checkout\" out a new branch and rebuilding is not\n> really an option for us. I jumped on IRC while back and the contrib\n> git-new-workdir was sugggested, but with the caveat that I should try\n> and think outside the box before I adopted git-new-workdir. So, I come\n> here, after using Git for a couple of months and not seeing a way around\n> this, asking if I'm missing something? Should I be using\n> git-new-workdir? Or is there a better way that I have yet to see? I'm\n> sure the kernel developers must have this need as well, so it's quite\n> possible I'm missing something. I appreciate all feedback!\n\nPersonally, I'd clone a local rep for each build, with the -s option to\nclone.\n\nSomething like:\n\ngit clone server:/rep ~/master\ngit clone -s ~/master build/abc\ngit clone -s ~/master build/foo\n...\n\nThe -s option should reduce disk-usage considerably.\n\n-- \nLuciano Rocha \nEurotux Informática, S.A. \n"},{"id":"77407","messageId":"63BEA5E623E09F4D92233FB12A9F794301FC8B24@emailmn.mqsoftware.com","threadId":"13604","inReplyTo":"20080521184446.GA23924@bit.office.eurotux.com","subject":"RE: Git-new-workdir","fromName":"Craig L. Ching","fromEmail":"cching@mqsoftware.com","sentAt":"2008-05-21T18:57:56Z","receivedAt":"2008-05-21T18:57:56Z","isPatch":false,"sender":{"key":"cching@mqsoftware.com","avatar":null},"body":" \n\n> From: Luciano Rocha [mailto:luciano@eurotux.com] \n> On Wed, May 21, 2008 at 01:21:22PM -0500, Craig L. Ching wrote:\n> > Hi all,\n> > \n\n[stuff about why we want to use git-new-workdir]\n\n> \n> Personally, I'd clone a local rep for each build, with the -s \n> option to clone.\n> \n> Something like:\n> \n> git clone server:/rep ~/master\n> git clone -s ~/master build/abc\n> git clone -s ~/master build/foo\n> ...\n> \n> The -s option should reduce disk-usage considerably.\n> \nYeah, I neglected to mention that the other good thing about git-new-workdir is that the origin is set to the origin of the remote repository so to push changes to our central repository, you only need one push. Otherwise you have to push twice, right? Well now (thinking out loud here), maybe you don't. That was the impression I got from the IRC conversation, but maybe you could just push from the original clone? Still, seems easier if all the shared repositories and the original clone pushed to the same place, at least for us.\n\n> --\n> Luciano Rocha \n> Eurotux Informática, S.A. \n> \n> \n\nThanks for the feedback, it's making me think about the problem ;-)\n\nCheers,\nCraig\n"},{"id":"77408","messageId":"63BEA5E623E09F4D92233FB12A9F794301FC8B25@emailmn.mqsoftware.com","threadId":"13604","inReplyTo":"9af502e50805211153ya79f73y60d4975d46ef8edd@mail.gmail.com","subject":"RE: Git-new-workdir","fromName":"Craig L. Ching","fromEmail":"cching@mqsoftware.com","sentAt":"2008-05-21T19:07:34Z","receivedAt":"2008-05-21T19:07:34Z","isPatch":false,"sender":{"key":"cching@mqsoftware.com","avatar":null},"body":"> From: Robert Anderson [mailto:rwa000@gmail.com] \n> \n> On Wed, May 21, 2008 at 11:21 AM, Craig L. Ching \n> wrote:\n> \n> \n> \tHi all,\n> \t\n> \tI'm a bit of a newbie to Git, but I have started using \n> it in earnest for\n> \tthe past couple of months. I had asked on IRC about a \n> potential problem\n> \tI saw with git and how it fit into our workflow. We \n> currently use CVS\n> \tand have used it for the past ten years. A lot of us have grown\n> \taccustomed to keeping multiple builds around for \n> different things, e.g.\n> \tdefects we're working on, new features, etc., we do a \n> lot of task\n> \tswitching and very rarely can we work on something \n> start to finish\n> \twithout being interrupted with something else. The \n> normal workflow of\n> \tgit seems to cut across that need to keep many builds around.\n> \tGenerally, building our software is not trivial and \n> takes a fair amount\n> \tof time, so just \"git checkout\" out a new branch and \n> rebuilding is not\n> \treally an option for us. \n> \n> \n> You haven't explained your issue very well. \n> \n> What does \"keeping multiple builds around\" mean? Taken at \n> face value this is irrelevant to source control. So you must \n> mean something else, but you haven't explained what. I keep \n> multiple builds around by using separate build directories \n> which are not source controlled. Whether or not I keep \n> multiple builds of a source tree just isn't relevant to my \n> source control whether it be CVS or git or whatever. Perhaps \n> you mean \"different variations of the same source tree\" or \n> something like that, in which case \"git seems to cut across \n> that need\" seems like an absurd thing to say.\n> \n> Can you give an actual scenario, and say how you use CVS in that case?\n> \nSure, what I mean is that you checkout a branch, the workspace reflects\nthe state of that branch. If you do a build in the workspace, the build\nartifacts match up with the source that's in the workspace. If you then\ncheckout a new branch, it's unlikely that the source reflects the build\nartifacts any more.\n\nHere's how we did it in CVS. Any feature or defect got it's own branch,\nno matter how trivial it was (yes, it was very painful with CVS, but the\nbenefits outweighed the pain. Moving to Git is very easy for us since\nwe already have the \"branch for everything\" mindset ;-) ). So, say you\nhave two defects, A and B. We'd create two separate branches named\nafter the defects, so two branches named A and B. Then we'd do:\n\nCd ~/dev/\nMkdir A && cd A && cvs co -r A && make\nMkdir B && cd B && cvs co -r B && make\n\nThat way we'd have two separate workspaces where the build artifacts\nmatch with the source. Now, I suppose you could suggest we change our\nbuild procedure so that it puts the build artifacts outside of the VCS\nworkspace, i.e. our makefiles could \"git branch\" and create a directory\nfor those build artifacts outside of the source workspace? That might\nwork, I'd have to think about it a bit more, but I know for our java\nsources that might be a problem with a lot of java build tool\nconventions, e.g. maven puts the build artifacts in the same top-level\ndirectory that contains the sources.\n\nCheers,\nCraig\n"},{"id":"77410","messageId":"MnNeABMJjOQ8gdG6gY5zubSC3c5X2sDYBwcI1MotmXFvW3kUNXzB5A@cipher.nrlssc.navy.mil","threadId":"13604","inReplyTo":"20080521184446.GA23924@bit.office.eurotux.com","subject":"Re: Git-new-workdir","fromName":"Brandon Casey","fromEmail":"casey@nrlssc.navy.mil","sentAt":"2008-05-21T19:25:37Z","receivedAt":"2008-05-21T19:25:37Z","isPatch":false,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"Luciano Rocha wrote:\n\n> git clone server:/rep ~/master\n> git clone -s ~/master build/abc\n> git clone -s ~/master build/foo\n> ...\n\nDon't do that without first doing\n\n git config gc.pruneExpire never\n\nto disable pruning loose objects if there is any chance that any will\nbe created. Better to be safe, and prune manually using the example\nin the prune documentation.\n\n> The -s option should reduce disk-usage considerably.\n\nIt won't be any less than what git-new-workdir would produce. Actually,\ngit-new-workdir could provide more space savings since there is only a\nsingle repository so new objects created by development in any of the\nnew work directories would be available to all others. This is getting\na little nit-picky, basically space usage for the two options is nil.\n\nMy take on it...\n\nIf you want to have _multiple_different_ branches checked out from the\n_same_ repository, and do development in all of them, then git-new-workdir\nis the right choice.\n\nIf you want to have the _same_branch_ checked out in multiple work\ndirectories, then cloning with -s is what you want. In this case\nI assume development will be performed in the original repo, and\nthe clones will do a pull to update.\n\nPersonally, I have found the git-new-workdir script to satisfy any\nneed which caused me to even think about cloning with -s. I am\nhoping the functionality of git-new-workdir will be folded into\ngit porcelain at some point (ahem J Schindelin).\n\n-brandon\n"},{"id":"77411","messageId":"63BEA5E623E09F4D92233FB12A9F794301FC8B2B@emailmn.mqsoftware.com","threadId":"13604","inReplyTo":"MnNeABMJjOQ8gdG6gY5zubSC3c5X2sDYBwcI1MotmXFvW3kUNXzB5A@cipher.nrlssc.navy.mil","subject":"RE: Git-new-workdir","fromName":"Craig L. Ching","fromEmail":"cching@mqsoftware.com","sentAt":"2008-05-21T19:30:42Z","receivedAt":"2008-05-21T19:30:42Z","isPatch":false,"sender":{"key":"cching@mqsoftware.com","avatar":null},"body":" \n\n> From: Brandon Casey [mailto:casey@nrlssc.navy.mil] \n> My take on it...\n> \n> If you want to have _multiple_different_ branches checked out \n> from the _same_ repository, and do development in all of \n> them, then git-new-workdir is the right choice.\n> \nYes, that's precisely what we want to do. So according to your\nexperience, we're making the right choice then.\n\n> If you want to have the _same_branch_ checked out in multiple \n> work directories, then cloning with -s is what you want. In \n> this case I assume development will be performed in the \n> original repo, and the clones will do a pull to update.\n> \nOk, for us this would probably be rare, but good to know.\n\n> Personally, I have found the git-new-workdir script to \n> satisfy any need which caused me to even think about cloning \n> with -s. I am hoping the functionality of git-new-workdir \n> will be folded into git porcelain at some point (ahem J Schindelin).\n> \nWe'd like that too ;-)\n\n> -brandon\n> \n> \n\nCheers,\nCraig\n"},{"id":"77415","messageId":"lXwYKtxzN4sNGyIsKSICbezjS7G4fF4oK6wrVgqs-vVP5A9o-fmLmg@cipher.nrlssc.navy.mil","threadId":"13604","inReplyTo":"63BEA5E623E09F4D92233FB12A9F794301FC8B2B@emailmn.mqsoftware.com","subject":"Re: Git-new-workdir","fromName":"Brandon Casey","fromEmail":"casey@nrlssc.navy.mil","sentAt":"2008-05-21T19:43:46Z","receivedAt":"2008-05-21T19:43:46Z","isPatch":false,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"Craig L. Ching wrote:\n> \n> \n>> From: Brandon Casey [mailto:casey@nrlssc.navy.mil] \n>> My take on it...\n>>\n>> If you want to have _multiple_different_ branches checked out \n>> from the _same_ repository, and do development in all of \n>> them, then git-new-workdir is the right choice.\n>>\n> Yes, that's precisely what we want to do. So according to your\n> experience, we're making the right choice then.\n\nYes. I feel more confident after reading your reply to Robert where\nyou described your use-case more thoroughly.\n\n-brandon\n"}]}