{"thread":{"id":"860","subject":"git/cogito usage scenarios for CVS refugee","startedAt":"2005-06-08T09:51:17Z","lastAt":"2005-06-08T20:26:03Z","messageCount":3,"participants":["Martin Langhoff","Petr Baudis"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"4694","messageId":"46a038f9050608025152af4163@mail.gmail.com","threadId":"860","inReplyTo":null,"subject":"git/cogito usage scenarios for CVS refugee","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2005-06-08T09:51:17Z","receivedAt":"2005-06-08T09:51:17Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"Trying to get my head around what usage patterns the git\ninfrastructure supports. I'm interested in exploring more git-centric\napproaches...\n\nFor a project that uses CVS with a classic HEAD and FOO_15_STABLE\napproach, where FOO_15_STABLE gets only fixes -- how do I manage HEAD\nand XX_STABLE where some patches that work well in HEAD I may decide\nto merge into XX_STABLE, and some security patch may be applied first\nto XX_STABLE and then to HEAD? I can apply the patch on both branches\n-- yep. But does git help me in keeping track of what's been merged?\n\nDoes git help in any way to keep track of patches across 2.6.11.12 and\n2.6.12rc5 ?\n\nIn a git-based project, one developer is about to merge from someone\nelse's tree, are there any tools to review the patchlog that is about\nto be applied (or replayed?) against his tree? Is there any way to say\n\"of the 20 commits that I'm about to merge, hold off 2\" other than\nletting git apply them ... and backing them out right next?\n\nAnd generally, is there any long-lived branch support? If I am to run\na \"local branch\" of the Linux kernel, does git help me at all?\n\nSo far I think the answer is \"no -- you'll need to keep track of your\ndamn patches somewhere else\" ;-) but there's a lot about the git\nmindset I don't quite understand yet. And I'm sure that the workflow\nof the Linux team must have some ancillary tools & strategies to keep\ntrack of this.\n\ncheers,\n\n\nmartin\n"},{"id":"4710","messageId":"20050608183414.GD982@pasky.ji.cz","threadId":"860","inReplyTo":"46a038f9050608025152af4163@mail.gmail.com","subject":"Re: git/cogito usage scenarios for CVS refugee","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-06-08T18:34:14Z","receivedAt":"2005-06-08T18:34:14Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Wed, Jun 08, 2005 at 11:51:17AM CEST, I got a letter\nwhere Martin Langhoff <martin.langhoff@gmail.com> told me that...\n> Trying to get my head around what usage patterns the git\n> infrastructure supports. I'm interested in exploring more git-centric\n> approaches...\n> \n> For a project that uses CVS with a classic HEAD and FOO_15_STABLE\n> approach, where FOO_15_STABLE gets only fixes -- how do I manage HEAD\n> and XX_STABLE where some patches that work well in HEAD I may decide\n> to merge into XX_STABLE, and some security patch may be applied first\n> to XX_STABLE and then to HEAD? I can apply the patch on both branches\n> -- yep. But does git help me in keeping track of what's been merged?\n> \n> Does git help in any way to keep track of patches across 2.6.11.12 and\n> 2.6.12rc5 ?\n> \n> In a git-based project, one developer is about to merge from someone\n> else's tree, are there any tools to review the patchlog that is about\n> to be applied (or replayed?) against his tree? Is there any way to say\n> \"of the 20 commits that I'm about to merge, hold off 2\" other than\n> letting git apply them ... and backing them out right next?\n\nThe answer for all those questions is that git has no support for\ncherrypicking (that sucks, but is hard to fix right now). git does ok\nas long as one branch is superset of the other, but it does not help you\notherwise.\n\n> And generally, is there any long-lived branch support? If I am to run\n> a \"local branch\" of the Linux kernel, does git help me at all?\n\nI don't understand what do you mean. How does a long-lived branch differ\nfrom a short-lived one and what support would you expect/like?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nC++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor\n"},{"id":"4720","messageId":"46a038f9050608132625803d@mail.gmail.com","threadId":"860","inReplyTo":"20050608183414.GD982@pasky.ji.cz","subject":"Re: git/cogito usage scenarios for CVS refugee","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2005-06-08T20:26:03Z","receivedAt":"2005-06-08T20:26:03Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 6/9/05, Petr Baudis <pasky@ucw.cz> wrote:\n> The answer for all those questions is that git has no support for\n> cherrypicking (that sucks, but is hard to fix right now). git does ok\n> as long as one branch is superset of the other, but it does not help you\n> otherwise.\n\nAgreed -- there's no support for cherry picking. Is there some\ngit-specific strategy perhaps?\n\nFor example, when using cvs, which doesn't support cherry picking\neither, people running \"stable\" branches use a \"merged\" tag that they\nmove around to indicate how far the bugfixes on the stable branch have\nbeen merged into head. It doesn't allow cherry picking, but it works\nand it is a valuable (if hackish) practice.\n\n> > And generally, is there any long-lived branch support? If I am to run\n> > a \"local branch\" of the Linux kernel, does git help me at all?\n> \n> I don't understand what do you mean. How does a long-lived branch differ\n> from a short-lived one and what support would you expect/like?\n\nSomething along the lines of what I've mention above. I mean, not\nliterally moving a tag around, but to have some basic suport to\nidentify what the merge status is. As soon as we are one commit out of\nsync, git stops being useful.\n\nIt doesn't need to happen inside git actually -- perhaps there is just\nenough support to add an identifier in each commit msg, so we could\nhave ancillary scripts that perform some simple patch tracking for\nsimple scenarios.\n\nWhen an automatic merge succeeds, does git bring in the commitmsg and\na unique identifier of the commit?\n\ncheers,\n\n\nmartin\n"}]}