{"thread":{"id":"1536","subject":"[RFC] Patches exchange is bad?","startedAt":"2005-08-16T20:01:32Z","lastAt":"2005-08-17T17:12:36Z","messageCount":5,"participants":["Marco Costalba","Johannes Schindelin","Junio C Hamano","Martin Langhoff","Catalin Marinas"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"7376","messageId":"20050816200132.88287.qmail@web26304.mail.ukl.yahoo.com","threadId":"1536","inReplyTo":null,"subject":"[RFC] Patches exchange is bad?","fromName":"Marco Costalba","fromEmail":"mcostalba@yahoo.it","sentAt":"2005-08-16T20:01:32Z","receivedAt":"2005-08-16T20:01:32Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"Hi,\n\nI would like to ask the list about something I'am thinking about,\nand I'am not sure it's a good idea.\n\nSuppose a possible scenario involves using a couple of git archives, one \nfor releases and stable code, say MAIN, and one for experimental stuff \nor new development, say HEAD.\n\nSuppose there is stuff in HEAD you don't want merged in MAIN, more,\nyou need to update MAIN with only a subset of patches in HEAD, peraphs \nin different order. Or simply, you are not interested to see the history \nof the HEAD tree when looking MAIN. All this points could keep you \nfrom merging.\n\nI have mocked up a very simple and very stupid 'drag and drop' function.\nBasically you drag some selected revs in another instance of qgit, open on \na different archive.\n\nWhat happpens in the background is that git-format-patch-script is feeded \nwith the selected revs and a bunch of temporary patch files are created, \nthen git-applymbox (re)creates the corresponding commits in the destination \narchive.\n\nIt is just a very thin layer above the two git scripts, the only extra work \nis the cleaning up of some info that git-format-patch-script automatically adds, \nso that the new commits look like the originals (i.e. same header and description).\n\nI've built-up this thing mainly because I found it useful for me, but I have \nsome concerns that this is the correct way to go, the way git it's meant to be used.\n\nIf there is some interest for this I can push something on SF, after a due polishing, \nbut if it is deeply broken I prefer discard and eventually switch to a more consistent\nworkflow.\n\nWhat do you think?\n\n\tMarco\n\n\n__________________________________________________\nDo You Yahoo!?\nTired of spam? Yahoo! Mail has the best spam protection around \nhttp://mail.yahoo.com \n"},{"id":"7378","messageId":"Pine.LNX.4.63.0508162238400.19656@wgmdd8.biozentrum.uni-wuerzburg.de","threadId":"1536","inReplyTo":"20050816200132.88287.qmail@web26304.mail.ukl.yahoo.com","subject":"Re: [RFC] Patches exchange is bad?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-08-16T20:39:41Z","receivedAt":"2005-08-16T20:39:41Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 16 Aug 2005, Marco Costalba wrote:\n\n> Suppose a possible scenario involves using a couple of git archives, one \n> for releases and stable code, say MAIN, and one for experimental stuff \n> or new development, say HEAD.\n> \n> Suppose there is stuff in HEAD you don't want merged in MAIN, more,\n> you need to update MAIN with only a subset of patches in HEAD, peraphs \n> in different order. Or simply, you are not interested to see the history \n> of the HEAD tree when looking MAIN. All this points could keep you \n> from merging.\n\nThis looks like a good description of cherry picking. See StGIT (and to a \ncertain extent, git-cherry) for that.\n\nCiao,\nDscho\n"},{"id":"7381","messageId":"7vzmrh8uis.fsf@assigned-by-dhcp.cox.net","threadId":"1536","inReplyTo":"20050816200132.88287.qmail@web26304.mail.ukl.yahoo.com","subject":"Re: [RFC] Patches exchange is bad?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-16T21:02:51Z","receivedAt":"2005-08-16T21:02:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Marco Costalba writes:\n\n> It is just a very thin layer above the two git scripts, the only extra work \n> is the cleaning up of some info that git-format-patch-script automatically adds, \n> so that the new commits look like the originals (i.e. same header and description).\n\n> What do you think?\n\nAll good. The existing tools are designed to work well in the\nfollowing workflow:\n\n $ git format-patch --mbox master..pu\n $ cat 000[234]-*.txt >to-apply\n $ git checkout master\n $ git applymbox to-apply\n $ mv .git/refs/heads/pu .git/refs/heads/old-pu\n $ git checkout -b pu master\n $ git applymbox 0001-*.txt\n\nto advance \"master\" with selected commits, possibly reordered,\nfrom the \"pu\" branch, and rebase the \"pu\" branch using the\nremaining commits.\n\nI would like to know a bit about \"git format-patch\" adding extra\ninfo that you needed to get rid of. It shouldn't be necessary.\n"},{"id":"7386","messageId":"46a038f9050816143153e4104b@mail.gmail.com","threadId":"1536","inReplyTo":"20050816200132.88287.qmail@web26304.mail.ukl.yahoo.com","subject":"Re: [RFC] Patches exchange is bad?","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2005-08-16T21:31:17Z","receivedAt":"2005-08-16T21:31:17Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 8/17/05, Marco Costalba wrote:\n> What do you think?\n\n>From what I understand, you'll want the StGIT infrastructure. If you\nuse git/cogito, there is an underlying assumption that you'll want\nall the patches merged across, and a simple cg-update will bring in\nall the pending stuff.\n\ncheers,\n\n\nmartin\n"},{"id":"7449","messageId":"tnxvf24o5bv.fsf@arm.com","threadId":"1536","inReplyTo":"20050816200132.88287.qmail@web26304.mail.ukl.yahoo.com","subject":"Re: [RFC] Patches exchange is bad?","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-08-17T17:12:36Z","receivedAt":"2005-08-17T17:12:36Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"Marco Costalba wrote:\n> Suppose a possible scenario involves using a couple of git archives, one \n> for releases and stable code, say MAIN, and one for experimental stuff \n> or new development, say HEAD.\n>\n> Suppose there is stuff in HEAD you don't want merged in MAIN, more,\n> you need to update MAIN with only a subset of patches in HEAD, peraphs \n> in different order. Or simply, you are not interested to see the history \n> of the HEAD tree when looking MAIN. All this points could keep you \n> from merging.\n\nAs others already recommended StGIT, I will just add a simple usage\nscenario (I do this with my StGIT repository).\n\nThe MAIN/stable repository (or branch) is only managed with GIT, not\nStGIT. The HEAD one is managed with StGIT (only, you can use 'stg\nclone'). You can create patches, modify them etc. (I updated the\nREADME in the latest snapshot and it contains some kind of tutorial).\n\nOnce you want a subset of these patches merged into MAIN, just pop\neverything from the stack and only push those you want merged, in the\norder you want (if there are some dependencies, the push will fail and\nyou can correct them or the order). When you are happy with the\npatches pushed on the stack, just do a 'git pull ' in the MAIN\nrepository. After this, doing a 'stg pull
' in the HEAD one will\nmark the patches already integrated into MAIN as empty and you can\nsafely remove them ('stg clean' does this automatically).\n\nThis way I found StGIT useful for maintainers as well, not only for\ncontributors.\n\n-- \nCatalin\n"}]}