{"thread":{"id":"13789","subject":"User's mailing list? And multiple cherry pick","startedAt":"2008-06-04T06:55:02Z","lastAt":"2008-06-04T18:09:31Z","messageCount":22,"participants":["David","Junio C Hamano","Jakub Narebski","Stephan Beyer","Johan Herland","Wincent Colaiuta","Karl Hasselström","Miklos Vajna","Theodore Tso","Björn Steinbrink"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"78591","messageId":"18c1e6480806032355q2002fe0ej1f37dbd7dbd4802b@mail.gmail.com","threadId":"13789","inReplyTo":null,"subject":"User's mailing list? And multiple cherry pick","fromName":"David","fromEmail":"wizzardx@gmail.com","sentAt":"2008-06-04T06:55:02Z","receivedAt":"2008-06-04T06:55:02Z","isPatch":false,"sender":{"key":"wizzardx@gmail.com","avatar":"https://gravatar.com/avatar/045483b90f748c2423d8321911ea9034f83f124c3e9ddb25e96011e6d68b20fb?d=mp&s=160"},"body":"Hi list.\n\nI've tried Googling for these, and checked the FAQ.\n\n1) Is there a separate Git Users mailing list or FAQ?\n\nSo that git noobs like myself don't bother the developers directly :-)\nAlso so that non-git-developer users who want to help other users\ndon't get a lot of mails with patches & git internal development\ndiscussions.\n\n2) Is it possible to cherry pick multiple patches?\n\nSometimes git rebase isn't appropriate, and it's a pain to do multiple\n'git-cherry-pick' commands. Here is my current recipe:\n\nfor C in $(git log --reverse .. --pretty=format:%H);\ndo git-cherry-pick $C; done\n\nIs there an easier syntax for doing this?\n\nDavid.\n"},{"id":"78592","messageId":"7vmym1zny4.fsf@gitster.siamese.dyndns.org","threadId":"13789","inReplyTo":"18c1e6480806032355q2002fe0ej1f37dbd7dbd4802b@mail.gmail.com","subject":"Re: User's mailing list? And multiple cherry pick","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-04T06:58:11Z","receivedAt":"2008-06-04T06:58:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David writes:\n\n> Hi list.\n>\n> I've tried Googling for these, and checked the FAQ.\n>\n> 1) Is there a separate Git Users mailing list or FAQ?\n>\n> So that git noobs like myself don't bother the developers directly :-)\n> Also so that non-git-developer users who want to help other users\n> don't get a lot of mails with patches & git internal development\n> discussions.\n>\n> 2) Is it possible to cherry pick multiple patches?\n>\n> Sometimes git rebase isn't appropriate, and it's a pain to do multiple\n> 'git-cherry-pick' commands. Here is my current recipe:\n>\n> for C in $(git log --reverse .. --pretty=format:%H);\n> do git-cherry-pick $C; done\n>\n> Is there an easier syntax for doing this?\n\nrebase --onto?\n"},{"id":"78593","messageId":"18c1e6480806040013l72da09aem30f91183e4fcbe41@mail.gmail.com","threadId":"13789","inReplyTo":"7vmym1zny4.fsf@gitster.siamese.dyndns.org","subject":"Re: User's mailing list? And multiple cherry pick","fromName":"David","fromEmail":"wizzardx@gmail.com","sentAt":"2008-06-04T07:13:18Z","receivedAt":"2008-06-04T07:13:18Z","isPatch":false,"sender":{"key":"wizzardx@gmail.com","avatar":"https://gravatar.com/avatar/045483b90f748c2423d8321911ea9034f83f124c3e9ddb25e96011e6d68b20fb?d=mp&s=160"},"body":">>\n>> for C in $(git log --reverse .. --pretty=format:%H);\n>> do git-cherry-pick $C; done\n>>\n>> Is there an easier syntax for doing this?\n>\n> rebase --onto?\n>\n\nThanks, I checked the manuals further, and it looks like this will\n(mostly) do what I need.\n\nWhat's still missing is multiple cherry pick ;-)\n\nIn other words, is there a simple way to *copy* a large number of\ncommits from one branch to another, without rebasing?\n\nDavid.\n"},{"id":"78595","messageId":"m3r6bdzm22.fsf@localhost.localdomain","threadId":"13789","inReplyTo":"18c1e6480806032355q2002fe0ej1f37dbd7dbd4802b@mail.gmail.com","subject":"Re: User's mailing list? And multiple cherry pick","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-06-04T07:39:07Z","receivedAt":"2008-06-04T07:39:07Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"David writes:\n\n> I've tried Googling for these, and checked the FAQ.\n> \n> 1) Is there a separate Git Users mailing list or FAQ?\n> \n> So that git noobs like myself don't bother the developers directly :-)\n> Also so that non-git-developer users who want to help other users\n> don't get a lot of mails with patches & git internal development\n> discussions.\n\nThere is Git User's mailing list (\"Git for human beings\", heh)\n git-users@googlegroups.com\n http://groups.google.com/group/git-users\n nntp://news.gmane.org/gmane.comp.version-control.git.user\n \nThere is GitFaq at Git Wiki:\n http://git.or.cz/gitwiki/GitFaq\n\n> 2) Is it possible to cherry pick multiple patches?\n> \n> Sometimes git rebase isn't appropriate, and it's a pain to do multiple\n> 'git-cherry-pick' commands. Here is my current recipe:\n> \n> for C in $(git log --reverse .. --pretty=format:%H);\n> do git-cherry-pick $C; done\n> \n> Is there an easier syntax for doing this?\n\n $ git rebase --onto\n $ git rebase --onto --interactive\n\n(if you want to copy, just create new branch using \"git branch\", or\nsomething).\n\nWhy can't you simply use merge, BTW?\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"78597","messageId":"20080604080017.GB7752@leksak.fem-net","threadId":"13789","inReplyTo":"18c1e6480806032355q2002fe0ej1f37dbd7dbd4802b@mail.gmail.com","subject":"Re: User's mailing list? And multiple cherry pick","fromName":"Stephan Beyer","fromEmail":"s-beyer@gmx.net","sentAt":"2008-06-04T08:00:17Z","receivedAt":"2008-06-04T08:00:17Z","isPatch":false,"sender":{"key":"s-beyer@gmx.net","avatar":"https://avatars.githubusercontent.com/u/143889?v=4"},"body":"> for C in $(git log --reverse .. --pretty=format:%H);\n> do git-cherry-pick $C; done\n> \n> Is there an easier syntax for doing this?\n\nPut this into a script and you've got an easier syntax ;-)\nBut note that does not get cherry-picked then.\nUse ^.. (or $1^..$2).\n\nExcept if there's a conflict.\n\nWell, though it is far from finished, you could fetch git-sequencer.sh[1]\n 1. http://tinyurl.com/6xtdvl\n\nchmod +x it and do\n\nfor C in $(git log --reverse .. --pretty=format:%H);\ndo echo pick $C ; done >temporaryfile\n/where/you/put/it/git-sequencer.sh temporaryfile\n\nHope I could help.\n\nRegards,\n Stephan\n\n-- \nStephan Beyer , PGP 0x6EDDD207FCC5040F\n"},{"id":"78598","messageId":"m3mym1zkus.fsf@localhost.localdomain","threadId":"13789","inReplyTo":"18c1e6480806040013l72da09aem30f91183e4fcbe41@mail.gmail.com","subject":"Re: User's mailing list? And multiple cherry pick","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-06-04T08:05:07Z","receivedAt":"2008-06-04T08:05:07Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"David writes:\n\n[Please don't remove quote attributions]\n\n>>> for C in $(git log --reverse .. --pretty=format:%H);\n>>> do git-cherry-pick $C; done\n>>>\n>>> Is there an easier syntax for doing this?\n>>\n>> rebase --onto?\n>>\n> \n> Thanks, I checked the manuals further, and it looks like this will\n> (mostly) do what I need.\n> \n> What's still missing is multiple cherry pick ;-)\n> \n> In other words, is there a simple way to *copy* a large number of\n> commits from one branch to another, without rebasing?\n\n # make temporary branch to not move to-be-copied during rebase\n $ git checkout -b tmp-rebase to-be-copied\n # copy commits; results are in just created temporary branch\n $ git rebase --onto branch copy-from tmp-rebase\n # check if everything is all right and rename temporary branch\n # to final name\n $ git branch -M tmp-rebase branch\n\nThat said, cherry-picking multiple commits is often requested feature.\nI guess that git-sequencer GSoC 2008 project would help in having it\nfinally implemented. BTW. why can't you use topic branches and\nmerging?\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"78599","messageId":"18c1e6480806040111s606701dfwc8a2ae5f742307b5@mail.gmail.com","threadId":"13789","inReplyTo":"m3r6bdzm22.fsf@localhost.localdomain","subject":"Re: User's mailing list? And multiple cherry pick","fromName":"David","fromEmail":"wizzardx@gmail.com","sentAt":"2008-06-04T08:11:33Z","receivedAt":"2008-06-04T08:11:33Z","isPatch":false,"sender":{"key":"wizzardx@gmail.com","avatar":"https://gravatar.com/avatar/045483b90f748c2423d8321911ea9034f83f124c3e9ddb25e96011e6d68b20fb?d=mp&s=160"},"body":"> There is Git User's mailing list (\"Git for human beings\", heh)\n> git-users@googlegroups.com\n> http://groups.google.com/group/git-users\n> nntp://news.gmane.org/gmane.comp.version-control.git.user\n>\n> There is GitFaq at Git Wiki:\n> http://git.or.cz/gitwiki/GitFaq\n>\n\nThanks for the links.\n\n>> Is there an easier syntax for doing this?\n>\n> $ git rebase --onto\n> $ git rebase --onto --interactive\n>\n> (if you want to copy, just create new branch using \"git branch\", or\n> something).\n\nThanks, but this doesn't quite solve the problem. I'm on the verge of\nfiguring it out, and would appreciate any further tips :-)\n\nHere is an example:\n\no--o--O master\n \\\n o--o--X--X--X--X--o--o topic\n\nI want to copy the \"X\" patches from the topic branch over to master.\nThe other patches aren't appropriate for master for whatever reason.\neg, temporary debugging hacks, but I fixed a few problems in master in\nthe X patches and now want to apply them on top of master, and keep\nworking on \"topic\"\n\nI want to end up with a tree like this:\n\n\no--o--O--X'--X'--X'--X' master\n \\\n o--o--X--X--X--X--o--o topic\n\nAfter getting the branches like this, I would then (try to) rebase\ntopic like this:\n\no--o--O--X'--X'--X'--X' master\n \\\n o'--o'--o'--o' topic\n\nI say try to, because rebase sometimes gets a lot of dumb (to me,\nmaybe I'm not using git correctly) conflicts in cases like this, so I\nend up manually rebasing, by making a new topic branch off master,\ncherry picking into it off the old topic branch, and then removing the\nold branch. Another case where multiple cherry picks would be nice :-)\n\n>\n> Why can't you simply use merge, BTW?\n\nBecause the topic branch has some 'dirty' commits that I don't want in master.\n\nDavid.\n"},{"id":"78600","messageId":"200806041016.26066.johan@herland.net","threadId":"13789","inReplyTo":"18c1e6480806040013l72da09aem30f91183e4fcbe41@mail.gmail.com","subject":"Re: User's mailing list? And multiple cherry pick","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2008-06-04T08:16:25Z","receivedAt":"2008-06-04T08:16:25Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Wednesday 04 June 2008, David wrote:\n> > rebase --onto?\n> \n> Thanks, I checked the manuals further, and it looks like this will\n> (mostly) do what I need.\n> \n> What's still missing is multiple cherry pick ;-)\n> \n> In other words, is there a simple way to *copy* a large number of\n> commits from one branch to another, without rebasing?\n\nDepends on you definition of \"simple\". Here are 5 commands that gets the job done in a (IMHO) conceptually simple way.\n\nUse\n\n\tgit checkout -b [tmpBranch] [fromBranch]\n\nto create (and checkout) a _new_ branch pointing to the same commit as the \"from\"-branch. Then use\n\n\tgit rebase --onto [toBranch] [fromBranchStart] [tmpBranch]\n\nto rebase all commits between [fromBranchStart] and [fromBranch] on top of [toBranch]. Since this was done with HEAD == [tmpBranch], the original [fromBranch] is not moved, and therefore *still* points to the old commits. [tmpBranch], however, have been moved to point at the rebased commits. This in effect *copies* the commits from [fromBranch] to [tmpBranch]. Now, all that remains is to reconcile [tmpBranch] and [toBranch], and finally remove [tmpBranch]:\n\n\tgit checkout [toBranch]\n\tgit merge [tmpBranch]\n\tgit branch -d [tmpBranch]\n\nThe merge should be a simple fast-forward without any conflicts.\n\nHere is an illustrated version of what's going on:\n\nInitial layout:\n\n\t G---H---I <---- [fromBranch]\n\t /\n\tA---B---C---D---E---F <-- [toBranch]\n\t ^----------------- [fromBranchStart]\n\ngit checkout -b [tmpBranch] [fromBranch]\n\n\t G---H---I <---- [fromBranch]\n\t / ^------- [tmpBranch] \n\tA---B---C---D---E---F <-- [toBranch]\n\t ^----------------- [fromBranchStart]\n\ngit rebase --onto [toBranch] [fromBranchStart] [tmpBranch]\n\n\t G---H---I <------------------- [fromBranch]\n\t / \n\tA---B---C---D---E---F---G'---H'---I' <-- [tmpBranch]\n\t ^ ^-------------------- [toBranch]\n\t --------------------------------- [fromBranchStart]\n\ngit checkout [toBranch]\ngit merge [tmpBranch]\ngit branch -d [tmpBranch]\n\n\t G---H---I <------------------- [fromBranch]\n\t / \n\tA---B---C---D---E---F---G'---H'---I' <-- [toBranch]\n\t ^-------------------------------- [fromBranchStart]\n\n\nThis should also work even if your commit graphs are considerably more complicated.\n\nIf you need to drop/edit/squash any commits between [fromBranchStart] and [fromBranch], simply add a \"--interactive\" to the rebase command.\n\n\nHave fun!\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"78601","messageId":"18c1e6480806040120k58aaf16eg88fa318788a2af45@mail.gmail.com","threadId":"13789","inReplyTo":"20080604080017.GB7752@leksak.fem-net","subject":"Re: User's mailing list? And multiple cherry pick","fromName":"David","fromEmail":"wizzardx@gmail.com","sentAt":"2008-06-04T08:20:28Z","receivedAt":"2008-06-04T08:20:28Z","isPatch":false,"sender":{"key":"wizzardx@gmail.com","avatar":"https://gravatar.com/avatar/045483b90f748c2423d8321911ea9034f83f124c3e9ddb25e96011e6d68b20fb?d=mp&s=160"},"body":">> Is there an easier syntax for doing this?\n>\n> Put this into a script and you've got an easier syntax ;-)\n> But note that does not get cherry-picked then.\n> Use ^.. (or $1^..$2).\n\nThanks for the ^ tip. I prefer to use git built-ins where possible,\ninstead of re-inventing the wheel badly by using my own scripts ;-)\n\n> for C in $(git log --reverse .. --pretty=format:%H);\n> do echo pick $C ; done >temporaryfile\n> /where/you/put/it/git-sequencer.sh temporaryfile\n>\n\nThanks for the script, but I want to use git built-ins only if\npossible :-) eg, so that I can easily help other people do the same\nthing without telling them to download separate scripts.\n\nAlso, that syntax is almost as long & complicated-looking as my own ;-)\n"},{"id":"78602","messageId":"200806041023.02632.johan@herland.net","threadId":"13789","inReplyTo":"m3mym1zkus.fsf@localhost.localdomain","subject":"Re: User's mailing list? And multiple cherry pick","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2008-06-04T08:23:02Z","receivedAt":"2008-06-04T08:23:02Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Wednesday 04 June 2008, Jakub Narebski wrote:\n> That said, cherry-picking multiple commits is often requested feature.\n> I guess that git-sequencer GSoC 2008 project would help in having it\n> finally implemented. BTW. why can't you use topic branches and\n> merging?\n\nWhat about adding a \"-b\" option to git-rebase that simply performs a \"git\ncheckout -b\" before starting the rest of the rebase process?\n\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"78603","messageId":"18c1e6480806040130k3851a89an3fcf986feb661226@mail.gmail.com","threadId":"13789","inReplyTo":"m3mym1zkus.fsf@localhost.localdomain","subject":"Re: User's mailing list? And multiple cherry pick","fromName":"David","fromEmail":"wizzardx@gmail.com","sentAt":"2008-06-04T08:30:08Z","receivedAt":"2008-06-04T08:30:08Z","isPatch":false,"sender":{"key":"wizzardx@gmail.com","avatar":"https://gravatar.com/avatar/045483b90f748c2423d8321911ea9034f83f124c3e9ddb25e96011e6d68b20fb?d=mp&s=160"},"body":"On Wed, Jun 4, 2008 at 10:05 AM, Jakub Narebski wrote:\n> David writes:\n>\n> [Please don't remove quote attributions]\n>\n\nThanks for the netiquette tip, I didn't know this was a bad thing. Are\ns also a good thing, or is it ok to just cut out the parts that\ndon't need re-quoting?\n\n\n>\n> # make temporary branch to not move to-be-copied during rebase\n> $ git checkout -b tmp-rebase to-be-copied\n> # copy commits; results are in just created temporary branch\n> $ git rebase --onto branch copy-from tmp-rebase\n> # check if everything is all right and rename temporary branch\n> # to final name\n> $ git branch -M tmp-rebase branch\n>\n\nThanks :-) This still isn't what I had in mind (see my earlier post\nwith examples), but I realise now, thanks to your post, that I can\nprobably do it like this:\n\n1) Make a temporary branch off the topic\n\n2) Rebase the temporary branch onto master interactively (maybe or\nmaybe not with --onto), and in interactive mode take out, reorder,\netc.\n\n3) Check & test the temporary branch\n\n4) Merge the temporary branch into master, and drop the temporary branch.\n\n5) Rebase the original topic branch onto the new master.\n\nThanks to all the posters for their tips.\n\nDavid.\n"},{"id":"78604","messageId":"200806041050.09701.jnareb@gmail.com","threadId":"13789","inReplyTo":"18c1e6480806040111s606701dfwc8a2ae5f742307b5@mail.gmail.com","subject":"Re: User's mailing list? And multiple cherry pick","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-06-04T08:50:08Z","receivedAt":"2008-06-04T08:50:08Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Wed, 4 June 2008, David wrote:\n> \n> Thanks, but this doesn't quite solve the problem. I'm on the verge of\n> figuring it out, and would appreciate any further tips :-)\n> \n> Here is an example:\n> \n> o--o--O master\n> \\\n> o--o--X--X--X--X--o--o topic\n> \n> I want to copy the \"X\" patches from the topic branch over to master.\n> The other patches aren't appropriate for master for whatever reason.\n> eg, temporary debugging hacks, but I fixed a few problems in master in\n> the X patches and now want to apply them on top of master, and keep\n> working on \"topic\"\n> \n> I want to end up with a tree like this:\n> \n> \n> o--o--O--X'--X'--X'--X' master\n> \\\n> o--o--X--X--X--X--o--o topic\n\nI think the simplest solution would be to mark old master, change it\nto topic (merge or branch -f), and use interactive rebase.\n\n $ git checkout master\n $ git branch TMP\n \n o--o--O *master, TMP\n \\\n o--o--X--X--X--X--o--o topic\n\nwhere '*master' means that 'master' is current branch.\n\nThen to rewind 'master' to 'topic' you can use either\n $ git merge topic \nwhich should fast-forward to 'topic', or use git-reset\n $ git reset --hard topic\n\n o--o--O TMP\n \\\n o--o--X--X--X--X--o--o topic, *master\n\nThen there is simply a matter of rebasing master interactively, picking \ncommits marked X.\n\n $ git rebase --interactive TMP\n # pick commits marked X in above diagram, backup (save) both original\n # list of commits, and final list of commits.\n\nIt is now safe to delete 'TMP' branch\n\n $ git branch -d TMP\n\n o--o--O--X'--X'--X'--X' *master\n \\\n o--o--X--X--X--X--o--o topic\n\nNow, if all goes well it would be simply a matter of rebasing 'topic' on \ntop of 'master'; git-rebase would skip commits that are already there.\n\nIf it is not the case, use interactive rebase again, this time picking \ncommits marked 'o' (if you saved original series, and list of commits \nrebased, this should be fairly easy to find/do).\n \n> After getting the branches like this, I would then (try to) rebase\n> topic like this:\n> \n> o--o--O--X'--X'--X'--X' master\n> \\\n> o'--o'--o'--o' topic\n\nAnd here you are.\n\nHTH\n-- \nJakub Narebski\nPoland\n"},{"id":"78606","messageId":"18c1e6480806040237m1f85c3f2s98ddb35ee1598ab2@mail.gmail.com","threadId":"13789","inReplyTo":"200806041050.09701.jnareb@gmail.com","subject":"Re: User's mailing list? And multiple cherry pick","fromName":"David","fromEmail":"wizzardx@gmail.com","sentAt":"2008-06-04T09:37:01Z","receivedAt":"2008-06-04T09:37:01Z","isPatch":false,"sender":{"key":"wizzardx@gmail.com","avatar":"https://gravatar.com/avatar/045483b90f748c2423d8321911ea9034f83f124c3e9ddb25e96011e6d68b20fb?d=mp&s=160"},"body":"On Wed, Jun 4, 2008 at 10:50 AM, Jakub Narebski wrote:\n> On Wed, 4 June 2008, David wrote:\n>>\n>> Thanks, but this doesn't quite solve the problem. I'm on the verge of\n>> figuring it out, and would appreciate any further tips :-)\n>>\n\n[snip]\n\n> I think the simplest solution would be to mark old master, change it\n> to topic (merge or branch -f), and use interactive rebase.\n>\n\nThanks for the idea, but doesn't this make your 'master' branch very volatile?\n\nMy understanding is that it's better to keep master as stable & \"main\nline\" as possible, and only merge into it when the bits being merged\nare relatively safe.\n\nIn your example, you still have a TMP \"rollback\" point if you need to\nrewind master in the event that the merge into master goes badly.\n\nMaybe jumping master around like that works better when you're more\nexperienced with git and can fix problems with master quickly.\n\nIn my case I make rsync backups of my git repos before I do anything\nthat looks remotely dangerous ;-)\n\nDavid.\n"},{"id":"78607","messageId":"D11EAC1A-B59E-4857-A31F-809809310E40@wincent.com","threadId":"13789","inReplyTo":"18c1e6480806040130k3851a89an3fcf986feb661226@mail.gmail.com","subject":"Re: User's mailing list? And multiple cherry pick","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2008-06-04T09:39:08Z","receivedAt":"2008-06-04T09:39:08Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 4/6/2008, a las 10:30, David escribió:\n\n> Thanks :-) This still isn't what I had in mind (see my earlier post\n> with examples), but I realise now, thanks to your post, that I can\n> probably do it like this:\n>\n> 1) Make a temporary branch off the topic\n>\n> 2) Rebase the temporary branch onto master interactively (maybe or\n> maybe not with --onto), and in interactive mode take out, reorder,\n> etc.\n>\n> 3) Check & test the temporary branch\n>\n> 4) Merge the temporary branch into master, and drop the temporary \n> branch.\n>\n> 5) Rebase the original topic branch onto the new master.\n>\n> Thanks to all the posters for their tips.\n\nSounds like it would definitely work but it also sounds like a lot of \nrepetitive \"busy work\"[1] which could be avoided by using finer- \ngrained topic branches in the first place.\n\nIn the basic case Git makes it incredibly easy to split off topic \nbranches and merge them back in, and when you do this you're working \nin synergy with the tool. But while what you're wanting to do is \ncertainly possible you can also see that it has a lot of fiddly, error- \nprone overhead in which you're juggling temporary branches and commits \nback and forth in a complicated way. Not working in synergy with the \ntool.\n\nI know that I'd soon get tied of this \"busy work\" if I had to do it; \nmaybe with time you'll be able to transition to a style in which you \nmake more, smaller topic branches, which can really be treated as \nlogically-grouped topics and merged in as a whole rather than sifted \nout into separate sub-topics.\n\nHaving said that, the ability to pass multiple commits or ranges of \ncommits to \"git cherry-pick\" is a logical enough enhancement, if \nsomeone is interested enough in this feature to actually do the work.\n\nWincent\n\n[1] http://en.wikipedia.org/wiki/Busy_work\n"},{"id":"78608","messageId":"200806041147.53523.jnareb@gmail.com","threadId":"13789","inReplyTo":"18c1e6480806040237m1f85c3f2s98ddb35ee1598ab2@mail.gmail.com","subject":"Re: User's mailing list? And multiple cherry pick","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-06-04T09:47:52Z","receivedAt":"2008-06-04T09:47:52Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"David wrote:\n\n[...]\n> In your example, you still have a TMP \"rollback\" point if you need to\n> rewind master in the event that the merge into master goes badly.\n\nAnd you have ORIG_HEAD and reflog (master@{1}, master@{2} etc.) as \nsafety net. Reflog is now enabled by default.\n\nBesides unless you run prune in the meantime, even without reflogs you \nwould be able to recover using lost-found / git-fsck output.\n-- \nJakub Narebski\nPoland\n"},{"id":"78609","messageId":"18c1e6480806040302k74156d47p4e878fef62d21b87@mail.gmail.com","threadId":"13789","inReplyTo":"D11EAC1A-B59E-4857-A31F-809809310E40@wincent.com","subject":"Re: User's mailing list? And multiple cherry pick","fromName":"David","fromEmail":"wizzardx@gmail.com","sentAt":"2008-06-04T10:02:13Z","receivedAt":"2008-06-04T10:02:13Z","isPatch":false,"sender":{"key":"wizzardx@gmail.com","avatar":"https://gravatar.com/avatar/045483b90f748c2423d8321911ea9034f83f124c3e9ddb25e96011e6d68b20fb?d=mp&s=160"},"body":"On Wed, Jun 4, 2008 at 11:39 AM, Wincent Colaiuta wrote:\n> El 4/6/2008, a las 10:30, David escribió:\n>\n>> Thanks :-) This still isn't what I had in mind (see my earlier post\n>> with examples), but I realise now, thanks to your post, that I can\n>> probably do it like this:\n\n[snip]\n\n>\n> Sounds like it would definitely work but it also sounds like a lot of\n> repetitive \"busy work\"[1] which could be avoided by using finer-grained\n> topic branches in the first place.\n>\n\nI see where you're coming from, and I am learning to work more in this\nway. Using git has made a big difference to how I develop. Not just as\na SCM, but also for improved work-flow. eg trying out things in code,\nand storing failed attempts for later reference/retries/etc if it\ndoesn't work out.\n\nMy problem with your post is, even if you take this to the extreme\n(topic branches for every fix that you want to make), there will still\nbe cases where while working on one fix (maybe disruptive to the main\nbranch), you uncover problems with master and start fixing it in your\ntopic branch.\n\nIt isn't always easy to fix the problems in master (that you're seeing\nin topic) by changing back to master and making another topic. Maybe\nyou can only (easily) find & detect the problems in master because of\nother changes in topic (eg: WIP unit tests) that you aren't ready to\nmerge yet.\n\nSo you would probably have to jump back and forth between your topic,\nand your new 'fix problems in master' branch a lot to track down the\nissues and get the fixes into master. This sounds like a lot more\n'busy work' than simply cherry-picking (multiple) those fixes out of\nyour topic branch into master, and then rebasing your topic branch :-)\n\nDavid.\n"},{"id":"78611","messageId":"20080604103848.GB2126@diana.vm.bytemark.co.uk","threadId":"13789","inReplyTo":"m3r6bdzm22.fsf@localhost.localdomain","subject":"Re: User's mailing list? And multiple cherry pick","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2008-06-04T10:38:48Z","receivedAt":"2008-06-04T10:38:48Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2008-06-04 00:39:07 -0700, Jakub Narebski wrote:\n\n> There is Git User's mailing list (\"Git for human beings\", heh)\n> git-users@googlegroups.com\n> http://groups.google.com/group/git-users\n> nntp://news.gmane.org/gmane.comp.version-control.git.user\n\nIs there a way to subscribe to a Google list such as this one and have\nthe list mails delivered to a non-gmail address? I'd like to be able\nto follow this list and the msysgit list, but not if I have to use\ngmail to do it.\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"78612","messageId":"72AA7E07-AFE5-40B5-822D-6E7F404B8FC6@wincent.com","threadId":"13789","inReplyTo":"18c1e6480806040302k74156d47p4e878fef62d21b87@mail.gmail.com","subject":"Re: User's mailing list? And multiple cherry pick","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2008-06-04T11:02:00Z","receivedAt":"2008-06-04T11:02:00Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 4/6/2008, a las 12:02, David escribió:\n\n> On Wed, Jun 4, 2008 at 11:39 AM, Wincent Colaiuta \n> wrote:\n>> El 4/6/2008, a las 10:30, David escribió:\n>>\n>>> Thanks :-) This still isn't what I had in mind (see my earlier post\n>>> with examples), but I realise now, thanks to your post, that I can\n>>> probably do it like this:\n>\n> [snip]\n>\n>>\n>> Sounds like it would definitely work but it also sounds like a lot of\n>> repetitive \"busy work\"[1] which could be avoided by using finer- \n>> grained\n>> topic branches in the first place.\n>>\n>\n> I see where you're coming from, and I am learning to work more in this\n> way. Using git has made a big difference to how I develop. Not just as\n> a SCM, but also for improved work-flow. eg trying out things in code,\n> and storing failed attempts for later reference/retries/etc if it\n> doesn't work out.\n>\n> My problem with your post is, even if you take this to the extreme\n> (topic branches for every fix that you want to make), there will still\n> be cases where while working on one fix (maybe disruptive to the main\n> branch), you uncover problems with master and start fixing it in your\n> topic branch.\n>\n> It isn't always easy to fix the problems in master (that you're seeing\n> in topic) by changing back to master and making another topic. Maybe\n> you can only (easily) find & detect the problems in master because of\n> other changes in topic (eg: WIP unit tests) that you aren't ready to\n> merge yet.\n>\n> So you would probably have to jump back and forth between your topic,\n> and your new 'fix problems in master' branch a lot to track down the\n> issues and get the fixes into master. This sounds like a lot more\n> 'busy work' than simply cherry-picking (multiple) those fixes out of\n> your topic branch into master, and then rebasing your topic branch :-)\n\nI guess it depends on how long-lived your topic branches are, and how \nurgently you want to get independent fixes back into \"master\".\n\nIf the topic branch isn't very long-lived, and the fix isn't \nincredibly urgent, you could just keep it in the topic until the \nentire topic branch is ready to be merged back in.\n\nIf the fix depends on changes in the topic branch then getting it into \nmaster may not be so urgent anyway. How often does this really happen? \nI know that all code bases are different, but in my experience if I \ndiscover a problem (in master) while working on a topic, the fix is \nusually independent of the topic, in which case I have two options: \neither fix it on master (and then optionally rebase the topic), or \njust fix it on the topic and let the fix propagate back to the master \nwhen I merge in the topic.\n\nDon't forget that you also have \"git stash\" for those moments when you \nare working on a topic and see a completely unrelated fix or change \nthat you want to do.\n\nBut obviously, this is all highly context-dependent and what works for \nme won't always work for everyone.\n\nWincent\n"},{"id":"78613","messageId":"m3iqwpzccs.fsf@localhost.localdomain","threadId":"13789","inReplyTo":"18c1e6480806040302k74156d47p4e878fef62d21b87@mail.gmail.com","subject":"Re: User's mailing list? And multiple cherry pick","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-06-04T11:09:18Z","receivedAt":"2008-06-04T11:09:18Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"David writes:\n\n> On Wed, Jun 4, 2008 at 11:39 AM, Wincent Colaiuta wrote:\n> >\n> > Sounds like it would definitely work but it also sounds like a lot of\n> > repetitive \"busy work\"[1] which could be avoided by using finer-grained\n> > topic branches in the first place.\n> >\n> \n> I see where you're coming from, and I am learning to work more in this\n> way. Using git has made a big difference to how I develop. Not just as\n> a SCM, but also for improved work-flow. eg trying out things in code,\n> and storing failed attempts for later reference/retries/etc if it\n> doesn't work out.\n> \n> My problem with your post is, even if you take this to the extreme\n> (topic branches for every fix that you want to make), there will still\n> be cases where while working on one fix (maybe disruptive to the main\n> branch), you uncover problems with master and start fixing it in your\n> topic branch.\n> \n> It isn't always easy to fix the problems in master (that you're seeing\n> in topic) by changing back to master and making another topic. Maybe\n> you can only (easily) find & detect the problems in master because of\n> other changes in topic (eg: WIP unit tests) that you aren't ready to\n> merge yet.\n> \n> So you would probably have to jump back and forth between your topic,\n> and your new 'fix problems in master' branch a lot to track down the\n> issues and get the fixes into master. This sounds like a lot more\n> 'busy work' than simply cherry-picking (multiple) those fixes out of\n> your topic branch into master, and then rebasing your topic branch :-)\n\nFor this I think it would be best to use some kind of patch management\ninterface on top of Git, be it StGIT or Guilt (interface of the latter\nis based on Mercurial Queues, hence former name Git Queues (gq)), see\nhttp://git.or.cz/gitwiki/InterfacesFrontendsAndTools (there was also\nPatchy Git (pg) tool, but it is no longer maintained). I personally\nuse StGIT, therefore all examples will use this tool.\n\nThen you would be able to go back and forth between patches (commits),\ncorrect them, with some difficulty even split or join them.\n\nNow the workflow depends if you are third-party contributor, sending\npatches upstream via email, or if you are project maintainer, and\nothers pull from you.\n\nIf you are third-party contributor, sending patches upstream via\nemail,using \"stg mail\" or \"git format-patch\" plus either \"git\nsend-email\", or your favorite mail program, you would do the\nfollowing, on your topic branch:\n 1. edit, going back and forth between patches\n 2. \"stg mail\" patches to maintainer\n 3. incorporate feedback, going to 1. if necessary\n 4. fetch from upstream (I use \"git fetch\"/\"git remote update\")\n 5. rebase your patches (\"stg rebase \")\n 6. remove applied patches (which should be empty) from stack,\n using \"stg clean -a\"; remove patches by hand if necessary\n (\"stg remove \").\n\nIf you are maintainer / main contributor your workflow would be a bit\ndifferent. Instead of emailing patches you would probably \"stg\ncommit\" them, turning them into ordinary commits (removing from patch\nqueue) when you finish working on them, then probably merge (parts of)\nfeature branch into one of stable branches ('maint', 'master',\n'next',...).\n\nHTH.\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"78614","messageId":"20080604111036.GV29404@genesis.frugalware.org","threadId":"13789","inReplyTo":"20080604103848.GB2126@diana.vm.bytemark.co.uk","subject":"Re: User's mailing list? And multiple cherry pick","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2008-06-04T11:10:36Z","receivedAt":"2008-06-04T11:10:36Z","isPatch":false,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"On Wed, Jun 04, 2008 at 12:38:48PM +0200, Karl Hasselström wrote:\n> On 2008-06-04 00:39:07 -0700, Jakub Narebski wrote:\n> \n> > There is Git User's mailing list (\"Git for human beings\", heh)\n> > git-users@googlegroups.com\n> > http://groups.google.com/group/git-users\n> > nntp://news.gmane.org/gmane.comp.version-control.git.user\n> \n> Is there a way to subscribe to a Google list such as this one and have\n> the list mails delivered to a non-gmail address? I'd like to be able\n> to follow this list and the msysgit list, but not if I have to use\n> gmail to do it.\n\nYes. You need a google account for your non-gmail address, though.\n"},{"id":"78616","messageId":"20080604113620.GB7094@mit.edu","threadId":"13789","inReplyTo":"18c1e6480806040111s606701dfwc8a2ae5f742307b5@mail.gmail.com","subject":"Re: User's mailing list? And multiple cherry pick","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2008-06-04T11:36:20Z","receivedAt":"2008-06-04T11:36:20Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Wed, Jun 04, 2008 at 10:11:33AM +0200, David wrote:\n> Here is an example:\n> \n> o--o--O master\n> \\\n> o--o--X--X--X--X--o--o topic\n> \n> I want to copy the \"X\" patches from the topic branch over to master.\n> The other patches aren't appropriate for master for whatever reason.\n> eg, temporary debugging hacks, but I fixed a few problems in master in\n> the X patches and now want to apply them on top of master, and keep\n> working on \"topic\"\n> \n> I want to end up with a tree like this:\n> \n> \n> o--o--O--X'--X'--X'--X' master\n> \\\n> o--o--X--X--X--X--o--o topic\n>\n> After getting the branches like this, I would then (try to) rebase\n> topic like this:\n> \n> o--o--O--X'--X'--X'--X' master\n> \\\n> o'--o'--o'--o' topic\n> \n\n\nOK, so assume the tree looks like this:\n\n o--o--O master\n \\\n 1--2--3--4--5--6--7--8 topic\n\nFirst do a \"git checkout topic; git rebase --interactive master\", and\nreorder the topic branch so it looks like this:\n\n o--o--O master\n \\\n 3--4--5--6--1--2--7--8 topic\n\nNow find the commit ID for commit #6 above, and assuming that it's\nf1dead2f, run the command \"git checkout master; git merge f1dead2f\".\nNow the graph looks like this:\n\n o--o--O--3--4--5--6 master\n \\\n 1--2--7--8 topic\n\nYou could also use the command:\n\n\t\"git update-ref refs/heads/master f1dead2f\"\n\nwhich keeps HEAD pointing at the topic branch, but the reason why I\nsuggested the \"git checkout master; git merge f1dead2f\" is that the\ncommands are generally more familiar to git newcomers, and I usually\nwant to do a test build and run the regression tests on master to make\nsure things are clean.\n\n\n> I say try to, because rebase sometimes gets a lot of dumb (to me,\n> maybe I'm not using git correctly) conflicts in cases like this, so I\n> end up manually rebasing, by making a new topic branch off master,\n> cherry picking into it off the old topic branch, and then removing the\n> old branch. Another case where multiple cherry picks would be nice :-)\n\nNote that in the above set of commands, summarized as:\n\n1) \"git checkout topic; git rebase --interactive master\"\n 1a) \"make; make check\" to build and run regression tests on the \n \treordered topic branch.\n2) \"git checkout master; git merge f1dead2f\" (this should be a fast forward)\n 2a) \"make; make check\" to build and run regression tests on the \n \tupdated master branch.\n\nThere may be indeed conflicts at the first \"git rebase --interactive\",\nbut that's just git being conservative. Usually it really isnt that\nhard to resolve the conflicts, git add the files which required\nfixups, and then doing a \"git rebase --continue\". And you will have\nto do the manual fixup regardless of whether you use \"git rebase\" or\n\"git cherry-pick\"; the git rebase is just a more automated way of\ndoing things.\n\nRegards,\n\n\t\t\t\t\t\t- Ted\n"},{"id":"78646","messageId":"20080604180931.GA31188@atjola.homenet","threadId":"13789","inReplyTo":"18c1e6480806040302k74156d47p4e878fef62d21b87@mail.gmail.com","subject":"Re: User's mailing list? And multiple cherry pick","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2008-06-04T18:09:31Z","receivedAt":"2008-06-04T18:09:31Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2008.06.04 12:02:13 +0200, David wrote:\n> On Wed, Jun 4, 2008 at 11:39 AM, Wincent Colaiuta wrote:\n> > El 4/6/2008, a las 10:30, David escribió:\n> >\n> >> Thanks :-) This still isn't what I had in mind (see my earlier post\n> >> with examples), but I realise now, thanks to your post, that I can\n> >> probably do it like this:\n> \n> [snip]\n> \n> >\n> > Sounds like it would definitely work but it also sounds like a lot of\n> > repetitive \"busy work\"[1] which could be avoided by using finer-grained\n> > topic branches in the first place.\n> >\n> \n> It isn't always easy to fix the problems in master (that you're seeing\n> in topic) by changing back to master and making another topic. Maybe\n> you can only (easily) find & detect the problems in master because of\n> other changes in topic (eg: WIP unit tests) that you aren't ready to\n> merge yet.\n> \n> So you would probably have to jump back and forth between your topic,\n> and your new 'fix problems in master' branch a lot to track down the\n> issues and get the fixes into master. This sounds like a lot more\n> 'busy work' than simply cherry-picking (multiple) those fixes out of\n> your topic branch into master, and then rebasing your topic branch :-)\n\nThe unit tests example is a pretty good use-case for rebase --onto.\nSimply start your new topic on top of the WIP topic, you don't always\nhave to branch from master. Then you have the all the code around. Fix\nthe bug, and finally rebase your new topic onto master.\n\ngit checkout -b bug_fix_branch wip_branch\n# work work work, commit commit commit\ngit rebase --onto master wip_branch bug_fix_branch\n\nEventually, you'll have to add stuff to your wip_branch while doing the\nbug_fix, but that's relatively straight forward.\n\ngit checkout wip_branch\n# work work work, commit commit commit\ngit rebase wip_branch bug_fix_branch\n\nAnd then you can continue to work on the bug fix branch and at some\npoint end up at the rebase --onto from above.\n\nOf course for stronger dependencies between wip_branch and\nbug_fix_branch, that's not possible, but then you most likely wouldn't\nwant to cherry-pick the bug fix stuff into master anyway.\n\nBjörn\n"}]}