{"thread":{"id":"10016","subject":"Workflow question","startedAt":"2007-09-25T16:43:05Z","lastAt":"2007-09-26T12:42:43Z","messageCount":17,"participants":["Russ Brown","Andreas Ericsson","Jeff King","Wincent Colaiuta","Junio C Hamano","Karl Hasselström"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"54018","messageId":"46F93A99.5080707@gmail.com","threadId":"10016","inReplyTo":null,"subject":"Workflow question","fromName":"Russ Brown","fromEmail":"pickscrape@gmail.com","sentAt":"2007-09-25T16:43:05Z","receivedAt":"2007-09-25T16:43:05Z","isPatch":false,"sender":{"key":"pickscrape@gmail.com","avatar":null},"body":"Hi,\n\nI've been trying to think of a git workflow that we could use to replace\nour current svn/svk setup without simply using git in exactly the same\nway that we use svn/svk.\n\nBasically, we develop, maintain and enhance a website. On the central\nrepo is trunk which represents live, and any number of project branches.\nDevelopers don't use local branches: they check out the project branches\nthey're working on and commit to those. Developers merge from trunk to\nproject branch from time to time to keep them current, and when a\nproject rolls out the branch is merged to trunk.\n\nIn addition to the obvious advantages that git would give us (such as\nproperly tracking that code author as opposed to the person who did the\nmerge), I'm wanting to gain the following benefits:\n\n * The repository is very large (multiple gigabytes) and mirroring using\nsvk obviously takes a lot of time and space, so I'm keen to bring that\ndown, most likely by the developer not needing to mirror branches he\ndoesn't care about, or by being able to throw away branches he's done with.\n * The repository is full of revisions that fail review (or break\nthings) and are fixed by subsequent revisions. We'd much rather be able\nto have the developer fix his revisions before they get committed\n'upstream' (whatever that ends up meaning).\n\nI asked earlier about the email-based model that git itself uses, and\nwhile it appears to work very well for a widely-dispersed open-source\nproject, I think it will be too cumbersome and slow for a fast-paced\ninternal development team who make a number of live releases every day.\n\nSo, I've been thinking and have come up with this, which I'd appreciate\ncomments about:\n\n 1. On a server we stick a git repository which contains the master\nbranch, which represents what trunk did (i.e. the live platform). This\nbranch contains the full history for the live platform.\n 2. On the same server we clone that repo to create a second repository\nwhich is the developer area. In this we track master from the live repo,\nand also create project branches.\n 3. Developers clone this developer repo, but I'd like them to be able\nto decide which branches they actually want to clone from that\nrepository rather than simply cloning them all. Is this possible?\n 4. Developers create a local branch of the project they\nare working on and commit to that.\n 5. Once they think they're done, they publish their branch to the\ndevelopment repo and request for comments.\n 6. If all is not well, the developer creates a new local branch and\nmoves good revisions from his previous one to the new one, modifying\nthings as he goes, and republishes his new branch.\n 7. If all is well, their works gets merged or rebased onto the main\nproject branch, and once that's ready it gets pushed to the master and\nrolled to live. The developer's individual branches get deleted from the\ndev repo since they're no longer required.\n 8. From time to time the master branch gets merged to the project\nbranches. Developer's local branches can be rebased against the project\nbranch as they please.\n\nFirstly, is all of this possible, and if so would it be considered a\ngood way of going about it?\n\nAny comments appreciated.\n\n-- \n\nRuss\n"},{"id":"54022","messageId":"46F95CCC.4080209@op5.se","threadId":"10016","inReplyTo":"46F93A99.5080707@gmail.com","subject":"Re: Workflow question","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-09-25T19:09:00Z","receivedAt":"2007-09-25T19:09:00Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Russ Brown wrote:\n> Hi,\n> \n> I've been trying to think of a git workflow that we could use to replace\n> our current svn/svk setup without simply using git in exactly the same\n> way that we use svn/svk.\n> \n> Basically, we develop, maintain and enhance a website. On the central\n> repo is trunk which represents live, and any number of project branches.\n> Developers don't use local branches: they check out the project branches\n> they're working on and commit to those. Developers merge from trunk to\n> project branch from time to time to keep them current, and when a\n> project rolls out the branch is merged to trunk.\n> \n> In addition to the obvious advantages that git would give us (such as\n> properly tracking that code author as opposed to the person who did the\n> merge), I'm wanting to gain the following benefits:\n> \n>  * The repository is very large (multiple gigabytes) and mirroring using\n> svk obviously takes a lot of time and space, so I'm keen to bring that\n> down, most likely by the developer not needing to mirror branches he\n> doesn't care about, or by being able to throw away branches he's done with.\n>  * The repository is full of revisions that fail review (or break\n> things) and are fixed by subsequent revisions. We'd much rather be able\n> to have the developer fix his revisions before they get committed\n> 'upstream' (whatever that ends up meaning).\n> \n> I asked earlier about the email-based model that git itself uses, and\n> while it appears to work very well for a widely-dispersed open-source\n> project, I think it will be too cumbersome and slow for a fast-paced\n> internal development team who make a number of live releases every day.\n> \n\nWe came to the same conclusion at our workplace. Email works great, but\nit's faster and better to just walk over to your colleague and ask what\nhe/she thinks about something.\n\n> So, I've been thinking and have come up with this, which I'd appreciate\n> comments about:\n> \n>  1. On a server we stick a git repository which contains the master\n> branch, which represents what trunk did (i.e. the live platform). This\n> branch contains the full history for the live platform.\n\nA must-have for any more-than-two-developers setup, so so far so good ;-)\n\n>  2. On the same server we clone that repo to create a second repository\n> which is the developer area. In this we track master from the live repo,\n> and also create project branches.\n\nThis isn't necessary. Branches in git are very nearly zero-cost, so having\nthem in the same repo as the master branch won't hurt a bit. You can add\nan update-hook on the mothership repo to restrict access to the master\nbranch if you like, but creating two separate repos will likely give\nmore headache than it's worth.\n\n>  3. Developers clone this developer repo, but I'd like them to be able\n> to decide which branches they actually want to clone from that\n> repository rather than simply cloning them all. Is this possible?\n\nYes, although I'd actually recommend you to clone the full repo anyway.\nSince the various branches are likely to share quite a lot of history\nthe added overhead of a few extra branches will most likely be negligible.\ngit makes even very large codebases appear small and unobtrusive. The\nlinux kernel history since 2.6.12 contains 554853 objects and compresses\ndown to 178MiB.\n\nI think KDE is the largest repo imported to git so far. I've forgotten\nthe exact numbers, but everyone was very impressed, and quite surprised,\nat the vast difference between SVN and git storage requirements.\n\n\n>  4. Developers create a local branch of the project they\n> are working on and commit to that.\n>  5. Once they think they're done, they publish their branch to the\n> development repo and request for comments.\n\nUsing topic-branches is a much better strategy, usually, since that\nallows each feature to be evaluated and improved on on its own, rather\nthan having to merge *all* of a particular developers changes just to\nget desirable feature X. Note that cherry-pick provides ways of doing\nthat anyways, but in a much less elegant way, and your integrator/\nrelease engineer will likely tear his hair out on a daily basis without\ntopic branches.\n\n>  6. If all is not well, the developer creates a new local branch and\n> moves good revisions from his previous one to the new one, modifying\n> things as he goes, and republishes his new branch.\n>  7. If all is well, their works gets merged or rebased onto the main\n> project branch, and once that's ready it gets pushed to the master and\n> rolled to live. The developer's individual branches get deleted from the\n> dev repo since they're no longer required.\n\nTopic branches would work the same, basically, except they can be pushed up\nfor review a lot faster.\n\nIf all the pushing gets cumbersome, it also makes it easy to send the patches\nout as emails for discussion. It's usually easier to let git handle the\nactual code transmissions, but discussing patches in emails works quite\nwell if it's intended for a wider audience.\n\n>  8. From time to time the master branch gets merged to the project\n> branches. Developer's local branches can be rebased against the project\n> branch as they please.\n> \n\ncriss-cross merging can turn kinda nasty though, as you may have a hard time\nfinding *the* common point when you run into that rogue merge with conflict\nmarkers everywhere (it happens for everyone sooner or later).\n\nI'd suggest you rebase the developer/topic branches onto master with regular\nintervals instead.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"54028","messageId":"20070925193416.GB8564@coredump.intra.peff.net","threadId":"10016","inReplyTo":"46F95CCC.4080209@op5.se","subject":"Re: Workflow question","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-09-25T19:34:16Z","receivedAt":"2007-09-25T19:34:16Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Sep 25, 2007 at 09:09:00PM +0200, Andreas Ericsson wrote:\n\n> We came to the same conclusion at our workplace. Email works great, but\n> it's faster and better to just walk over to your colleague and ask what\n> he/she thinks about something.\n\nOne of the projects I am working on does things this way, but I have to\nadmit that I miss the email code-review process. There are often small\nfixups (stylistic, minor nits, \"I would have done it this way...\", etc)\nthat are worth pointing out at the time, but are more painful to go back\nand correct much later.\n\nAnd documenting those discussions can really help other developers\nbesides the author and reviewer.\n\n-Peff\n"},{"id":"54030","messageId":"46F96493.8000607@gmail.com","threadId":"10016","inReplyTo":"46F95CCC.4080209@op5.se","subject":"Re: Workflow question","fromName":"Russ Brown","fromEmail":"pickscrape@gmail.com","sentAt":"2007-09-25T19:42:11Z","receivedAt":"2007-09-25T19:42:11Z","isPatch":false,"sender":{"key":"pickscrape@gmail.com","avatar":null},"body":"Andreas Ericsson wrote:\n> Russ Brown wrote:\n>> Hi,\n>>\n>> I've been trying to think of a git workflow that we could use to replace\n>> our current svn/svk setup without simply using git in exactly the same\n>> way that we use svn/svk.\n>>\n>> Basically, we develop, maintain and enhance a website. On the central\n>> repo is trunk which represents live, and any number of project branches.\n>> Developers don't use local branches: they check out the project branches\n>> they're working on and commit to those. Developers merge from trunk to\n>> project branch from time to time to keep them current, and when a\n>> project rolls out the branch is merged to trunk.\n>>\n>> In addition to the obvious advantages that git would give us (such as\n>> properly tracking that code author as opposed to the person who did the\n>> merge), I'm wanting to gain the following benefits:\n>>\n>>  * The repository is very large (multiple gigabytes) and mirroring using\n>> svk obviously takes a lot of time and space, so I'm keen to bring that\n>> down, most likely by the developer not needing to mirror branches he\n>> doesn't care about, or by being able to throw away branches he's done\n>> with.\n>>  * The repository is full of revisions that fail review (or break\n>> things) and are fixed by subsequent revisions. We'd much rather be able\n>> to have the developer fix his revisions before they get committed\n>> 'upstream' (whatever that ends up meaning).\n>>\n>> I asked earlier about the email-based model that git itself uses, and\n>> while it appears to work very well for a widely-dispersed open-source\n>> project, I think it will be too cumbersome and slow for a fast-paced\n>> internal development team who make a number of live releases every day.\n>>\n> \n> We came to the same conclusion at our workplace. Email works great, but\n> it's faster and better to just walk over to your colleague and ask what\n> he/she thinks about something.\n> \n\nVery true, with the minor exception that at my place there are\ndevelopers working at different sites, so the walk-over method will only\nwork for specific subsets of the team. :)\n\n>> So, I've been thinking and have come up with this, which I'd appreciate\n>> comments about:\n>>\n>>  1. On a server we stick a git repository which contains the master\n>> branch, which represents what trunk did (i.e. the live platform). This\n>> branch contains the full history for the live platform.\n> \n> A must-have for any more-than-two-developers setup, so so far so good ;-)\n> \n>>  2. On the same server we clone that repo to create a second repository\n>> which is the developer area. In this we track master from the live repo,\n>> and also create project branches.\n> \n> This isn't necessary. Branches in git are very nearly zero-cost, so having\n> them in the same repo as the master branch won't hurt a bit. You can add\n> an update-hook on the mothership repo to restrict access to the master\n> branch if you like, but creating two separate repos will likely give\n> more headache than it's worth.\n> \n\nAh, right. I'm just trying to remember why it was I came up with that\nidea in the first place, but I'm struggling a bit. :)\n\n>>  3. Developers clone this developer repo, but I'd like them to be able\n>> to decide which branches they actually want to clone from that\n>> repository rather than simply cloning them all. Is this possible?\n> \n> Yes, although I'd actually recommend you to clone the full repo anyway.\n> Since the various branches are likely to share quite a lot of history\n> the added overhead of a few extra branches will most likely be negligible.\n> git makes even very large codebases appear small and unobtrusive. The\n> linux kernel history since 2.6.12 contains 554853 objects and compresses\n> down to 178MiB.\n> \n\nMakes sense. Thing is, with git-svn (which I've been using for a while\nnow) it's possible to 'bring in' an upstream branch at will by adding it\nto your config file, and on next git-svn fetch revisions that affect\nthat branch are automatically fetched. I figured it would just be a\nlittle more efficient, though I appreciate it involves more 'fiddling'\nby the client users.\n\nHere's a question: is the creation and deletion of a branch also version\ncontrolled as it is in Subversion? In other words, if I create a branch,\ndevelop on it and delete it without merging it anywhere, will the\nrevisions hang around and get pulled down by future people cloning the\nrepository, or do they get thrown away?\n\n> I think KDE is the largest repo imported to git so far. I've forgotten\n> the exact numbers, but everyone was very impressed, and quite surprised,\n> at the vast difference between SVN and git storage requirements.\n> \n> \n>>  4. Developers create a local branch of the project they\n>> are working on and commit to that.\n>>  5. Once they think they're done, they publish their branch to the\n>> development repo and request for comments.\n> \n> Using topic-branches is a much better strategy, usually, since that\n> allows each feature to be evaluated and improved on on its own, rather\n> than having to merge *all* of a particular developers changes just to\n> get desirable feature X. Note that cherry-pick provides ways of doing\n> that anyways, but in a much less elegant way, and your integrator/\n> release engineer will likely tear his hair out on a daily basis without\n> topic branches.\n> \n\nI've seen the term 'topic-branch' used here quite a bit but it's\nunfamiliar to me. It is basically synonymous with what we call a\n'project branch'? i.e. Management decide that feature X is required so\nwe create a branch to develop it on which all developers on the project\ncommit to.\n\nNote that in step 4 above I mean the developer takes a local branch of\nthe topic branch. For example, we start projectX/main, and create branch\nprojectX on the shared repo. Developer 'jeff' works on the project and\nso creates local branch projectX/jeff and begins work. In step 5 they\npush this local branch to the shared repo so everyone can see it\n(alternative to the 'walk-over' method or emailing). Note that all\nchanges jeff making in projectX/jeff are specific to the project branch,\nso he can rebase against other changes that get committed to that\nproject branch.\n\nIf colleagues don't like his changes he can create projectXjeff2 and try\nagain.\n\nJeff can also have other local branches to keep separate changes he is\nmaking on the other projects he is involved in.\n\nThat's how I'd thought of it happening...\n\n>>  6. If all is not well, the developer creates a new local branch and\n>> moves good revisions from his previous one to the new one, modifying\n>> things as he goes, and republishes his new branch.\n>>  7. If all is well, their works gets merged or rebased onto the main\n>> project branch, and once that's ready it gets pushed to the master and\n>> rolled to live. The developer's individual branches get deleted from the\n>> dev repo since they're no longer required.\n> \n> Topic branches would work the same, basically, except they can be pushed up\n> for review a lot faster.\n> \n> If all the pushing gets cumbersome, it also makes it easy to send the\n> patches\n> out as emails for discussion. It's usually easier to let git handle the\n> actual code transmissions, but discussing patches in emails works quite\n> well if it's intended for a wider audience.\n> \n\nYes, I am going to experiment with this a little too to see just how\nmuch work it would involve for the developers (if it's too much they\nwon't do it) :)\n\n>>  8. From time to time the master branch gets merged to the project\n>> branches. Developer's local branches can be rebased against the project\n>> branch as they please.\n>>\n> \n> criss-cross merging can turn kinda nasty though, as you may have a hard\n> time\n> finding *the* common point when you run into that rogue merge with conflict\n> markers everywhere (it happens for everyone sooner or later).\n> \n> I'd suggest you rebase the developer/topic branches onto master with\n> regular\n> intervals instead.\n> \n\nHaving been using git-svn for a while I really like the clean history\nresult that rebase gives, however my understanding was that you should\nnever rebase any published branch as it could screw up clones of that\nbranch. In fact, this is what has me the most confused: how to rebase a\nproject branch that is on a shared repository against master when\neveryone will have it cloned? Or is this something that I clearly don't\nunderstand properly?\n\n(Thanks for your answers BTW Andreas)\n\n-- \n\nRuss\n"},{"id":"54033","messageId":"24DF51B9-1BF9-40C0-A1EF-80EF5072570F@wincent.com","threadId":"10016","inReplyTo":"20070925193416.GB8564@coredump.intra.peff.net","subject":"Re: Workflow question","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2007-09-25T19:50:34Z","receivedAt":"2007-09-25T19:50:34Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 25/9/2007, a las 21:34, Jeff King escribió:\n\n> On Tue, Sep 25, 2007 at 09:09:00PM +0200, Andreas Ericsson wrote:\n>\n>> We came to the same conclusion at our workplace. Email works  \n>> great, but\n>> it's faster and better to just walk over to your colleague and ask  \n>> what\n>> he/she thinks about something.\n>\n> One of the projects I am working on does things this way, but I  \n> have to\n> admit that I miss the email code-review process. There are often small\n> fixups (stylistic, minor nits, \"I would have done it this way...\",  \n> etc)\n> that are worth pointing out at the time, but are more painful to go  \n> back\n> and correct much later.\n>\n> And documenting those discussions can really help other developers\n> besides the author and reviewer.\n\nGoogle has a pretty interesting internal code review system:\n\n<http://video.google.com/videoplay?docid=-8502904076440714866>\n\nCheers,\nWincent\n"},{"id":"54040","messageId":"20070925201717.GB19549@segfault.peff.net","threadId":"10016","inReplyTo":"46F96493.8000607@gmail.com","subject":"Re: Workflow question","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-09-25T20:17:17Z","receivedAt":"2007-09-25T20:17:17Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Sep 25, 2007 at 02:42:11PM -0500, Russ Brown wrote:\n\n> > This isn't necessary. Branches in git are very nearly zero-cost, so having\n> > them in the same repo as the master branch won't hurt a bit. You can add\n> > an update-hook on the mothership repo to restrict access to the master\n> > branch if you like, but creating two separate repos will likely give\n> > more headache than it's worth.\n> > \n> \n> Ah, right. I'm just trying to remember why it was I came up with that\n> idea in the first place, but I'm struggling a bit. :)\n\nIt's not entirely true that branches are zero-cost. They cost nothing to\nmake, but fetching a branch that has commits that you don't want is\ngoing to cost something. And since git-clone doesn't have good support\nfor \"fetch only this subset of the branches\" you end up getting them\nall.\n\nThat being said, you will be amazed how _little_ that cost is unless\none of the branches doesn't delta well (e.g., if one branch introduces 100M\nof unrelated images, then getting that branch is going to cost). But\nit's almost certainly worth seeing what your workload is like.\n\n> Here's a question: is the creation and deletion of a branch also version\n> controlled as it is in Subversion? In other words, if I create a branch,\n> develop on it and delete it without merging it anywhere, will the\n> revisions hang around and get pulled down by future people cloning the\n> repository, or do they get thrown away?\n\nBranch creation isn't version controlled, but your frame of reference is\nobviously svn branches, not git branches. A git repo is just a\ncollection of refs, and each ref is a pointer to some commit (which\npoints to a tree and to further commits). Branches are just refs in a\ngiven namespace (where the namespace refs/heads/ indicates \"it's ok to\nmake further commits on top of these\").\n\nSo if you create a branch in your private repo, it is a totally private\nthing; the central repo has no notion of it. When you push that branch\nto the central repo, you are creating a new ref at the central location\nthat points to some commits you made. People who clone it will clone\nthat ref and your commits. If you delete the branch locally, again it\nhas no effect on the master repo. If you delete the branch from the\ncentral repo, then nobody will fetch those commits anymore (since\nnothing will be pointing to them).\n\n> I've seen the term 'topic-branch' used here quite a bit but it's\n> unfamiliar to me. It is basically synonymous with what we call a\n> 'project branch'? i.e. Management decide that feature X is required so\n> we create a branch to develop it on which all developers on the project\n> commit to.\n\nYes, that's exactly right. You have a \"branch\" for working on a \"topic\".\n\n> Note that in step 4 above I mean the developer takes a local branch of\n> the topic branch. For example, we start projectX/main, and create branch\n> projectX on the shared repo. Developer 'jeff' works on the project and\n> so creates local branch projectX/jeff and begins work. In step 5 they\n\nYou are actually talking about per-developer, per-topic branches. Which\nis fine, too. It sounds like these projects are big (many participants\nover an extended period), so you may want to do things hierarchically:\n\n  1. project X starts, so you make a branch projectX and assign Bob to\n     be the integrator (or if you prefer, nobody is the integrator).\n  2. Jeff starts to work on project X, feature Y. He makes a branch\n     projectX/featureY, based on projectX. He may publish this to the\n     shared repo if he wants to communicate his progress.\n  3. When featureY is \"ready\", he tells Bob to pull it into the main\n     projectX branch (or if no integrator, he does it himself).\n\nAny developer can see the progress of any \"topic\" by looking at its\nbranch. But only things which have advanced to the main \"projectX\"\nbranch are used as the basis for other topics. If you want, you can\nreplace featureY with \"jeff\" to indicate \"this is the work Jeff is doing\non projectX\", but then you will run into issues when Jeff is working on\ntwo different topics of projectY.\n\n> Having been using git-svn for a while I really like the clean history\n> result that rebase gives, however my understanding was that you should\n> never rebase any published branch as it could screw up clones of that\n> branch. In fact, this is what has me the most confused: how to rebase a\n> project branch that is on a shared repository against master when\n> everyone will have it cloned? Or is this something that I clearly don't\n> understand properly?\n\nYou generally don't want to rebase that branch. If there are other\nbranches based on some work, then it will become more difficult to merge\nthose branches into the rebased work. IOW, rebase works well only at the\n\"outermost\" level of development. So if branch \"featureY\" is branched from\n\"projectX\" which is branched from \"main\", then it is reasonable to\nrebase featureY against projectX. But rebasing projectX against master\nwill make integrating \"featureY\" more difficult. So you should either:\n  - just do regular merges of projectX into main (and hopefully, if\n    projectX is an aggregate of features, it won't have _that_ many\n    merges, so the history should still be quite readable)\n  - wait until all such \"featureY\" branches are merged into projectX,\n    announce a freeze of branching from projectX, and then rebase it\n    forward.\n\n-Peff\n"},{"id":"54041","messageId":"20070925202022.GC19549@segfault.peff.net","threadId":"10016","inReplyTo":"24DF51B9-1BF9-40C0-A1EF-80EF5072570F@wincent.com","subject":"Re: Workflow question","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-09-25T20:20:22Z","receivedAt":"2007-09-25T20:20:22Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Sep 25, 2007 at 09:50:34PM +0200, Wincent Colaiuta wrote:\n\n> Google has a pretty interesting internal code review system:\n> \n> <http://video.google.com/videoplay?docid=-8502904076440714866>\n\nInteresting pointer, thanks. Though I did get a little concerned when I\nsaw that it is based on Perforce. ;)\n\n-Peff\n"},{"id":"54042","messageId":"5E384CBB-4562-47B3-B4D8-D12D5A5129D6@wincent.com","threadId":"10016","inReplyTo":"20070925202022.GC19549@segfault.peff.net","subject":"Re: Workflow question","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2007-09-25T20:37:10Z","receivedAt":"2007-09-25T20:37:10Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 25/9/2007, a las 22:20, Jeff King escribió:\n\n> On Tue, Sep 25, 2007 at 09:50:34PM +0200, Wincent Colaiuta wrote:\n>\n>> Google has a pretty interesting internal code review system:\n>>\n>> <http://video.google.com/videoplay?docid=-8502904076440714866>\n>\n> Interesting pointer, thanks. Though I did get a little concerned  \n> when I\n> saw that it is based on Perforce. ;)\n\nYes (poor Google employees!), and not only that, I'm not aware of any  \npublic access to the code. But still, there are some interesting  \nideas about the review process in there.\n\nW\n"},{"id":"54043","messageId":"46F97618.9010207@gmail.com","threadId":"10016","inReplyTo":"20070925201717.GB19549@segfault.peff.net","subject":"Re: Workflow question","fromName":"Russ Brown","fromEmail":"pickscrape@gmail.com","sentAt":"2007-09-25T20:56:56Z","receivedAt":"2007-09-25T20:56:56Z","isPatch":false,"sender":{"key":"pickscrape@gmail.com","avatar":null},"body":"Jeff King wrote:\n> On Tue, Sep 25, 2007 at 02:42:11PM -0500, Russ Brown wrote:\n> \n>>> This isn't necessary. Branches in git are very nearly zero-cost, so having\n>>> them in the same repo as the master branch won't hurt a bit. You can add\n>>> an update-hook on the mothership repo to restrict access to the master\n>>> branch if you like, but creating two separate repos will likely give\n>>> more headache than it's worth.\n>>>\n>> Ah, right. I'm just trying to remember why it was I came up with that\n>> idea in the first place, but I'm struggling a bit. :)\n> \n> It's not entirely true that branches are zero-cost. They cost nothing to\n> make, but fetching a branch that has commits that you don't want is\n> going to cost something. And since git-clone doesn't have good support\n> for \"fetch only this subset of the branches\" you end up getting them\n> all.\n> \n> That being said, you will be amazed how _little_ that cost is unless\n> one of the branches doesn't delta well (e.g., if one branch introduces 100M\n> of unrelated images, then getting that branch is going to cost). But\n> it's almost certainly worth seeing what your workload is like.\n> \n\nThat's pretty much what I thought. Given that we'll probably only port\nacross a few (active) branches if we do decide to convert, I figure we\nmight as well start off by cloning them all and see how it goes.\n\n>> Here's a question: is the creation and deletion of a branch also version\n>> controlled as it is in Subversion? In other words, if I create a branch,\n>> develop on it and delete it without merging it anywhere, will the\n>> revisions hang around and get pulled down by future people cloning the\n>> repository, or do they get thrown away?\n> \n> Branch creation isn't version controlled, but your frame of reference is\n> obviously svn branches, not git branches. A git repo is just a\n> collection of refs, and each ref is a pointer to some commit (which\n> points to a tree and to further commits). Branches are just refs in a\n> given namespace (where the namespace refs/heads/ indicates \"it's ok to\n> make further commits on top of these\").\n> \n\nI keep reading things similar to this and bit by bit I'm starting to get\nit. :) I suppose this is one case in which it's definitely a\ndisadvantage to have a good understanding of svn before coming to git...\n\n<yoda>You must unlearn what you have learned</yoda>\n\n> So if you create a branch in your private repo, it is a totally private\n> thing; the central repo has no notion of it. When you push that branch\n> to the central repo, you are creating a new ref at the central location\n> that points to some commits you made. People who clone it will clone\n> that ref and your commits. If you delete the branch locally, again it\n> has no effect on the master repo. If you delete the branch from the\n> central repo, then nobody will fetch those commits anymore (since\n> nothing will be pointing to them).\n> \n\nIf you delete a branch that has commits on it that aren't referenced by\nany other branches, will those commits be removed by something like git\npack or git gc?\n\n>> I've seen the term 'topic-branch' used here quite a bit but it's\n>> unfamiliar to me. It is basically synonymous with what we call a\n>> 'project branch'? i.e. Management decide that feature X is required so\n>> we create a branch to develop it on which all developers on the project\n>> commit to.\n> \n> Yes, that's exactly right. You have a \"branch\" for working on a \"topic\".\n> \n>> Note that in step 4 above I mean the developer takes a local branch of\n>> the topic branch. For example, we start projectX/main, and create branch\n>> projectX on the shared repo. Developer 'jeff' works on the project and\n>> so creates local branch projectX/jeff and begins work. In step 5 they\n> \n> You are actually talking about per-developer, per-topic branches. Which\n> is fine, too. It sounds like these projects are big (many participants\n> over an extended period), so you may want to do things hierarchically:\n> \n>   1. project X starts, so you make a branch projectX and assign Bob to\n>      be the integrator (or if you prefer, nobody is the integrator).\n>   2. Jeff starts to work on project X, feature Y. He makes a branch\n>      projectX/featureY, based on projectX. He may publish this to the\n>      shared repo if he wants to communicate his progress.\n>   3. When featureY is \"ready\", he tells Bob to pull it into the main\n>      projectX branch (or if no integrator, he does it himself).\n> \n> Any developer can see the progress of any \"topic\" by looking at its\n> branch. But only things which have advanced to the main \"projectX\"\n> branch are used as the basis for other topics. If you want, you can\n> replace featureY with \"jeff\" to indicate \"this is the work Jeff is doing\n> on projectX\", but then you will run into issues when Jeff is working on\n> two different topics of projectY.\n> \n\nYes, that's kinda like what I was thinking. The distinction between a\ndeveloper working on a named branch or a feature branch I suppose is one\nto think about.\n\nI suppose what has me the most confused is how a developer works with a\nremote branch: I've come to understand that a developer should never\ncheck out and work on a remote branch, and always create a local one and\nwork on that. If he does that using the above hierarchy, there then\nbecomes main->projectX->featureY->jeff_local_branch_of_featureY. Or is\nis possible for a developer to work directory on a remote branch?\n\n>> Having been using git-svn for a while I really like the clean history\n>> result that rebase gives, however my understanding was that you should\n>> never rebase any published branch as it could screw up clones of that\n>> branch. In fact, this is what has me the most confused: how to rebase a\n>> project branch that is on a shared repository against master when\n>> everyone will have it cloned? Or is this something that I clearly don't\n>> understand properly?\n> \n> You generally don't want to rebase that branch. If there are other\n> branches based on some work, then it will become more difficult to merge\n> those branches into the rebased work. IOW, rebase works well only at the\n> \"outermost\" level of development. So if branch \"featureY\" is branched from\n> \"projectX\" which is branched from \"main\", then it is reasonable to\n> rebase featureY against projectX. But rebasing projectX against master\n> will make integrating \"featureY\" more difficult. So you should either:\n>   - just do regular merges of projectX into main (and hopefully, if\n>     projectX is an aggregate of features, it won't have _that_ many\n>     merges, so the history should still be quite readable)\n>   - wait until all such \"featureY\" branches are merged into projectX,\n>     announce a freeze of branching from projectX, and then rebase it\n>     forward.\n> \n> -Peff\n\nAh,I see... The light is beginning to come on somewhat here, though it's\ndimmed somewhat by the remote/local branch confusion I mention above,\nwhich tends to imply that rebase is only really useful in local branches\nsince it is always the outer-most branch (assuming that my understanding\non that is correct, which it may well not be).\n\nI actually quite like the idea of the freezing before re-basing in the\nsub-branches. However, to answer the question of which merge strategy\nwould work best for us I think I need to actually set this up and have a\nplay with it to see how it all pans out using the various options available.\n\nThanks for your help!\n\n-- \n\nRuss\n"},{"id":"54044","messageId":"7vabra5tah.fsf@gitster.siamese.dyndns.org","threadId":"10016","inReplyTo":"46F97618.9010207@gmail.com","subject":"Re: Workflow question","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-09-25T21:28:22Z","receivedAt":"2007-09-25T21:28:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Russ Brown <pickscrape@gmail.com> writes:\n\n> I keep reading things similar to this and bit by bit I'm starting to get\n> it. :) I suppose this is one case in which it's definitely a\n> disadvantage to have a good understanding of svn before coming to git...\n>\n> <yoda>You must unlearn what you have learned</yoda>\n\nYou do not have to unlearn; if Jeff truly unlearned he wouldn't\nhave spotted you were trapped in SVN mentality.  You just need\nto learn there could be other ways ;-).\n\n> If you delete a branch that has commits on it that aren't referenced by\n> any other branches, will those commits be removed by something like git\n> pack or git gc?\n\nYes, eventually.\n\n> I suppose what has me the most confused is how a developer works with a\n> remote branch: I've come to understand that a developer should never\n> check out and work on a remote branch, and always create a local one and\n> work on that. If he does that using the above hierarchy, there then\n> becomes main->projectX->featureY->jeff_local_branch_of_featureY. Or is\n> is possible for a developer to work directory on a remote branch?\n\nThe statement in the last sentence does not make any sense.\nRemote is called remote because it is remote and supposed to be\nout of reach ;-)\n\nMore seriously, remotes are used as reference points so if you\n\"work directly on them\", you cannot use them as reference points\nany more; you defeat the sole purpose of existence of remotes.\n\nYou can work _without_ using remote tracking branches, but that\nis mostly for merge based workflow.  It appears that you are\nleaning towards rebase-heavy workflow, so I do not think it is\napplicable to your project.\n"},{"id":"54053","messageId":"46F98DFA.7040705@op5.se","threadId":"10016","inReplyTo":"46F96493.8000607@gmail.com","subject":"Re: Workflow question","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-09-25T22:38:50Z","receivedAt":"2007-09-25T22:38:50Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Russ Brown wrote:\n> Andreas Ericsson wrote:\n>> Russ Brown wrote:\n>>> Hi,\n>>>\n>>> I've been trying to think of a git workflow that we could use to replace\n>>> our current svn/svk setup without simply using git in exactly the same\n>>> way that we use svn/svk.\n>>>\n>>> Basically, we develop, maintain and enhance a website. On the central\n>>> repo is trunk which represents live, and any number of project branches.\n>>> Developers don't use local branches: they check out the project branches\n>>> they're working on and commit to those. Developers merge from trunk to\n>>> project branch from time to time to keep them current, and when a\n>>> project rolls out the branch is merged to trunk.\n>>>\n>>> In addition to the obvious advantages that git would give us (such as\n>>> properly tracking that code author as opposed to the person who did the\n>>> merge), I'm wanting to gain the following benefits:\n>>>\n>>>  * The repository is very large (multiple gigabytes) and mirroring using\n>>> svk obviously takes a lot of time and space, so I'm keen to bring that\n>>> down, most likely by the developer not needing to mirror branches he\n>>> doesn't care about, or by being able to throw away branches he's done\n>>> with.\n>>>  * The repository is full of revisions that fail review (or break\n>>> things) and are fixed by subsequent revisions. We'd much rather be able\n>>> to have the developer fix his revisions before they get committed\n>>> 'upstream' (whatever that ends up meaning).\n>>>\n>>> I asked earlier about the email-based model that git itself uses, and\n>>> while it appears to work very well for a widely-dispersed open-source\n>>> project, I think it will be too cumbersome and slow for a fast-paced\n>>> internal development team who make a number of live releases every day.\n>>>\n>> We came to the same conclusion at our workplace. Email works great, but\n>> it's faster and better to just walk over to your colleague and ask what\n>> he/she thinks about something.\n>>\n> \n> Very true, with the minor exception that at my place there are\n> developers working at different sites, so the walk-over method will only\n> work for specific subsets of the team. :)\n> \n\nSo do what Peff suggested and use emails for code-review and git-pull/push\nfor shoveling the code around. He's got some valid points. Where I work,\nthere's mostly three or at most four developers at any one team, so paired\nprogramming or walking over works quite well. Otherwise we'd likely use the\npatch-emails-for-review thing.\n\n\n> Here's a question: is the creation and deletion of a branch also version\n> controlled as it is in Subversion? In other words, if I create a branch,\n> develop on it and delete it without merging it anywhere, will the\n> revisions hang around and get pulled down by future people cloning the\n> repository, or do they get thrown away?\n> \n\nThey don't get thrown away unless you garbage-collect them, using git-gc,\nbut they won't get propagated unless they can't be reached from a 'ref'\nor a ref's log. The refs that can be propagated between repos are tags\nand branches. There are others too, but they are less user-visible and\noftentimes more for housekeeping than anything else.\n\n>>\n>>>  4. Developers create a local branch of the project they\n>>> are working on and commit to that.\n>>>  5. Once they think they're done, they publish their branch to the\n>>> development repo and request for comments.\n>> Using topic-branches is a much better strategy, usually, since that\n>> allows each feature to be evaluated and improved on on its own, rather\n>> than having to merge *all* of a particular developers changes just to\n>> get desirable feature X. Note that cherry-pick provides ways of doing\n>> that anyways, but in a much less elegant way, and your integrator/\n>> release engineer will likely tear his hair out on a daily basis without\n>> topic branches.\n>>\n> \n> I've seen the term 'topic-branch' used here quite a bit but it's\n> unfamiliar to me. It is basically synonymous with what we call a\n> 'project branch'? i.e. Management decide that feature X is required so\n> we create a branch to develop it on which all developers on the project\n> commit to.\n> \n\nPretty much, yes. 'feature branch' and 'topic branch' are interchangeable.\n\n> Note that in step 4 above I mean the developer takes a local branch of\n> the topic branch. For example, we start projectX/main, and create branch\n> projectX on the shared repo. Developer 'jeff' works on the project and\n> so creates local branch projectX/jeff and begins work. In step 5 they\n> push this local branch to the shared repo so everyone can see it\n> (alternative to the 'walk-over' method or emailing). Note that all\n> changes jeff making in projectX/jeff are specific to the project branch,\n> so he can rebase against other changes that get committed to that\n> project branch.\n> \n> If colleagues don't like his changes he can create projectXjeff2 and try\n> again.\n> \n> Jeff can also have other local branches to keep separate changes he is\n> making on the other projects he is involved in.\n> \n> That's how I'd thought of it happening...\n> \n\nYe, that sounds about right.\n\n>>>  6. If all is not well, the developer creates a new local branch and\n>>> moves good revisions from his previous one to the new one, modifying\n>>> things as he goes, and republishes his new branch.\n>>>  7. If all is well, their works gets merged or rebased onto the main\n>>> project branch, and once that's ready it gets pushed to the master and\n>>> rolled to live. The developer's individual branches get deleted from the\n>>> dev repo since they're no longer required.\n>> Topic branches would work the same, basically, except they can be pushed up\n>> for review a lot faster.\n>>\n>> If all the pushing gets cumbersome, it also makes it easy to send the\n>> patches\n>> out as emails for discussion. It's usually easier to let git handle the\n>> actual code transmissions, but discussing patches in emails works quite\n>> well if it's intended for a wider audience.\n>>\n> \n> Yes, I am going to experiment with this a little too to see just how\n> much work it would involve for the developers (if it's too much they\n> won't do it) :)\n> \n\nIt's a slightly steeper starting cost, but the maintenance costs go way\ndown, so the developers can spend more of their time doing fun and new\nstuff rather than figuring out how to get their already-ancient fixes\nmerged to the master-branch.\n\n>>>  8. From time to time the master branch gets merged to the project\n>>> branches. Developer's local branches can be rebased against the project\n>>> branch as they please.\n>>>\n>> criss-cross merging can turn kinda nasty though, as you may have a hard\n>> time\n>> finding *the* common point when you run into that rogue merge with conflict\n>> markers everywhere (it happens for everyone sooner or later).\n>>\n>> I'd suggest you rebase the developer/topic branches onto master with\n>> regular\n>> intervals instead.\n>>\n> \n> Having been using git-svn for a while I really like the clean history\n> result that rebase gives, however my understanding was that you should\n> never rebase any published branch as it could screw up clones of that\n> branch. In fact, this is what has me the most confused: how to rebase a\n> project branch that is on a shared repository against master when\n> everyone will have it cloned? Or is this something that I clearly don't\n> understand properly?\n> \n\nWell, afaiu you want every developer to have his own topic-branch, in\nwhich case they can simply rebase those topic-branches onto master,\nwhich will make sure they always know they're conflict-free with the\nlatest bugfixes and whatnot.\n\nThey don't really have to push their changes upstream until they're\nready for review.\n\n> (Thanks for your answers BTW Andreas)\n> \n\nnp. Happy to help :)\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"54067","messageId":"46F9A13E.4000608@gmail.com","threadId":"10016","inReplyTo":"7vabra5tah.fsf@gitster.siamese.dyndns.org","subject":"Re: Workflow question","fromName":"Russ Brown","fromEmail":"pickscrape@gmail.com","sentAt":"2007-09-26T00:01:02Z","receivedAt":"2007-09-26T00:01:02Z","isPatch":false,"sender":{"key":"pickscrape@gmail.com","avatar":null},"body":"Junio C Hamano wrote:\n> Russ Brown <pickscrape@gmail.com> writes:\n> \n>> I keep reading things similar to this and bit by bit I'm starting to get\n>> it. :) I suppose this is one case in which it's definitely a\n>> disadvantage to have a good understanding of svn before coming to git...\n>>\n>> <yoda>You must unlearn what you have learned</yoda>\n> \n> You do not have to unlearn; if Jeff truly unlearned he wouldn't\n> have spotted you were trapped in SVN mentality.  You just need\n> to learn there could be other ways ;-).\n> \n\nI suppose what I really mean is you need to stop assuming what you've\nalready learned. :)\n\n>> If you delete a branch that has commits on it that aren't referenced by\n>> any other branches, will those commits be removed by something like git\n>> pack or git gc?\n> \n> Yes, eventually.\n> \n>> I suppose what has me the most confused is how a developer works with a\n>> remote branch: I've come to understand that a developer should never\n>> check out and work on a remote branch, and always create a local one and\n>> work on that. If he does that using the above hierarchy, there then\n>> becomes main->projectX->featureY->jeff_local_branch_of_featureY. Or is\n>> is possible for a developer to work directory on a remote branch?\n> \n> The statement in the last sentence does not make any sense.\n> Remote is called remote because it is remote and supposed to be\n> out of reach ;-)\n> \n\nAh. I think I was a little confused by the fact that git does let you\ncheckout remote branches, through I see that it does warn you about it\nwhen you do it.\n\n> More seriously, remotes are used as reference points so if you\n> \"work directly on them\", you cannot use them as reference points\n> any more; you defeat the sole purpose of existence of remotes.\n> \n> You can work _without_ using remote tracking branches, but that\n> is mostly for merge based workflow.  It appears that you are\n> leaning towards rebase-heavy workflow, so I do not think it is\n> applicable to your project.\n\nRight, I think we're going to be aiming for that, though as I say I'm\ngoing to be experimenting a bit to see how things work when using both\napproaches.\n\nThanks.\n\n-- \n\nRuss\n"},{"id":"54072","messageId":"20070926004734.GA22617@segfault.peff.net","threadId":"10016","inReplyTo":"46F97618.9010207@gmail.com","subject":"Re: Workflow question","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-09-26T00:47:34Z","receivedAt":"2007-09-26T00:47:34Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Sep 25, 2007 at 03:56:56PM -0500, Russ Brown wrote:\n\n> I keep reading things similar to this and bit by bit I'm starting to get\n> it. :) I suppose this is one case in which it's definitely a\n> disadvantage to have a good understanding of svn before coming to git...\n> \n> <yoda>You must unlearn what you have learned</yoda>\n\nI prefer to think of it like a war movie, where I keep having\nnightmarish flashbacks to CVS.\n\nBut yes, from the outside git _looks_ a lot like other SCMs you may have\nused, and so it's tempting to keep their mental models. But that can\neasily end up being confusing, as you have found. Personally, I think it\npays to learn a little about what's going on under the hood, and then\nall of the commands Just Make Sense.\n\nThere are several explanations floating around; this is a pretty concise\none:\n\n  http://eagain.net/articles/git-for-computer-scientists/\n\n> If you delete a branch that has commits on it that aren't referenced by\n> any other branches, will those commits be removed by something like git\n> pack or git gc?\n\nThe 'git-prune' command will do this, though it is not run as part of\ngit-gc unless you specify --prune.\n\n> I suppose what has me the most confused is how a developer works with a\n> remote branch: I've come to understand that a developer should never\n> check out and work on a remote branch, and always create a local one and\n> work on that. If he does that using the above hierarchy, there then\n> becomes main->projectX->featureY->jeff_local_branch_of_featureY. Or is\n> is possible for a developer to work directory on a remote branch?\n\nAs Junio noted, you can't, because they're remote. What you have in your\nlocal repository is a remote _tracking branch_, which is a local ref\nthat tracks your idea of what the remote's branches are. And git will\nfeel free to overwrite the contents of that tracking branch whenever you\ndo a fetch or pull. So if you make commits on it, they are subject to\nbeing overwritten (and we note this property of the refs by putting them\nin the refs/remotes hierarchy, rather than refs/heads).\n\nSo in the case of our developer Jeff, his local repository will have a\n\"projectX/featureY\" branch that he works on. And he will also have a\nremote tracking branch \"origin/projectX/featureY\" which indicates where\nhis local repo thinks the remote repo points. And the remote repo will\nhave a \"projectX/featureY\" branch, of course.\n\n> Ah,I see... The light is beginning to come on somewhat here, though it's\n> dimmed somewhat by the remote/local branch confusion I mention above,\n> which tends to imply that rebase is only really useful in local branches\n> since it is always the outer-most branch (assuming that my understanding\n> on that is correct, which it may well not be).\n\nYes, although the important distinction is not so much \"this is a local\nbranch\" but rather \"this is a _published_ branch\" which implies that\nother people are looking at (and possibly basing work on) it.\n\n> I actually quite like the idea of the freezing before re-basing in the\n> sub-branches. However, to answer the question of which merge strategy\n> would work best for us I think I need to actually set this up and have a\n> play with it to see how it all pans out using the various options available.\n\nYes, it is easy to get into academic discussions of setups, but in\npractice you need to find a workflow that is smooth for your team.\n\nOn one web-based project I work on, we have a setup like this (which is\nvery centralized):\n\n  - a central repo resides on a development server with two branches,\n    \"master\" and \"production\"\n  - each developer clones the repo with a working tree\n  - some developers develop directly on 'master' if they have small\n    changes, or only work on one thing at a time; other developers use\n    topic branches to work on simultaneous changes\n  - any developer can push to master; it is expected that your code is\n    in a reasonable state, since it will now be consumed by other\n    developers. Anything that has made it into master is considered\n    published and should not be rebased. It is up to developers whether\n    they want to rebase their work before publishing or to simply merge.\n  - some developers communicate directly with each other: \"hey, check\n    out branch 'foo' in my repo\" or \"what do you think of this patch?\"\n  - The live site has a repo cloned from the central repo, pointing at\n    \"production\".\n  - there is a test site with a repo cloned from the master.\n    Occasionally the master branch is pulled and tested. If it passes,\n    it is pushed to the \"production\" branch. In addition, small\n    immediate fixes can go onto \"production\", tested, and then pushed to\n    the central repo's \"production\"\n\nSo this is not necessarily using the distributed nature of that much,\nbut it allows those developers who aren't very comfortable with SCMs to\nstick to a \"pull, hack, push\" workflow. And those who want to can do\nmore interesting things if it helps them.\n\n-Peff\n"},{"id":"54077","messageId":"20070926015146.GA25175@diana.vm.bytemark.co.uk","threadId":"10016","inReplyTo":"20070926004734.GA22617@segfault.peff.net","subject":"Re: Workflow question","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-09-26T01:51:46Z","receivedAt":"2007-09-26T01:51:46Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-09-25 20:47:34 -0400, Jeff King wrote:\n\n> Personally, I think it pays to learn a little about what's going on\n> under the hood, and then all of the commands Just Make Sense.\n>\n> There are several explanations floating around; this is a pretty\n> concise one:\n>\n>   http://eagain.net/articles/git-for-computer-scientists/\n\nI agree. Once you understand that history in git is just a DAG of\ncommits, and that \"branches\" are just named pointers into this DAG to\nhelp the user remember where to attach new commits, everything starts\nto Just Make Sense.\n\n(And FWIW, that article was quite good as I recall.)\n\n-- \nKarl Hasselström, kha@treskal.com\n      www.treskal.com/kalle\n"},{"id":"54082","messageId":"46F9CA2A.7000107@gmail.com","threadId":"10016","inReplyTo":"20070926004734.GA22617@segfault.peff.net","subject":"Re: Workflow question","fromName":"Russ Brown","fromEmail":"pickscrape@gmail.com","sentAt":"2007-09-26T02:55:38Z","receivedAt":"2007-09-26T02:55:38Z","isPatch":false,"sender":{"key":"pickscrape@gmail.com","avatar":null},"body":"Jeff King wrote:\n> On Tue, Sep 25, 2007 at 03:56:56PM -0500, Russ Brown wrote:\n> \n>> I keep reading things similar to this and bit by bit I'm starting to get\n>> it. :) I suppose this is one case in which it's definitely a\n>> disadvantage to have a good understanding of svn before coming to git...\n>>\n>> <yoda>You must unlearn what you have learned</yoda>\n> \n> I prefer to think of it like a war movie, where I keep having\n> nightmarish flashbacks to CVS.\n> \n> But yes, from the outside git _looks_ a lot like other SCMs you may have\n> used, and so it's tempting to keep their mental models. But that can\n> easily end up being confusing, as you have found. Personally, I think it\n> pays to learn a little about what's going on under the hood, and then\n> all of the commands Just Make Sense.\n> \n> There are several explanations floating around; this is a pretty concise\n> one:\n> \n>   http://eagain.net/articles/git-for-computer-scientists/\n> \n\nYes, this is very helpful indeed: thank you for that. /me bookmarks. I\nhadn't actually realised that rebase creates new commits and replaces\nyour old ones: I'd thought they just got 'moved' (dunno how I thought it\nworked though!)\n\n>> If you delete a branch that has commits on it that aren't referenced by\n>> any other branches, will those commits be removed by something like git\n>> pack or git gc?\n> \n> The 'git-prune' command will do this, though it is not run as part of\n> git-gc unless you specify --prune.\n> \n\nAnother thing makes sense now (helped by the link above also).\n\n>> I suppose what has me the most confused is how a developer works with a\n>> remote branch: I've come to understand that a developer should never\n>> check out and work on a remote branch, and always create a local one and\n>> work on that. If he does that using the above hierarchy, there then\n>> becomes main->projectX->featureY->jeff_local_branch_of_featureY. Or is\n>> is possible for a developer to work directory on a remote branch?\n> \n> As Junio noted, you can't, because they're remote. What you have in your\n> local repository is a remote _tracking branch_, which is a local ref\n> that tracks your idea of what the remote's branches are. And git will\n> feel free to overwrite the contents of that tracking branch whenever you\n> do a fetch or pull. So if you make commits on it, they are subject to\n> being overwritten (and we note this property of the refs by putting them\n> in the refs/remotes hierarchy, rather than refs/heads).\n> \n> So in the case of our developer Jeff, his local repository will have a\n> \"projectX/featureY\" branch that he works on. And he will also have a\n> remote tracking branch \"origin/projectX/featureY\" which indicates where\n> his local repo thinks the remote repo points. And the remote repo will\n> have a \"projectX/featureY\" branch, of course.\n> \n\nI'm just wondering at this point why git lets you checkout remote\ntracking branches if it's something you really shouldn't do. Unless it's\nsomething you want to be able to do in edge cases to fix screwups maybe?\n\n>> Ah,I see... The light is beginning to come on somewhat here, though it's\n>> dimmed somewhat by the remote/local branch confusion I mention above,\n>> which tends to imply that rebase is only really useful in local branches\n>> since it is always the outer-most branch (assuming that my understanding\n>> on that is correct, which it may well not be).\n> \n> Yes, although the important distinction is not so much \"this is a local\n> branch\" but rather \"this is a _published_ branch\" which implies that\n> other people are looking at (and possibly basing work on) it.\n> \n>> I actually quite like the idea of the freezing before re-basing in the\n>> sub-branches. However, to answer the question of which merge strategy\n>> would work best for us I think I need to actually set this up and have a\n>> play with it to see how it all pans out using the various options available.\n> \n> Yes, it is easy to get into academic discussions of setups, but in\n> practice you need to find a workflow that is smooth for your team.\n> \n> On one web-based project I work on, we have a setup like this (which is\n> very centralized):\n> \n>   - a central repo resides on a development server with two branches,\n>     \"master\" and \"production\"\n>   - each developer clones the repo with a working tree\n>   - some developers develop directly on 'master' if they have small\n>     changes, or only work on one thing at a time; other developers use\n>     topic branches to work on simultaneous changes\n>   - any developer can push to master; it is expected that your code is\n>     in a reasonable state, since it will now be consumed by other\n>     developers. Anything that has made it into master is considered\n>     published and should not be rebased. It is up to developers whether\n>     they want to rebase their work before publishing or to simply merge.\n>   - some developers communicate directly with each other: \"hey, check\n>     out branch 'foo' in my repo\" or \"what do you think of this patch?\"\n>   - The live site has a repo cloned from the central repo, pointing at\n>     \"production\".\n>   - there is a test site with a repo cloned from the master.\n>     Occasionally the master branch is pulled and tested. If it passes,\n>     it is pushed to the \"production\" branch. In addition, small\n>     immediate fixes can go onto \"production\", tested, and then pushed to\n>     the central repo's \"production\"\n> \n> So this is not necessarily using the distributed nature of that much,\n> but it allows those developers who aren't very comfortable with SCMs to\n> stick to a \"pull, hack, push\" workflow. And those who want to can do\n> more interesting things if it helps them.\n> \n\nThanks for this, it's very useful to read examples of workflows in\nactual use. In fact, I was thinking the other day that it would be good\nto have a site that acts as a directory of many different workflows,\nincluding descriptions of how they work, how you actually go about\nsetting it up and using it day to day (i.e. lists of commands for each\nrole/task) and the pros/cons that it provides. I reckon that would help\nnewbies out quite a bit (if only for the examples). I've seen a few\nindividual examples of workflow but nothing like a comprehensive set of\nthem.\n\n> -Peff\n\nThanks!\n\n-- \n\nRuss\n"},{"id":"54085","messageId":"7vlkau0zah.fsf@gitster.siamese.dyndns.org","threadId":"10016","inReplyTo":"46F9CA2A.7000107@gmail.com","subject":"Re: Workflow question","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-09-26T05:29:58Z","receivedAt":"2007-09-26T05:29:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Russ Brown <pickscrape@gmail.com> writes:\n\n> I'm just wondering at this point why git lets you checkout remote\n> tracking branches if it's something you really shouldn't do. Unless it's\n> something you want to be able to do in edge cases to fix screwups maybe?\n\nYou actually never checkout \"remote tracking branches\".\n\nYou can be in two states, either you are on a branch (meaning,\nif you create a commit, the new commit will have the current tip\ncommit of that branch as its first parent and will become the\nnew tip commit of that branch), or you aren't on _any_ branch.\n\nThe latter state is often affectionately called \"detached HEAD\"\nstate.\n\nThis is primarily useful for sightseeing.  Sometimes people\nwould want to check out a commit that is not a tip of any\nbranch.  The most typical one is \"I want to have a checkout of\nversion 2.6.17\", and people call that (loosely) as \"checking out\na tag\".  In the same way, you can \"checkout a remote tracking\nbranch\" (but if you want to be anal in terminology, you never\n\"check out a tag\" nor \"check out a remote branch\"---you are\ndetaching your HEAD at the named commit (which could be the one\npointed at by the tag, or the one at the tip of your remote\ntracking branch).\n\nDetached HEAD state allows you to make further commits and\nmerges.  Because git allows you to create a new branch from the\ncurrent commit (i.e. whatever HEAD points at, be it on any\nbranch or detached) without losing local changes in the index\nnor the work tree, this is often handy for doing quick fixups and\nexperiments --- you first start on detached HEAD and if it turns\nout not to be so \"quick\" fixup, at that point you can create a\nreal branch so that you can continue working on it without\nlosing track.\n\n> Thanks for this, it's very useful to read examples of workflows in\n> actual use. In fact, I was thinking the other day that it would be good\n> to have a site that acts as a directory of many different workflows,\n> including descriptions of how they work, how you actually go about\n> setting it up and using it day to day (i.e. lists of commands for each\n> role/task) and the pros/cons that it provides. I reckon that would help\n> newbies out quite a bit (if only for the examples). I've seen a few\n> individual examples of workflow but nothing like a comprehensive set of\n> them.\n\n\"Everyday\" might be a good starting point for catalogs of\nworkflows for people playing various roles.\n"},{"id":"54097","messageId":"20070926124243.GB13739@coredump.intra.peff.net","threadId":"10016","inReplyTo":"46F9CA2A.7000107@gmail.com","subject":"Re: Workflow question","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-09-26T12:42:43Z","receivedAt":"2007-09-26T12:42:43Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Sep 25, 2007 at 09:55:38PM -0500, Russ Brown wrote:\n\n> Yes, this is very helpful indeed: thank you for that. /me bookmarks. I\n> hadn't actually realised that rebase creates new commits and replaces\n> your old ones: I'd thought they just got 'moved' (dunno how I thought it\n> worked though!)\n\nIt's a necessity, since the commits are named by hash, and the hash\nencompasses _all_ of the history. So the same change at a different\nlocation in history will be a different commit.\n\nAnd that is why rebases can make merging harder. Git can very quickly\ncompare two commits by hash and say \"these are the same commit\", or look\nat them and say \"one side has these changes, the other side has these\nother changes, and here is where they meet.\" Rebasing ruins that, since\nthe same changes occur in two places with different names.\n\n> I'm just wondering at this point why git lets you checkout remote\n> tracking branches if it's something you really shouldn't do. Unless it's\n> something you want to be able to do in edge cases to fix screwups maybe?\n\nJunio explained in much more detail, but I use it largely for read-only\naccess (\"oh, let me speed-test my branch against the upstream 'master'\";\ngit-checkout master; test test test; git-checkout mybranch).\n\n> Thanks for this, it's very useful to read examples of workflows in\n> actual use. In fact, I was thinking the other day that it would be good\n> to have a site that acts as a directory of many different workflows,\n> including descriptions of how they work, how you actually go about\n> setting it up and using it day to day (i.e. lists of commands for each\n> role/task) and the pros/cons that it provides. I reckon that would help\n> newbies out quite a bit (if only for the examples). I've seen a few\n> individual examples of workflow but nothing like a comprehensive set of\n> them.\n\nI agree. That sort of information is sprinkled throughout the mailing\nlist, but it might be nice on a wiki. I have thought of it as a sort of\n\"git cookbook\" where you say \"here is a recipe for accomplishing X\". The\nuser manual comes close to this for smaller tasks.\n\n-Peff\n"}]}