{"thread":{"id":"26500","subject":"configuring cherry-pick to always use -x?","startedAt":"2011-02-14T17:19:49Z","lastAt":"2011-02-15T21:03:43Z","messageCount":12,"participants":["Adam Monsen","Jay Soffian","Junio C Hamano","Michael J Gruber","Jonathan Nieder","Ivan Kanis"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"161073","messageId":"4D596435.9020605@gmail.com","threadId":"26500","inReplyTo":null,"subject":"configuring cherry-pick to always use -x?","fromName":"Adam Monsen","fromEmail":"haircut@gmail.com","sentAt":"2011-02-14T17:19:49Z","receivedAt":"2011-02-14T17:19:49Z","isPatch":false,"sender":{"key":"haircut@gmail.com","avatar":"https://avatars.githubusercontent.com/u/50639?v=4"},"body":"Is there a configuration option to make cherry-pick always include the\nsource commit hash in the new commit log message?\n\ne.g., make \"git cherry-pick\" always behave like \"git cherry-pick -x\"?\n\nMy most frequent use case for cherry picking is between publicly visible\nbranches.\n\nI have the following configuration option set:\n\n alias.cpx=cherry-pick -x\n\nbut I rarely remember to use it.\n"},{"id":"161080","messageId":"AANLkTin0xB=hJ-v21+esT6Zqj2f53XiwD8tBW4qFkuVy@mail.gmail.com","threadId":"26500","inReplyTo":"4D596435.9020605@gmail.com","subject":"Re: configuring cherry-pick to always use -x?","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2011-02-14T18:09:32Z","receivedAt":"2011-02-14T18:09:32Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Mon, Feb 14, 2011 at 12:19 PM, Adam Monsen wrote:\n> Is there a configuration option to make cherry-pick always include the\n> source commit hash in the new commit log message?\n>\n> e.g., make \"git cherry-pick\" always behave like \"git cherry-pick -x\"?\n\nNope, but one would be appreciated. :-)\n\n> My most frequent use case for cherry picking is between publicly visible\n> branches.\n>\n> I have the following configuration option set:\n>\n>  alias.cpx=cherry-pick -x\n>\n> but I rarely remember to use it.\n\nIt's worse than that. I like to keep the message generated after a\ncherry-pick conflict, but the original commit authorship. I have this,\nwhich I call recommit:\n\n\n#!/bin/sh\n# Used after a cherry-pick conflicts to commit with the original\n# authorship (commit -c) but keep the newly generated commit message\n#\nself=$(cd \"$(dirname \"$0\")\" && pwd -P)/$(basename \"$0\")\n. \"$(git --exec-path)/git-sh-setup\"\nrequire_work_tree\ncd_to_toplevel\ntest -f .git/MERGE_MSG || die \"No .git/MERGE_MSG\"\n\nif test \"$GIT_EDITOR\" = \"$self\"\nthen\n cat .git/MERGE_MSG > .GIT/COMMIT_EDITMSG\n exit 0\nfi\n\nif sha1=$(sed -ne \\\n 's/^(cherry picked from commit \\([a-f0-9]\\{40\\}\\))$/\\1/p' .git/MERGE_MSG)\nthen\n export GIT_EDITOR=\"$self\"\n git commit -c $sha1\nfi\n\n\nI've had it on my TODO list for a while now to:\n\n1. add a config option to enable -x by default\n\n2. improve the cherry-pick conflict UX. I was thinking of out\nCHERRY_HEAD on conflict and then adding a cherry-pick --continue\noption which acts like rebase --continue. CHERRY_HEAD is what was\nbeing picked at the time of conflict and can be used by the bash\ncompletion script for proper prompting, as well as obviously the\n--continue option.\n\nj.\n"},{"id":"161103","messageId":"AANLkTimi=d0qbO3_-BEnPEJ+iy9B=_fksF7TiBE7HorC@mail.gmail.com","threadId":"26500","inReplyTo":"4D596435.9020605@gmail.com","subject":"Re: configuring cherry-pick to always use -x?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-14T21:05:06Z","receivedAt":"2011-02-14T21:05:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"On Mon, Feb 14, 2011 at 9:19 AM, Adam Monsen wrote:\n> Is there a configuration option to make cherry-pick always include the\n> source commit hash in the new commit log message?\n\nNot currently, but before we go any further, could you please justify\nin what workflow it would make sense to use -x most of the time?\n\nWe used to add the \"cherry-picked from\" by default in the very early\ndays, and stopped doing so for a reason, and also deliberately stayed\naway from adding such a configuration to actively discourage the use\nof -x without making the user thinking twice.\n"},{"id":"161107","messageId":"AANLkTinpY2B0g-U4No-8rV7TFV5-z=x7AAGqgHNR7Wrt@mail.gmail.com","threadId":"26500","inReplyTo":"AANLkTin0xB=hJ-v21+esT6Zqj2f53XiwD8tBW4qFkuVy@mail.gmail.com","subject":"Re: configuring cherry-pick to always use -x?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-14T21:23:11Z","receivedAt":"2011-02-14T21:23:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"On Mon, Feb 14, 2011 at 10:09 AM, Jay Soffian wrote:\n> I've had it on my TODO list for a while now to:\n> ...\n> 2. improve the cherry-pick conflict UX. I was thinking of out\n> CHERRY_HEAD on conflict and then adding a cherry-pick --continue\n> option which acts like rebase --continue. CHERRY_HEAD is what was\n> being picked at the time of conflict and can be used by the bash\n> completion script for proper prompting, as well as obviously the\n> --continue option.\n\nYes, we have so far only \"use commit -c $that_one\", which is an\nobvious and low hanging fruit for improvement.\nThanks.\n"},{"id":"161112","messageId":"4D59A39C.9090402@gmail.com","threadId":"26500","inReplyTo":"AANLkTimi=d0qbO3_-BEnPEJ+iy9B=_fksF7TiBE7HorC@mail.gmail.com","subject":"Re: configuring cherry-pick to always use -x?","fromName":"Adam Monsen","fromEmail":"haircut@gmail.com","sentAt":"2011-02-14T21:50:20Z","receivedAt":"2011-02-14T21:50:20Z","isPatch":false,"sender":{"key":"haircut@gmail.com","avatar":"https://avatars.githubusercontent.com/u/50639?v=4"},"body":"Junio C Hamano wrote:\n> could you please justify in what workflow it would make sense to use\n> -x most of the time?\n\nSure. Summary: two long-lived publicly visible branches.\n\nDetails:\nMifos is what I'm usually working on lately. We have branches \"master\"\nand \"f-release\" both present in our public git repository called \"head\"\n(hosted at sf.net). master is the bleeding edge of development,\nf-release is a release maintenance branch recently created off the tip\nof master. I expect both to live on forever (even though commits to\nf-release will eventually cease).\n\nRight after f-release was cut, we merged f-release to master every day\nor so to make sure bugfixes for f-release were also propagated to future\nreleases. After a while, merging resulted in too many conflicts and we\nstarted cherry picking instead.\n\nThis process is described generally at\nhttp://mifosforge.jira.com/wiki/display/MIFOS/Release+Branch+Merging+Policy\n.\n\nIf the source commit is present in the log message of the new (cherry\npicked) commit, it's easy to (1) find the source commit (gitweb creates\na hyperlink, for instance) and (2) know that, when viewing the log of\nmaster, a particular commit is also present on another branch. Right now\nI just keep reminding folks to use -x.\n\nFor (2), I generally assume that branch is a release branch, but come to\nthink of it, it would be nice to know what branch a commit was cherry\npicked from. For example: \"(cherry picked from BRANCHNAME commit\nc6e08938e352f3ec99a29a67dd192945d2bcf00d)\" would be better than the\ncurrent message generated by -x.\n\nSee also:\nhttp://mifosforge.jira.com/wiki/display/MIFOS/Mifos+Version+Control+Guide\n\n"},{"id":"161113","messageId":"AANLkTikKXLBf2HYk2CZmVMzgVhYUAL=URFTZ851eb5do@mail.gmail.com","threadId":"26500","inReplyTo":"AANLkTimi=d0qbO3_-BEnPEJ+iy9B=_fksF7TiBE7HorC@mail.gmail.com","subject":"Re: configuring cherry-pick to always use -x?","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2011-02-14T21:53:30Z","receivedAt":"2011-02-14T21:53:30Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Mon, Feb 14, 2011 at 4:05 PM, Junio C Hamano wrote:\n> Not currently, but before we go any further, could you please justify\n> in what workflow it would make sense to use -x most of the time?\n\nIn one of my repos, most of the time my cherry-picks are between two\npublic branches. Perhaps a better enhancement would be something like:\n\n branch..annotate_cherry_pick = {true, false}\n\nwhich could be set to true for source branches that you wish to\ndefault to -x. Or, maybe it makes sense in cases where the source\nbranch is a remote-tracking branch:\n\n cherry_pick.annotate = {local, remote}\n\nI'm not sure how good a remote-tracking branch is as an indicator of\n'public branch', though, so I think explicitly configuring it\nper-branch makes more sense. I hesitate there only because we don't\ncurrently put remote-tracking branches in the branch section names.\n\nj.\n"},{"id":"161165","messageId":"4D5A401B.1050103@drmicha.warpmail.net","threadId":"26500","inReplyTo":"4D59A39C.9090402@gmail.com","subject":"Re: configuring cherry-pick to always use -x?","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-02-15T08:58:03Z","receivedAt":"2011-02-15T08:58:03Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Adam Monsen venit, vidit, dixit 14.02.2011 22:50:\n> Junio C Hamano wrote:\n>> could you please justify in what workflow it would make sense to use\n>> -x most of the time?\n> \n> Sure. Summary: two long-lived publicly visible branches.\n> \n> Details:\n> Mifos is what I'm usually working on lately. We have branches \"master\"\n> and \"f-release\" both present in our public git repository called \"head\"\n> (hosted at sf.net). master is the bleeding edge of development,\n> f-release is a release maintenance branch recently created off the tip\n> of master. I expect both to live on forever (even though commits to\n> f-release will eventually cease).\n> \n> Right after f-release was cut, we merged f-release to master every day\n> or so to make sure bugfixes for f-release were also propagated to future\n> releases. After a while, merging resulted in too many conflicts and we\n> started cherry picking instead.\n> \n> This process is described generally at\n> http://mifosforge.jira.com/wiki/display/MIFOS/Release+Branch+Merging+Policy\n\nI don't quite understand how cherry picks could conflict less then\nmerges if the release branch contains fixes only. Also, I don't think\nthe advice to use \"merge+revert\" is a good one. All of this indicates a\nsuboptimal use of branches. My impression is that \"f-release\" actually\nmixes release engineering and maintenance. Two possible remedies:\n\n- Separate release engineering from maintenance and merge only the\nlatter to master\n\n- If you do want them on the same branch \"f-release\", you probably know\nbeforehand which commits you don't want on master. You can fake-merge\nthese (\"merge -Xours\") to master and merge the others, which is somewhat\nugly but still better than cherry-picking everything. In some sense this\nis \"manual rerere\" whose results are shared (pushed) easily.(*)\n\nMichael\n\n(*) If that is cryptic, I mean something like:\n\ngit checkout master\ngit merge f-release\n#be happy if it succeeds, identify problematic commit X if not; decide\nwhether X belongs on master; if yes resolve, if not reset and:\ngit merge X^\ngit merge -Xours X\n#back to start\n"},{"id":"161167","messageId":"20110215091828.GA22661@elie","threadId":"26500","inReplyTo":"4D5A401B.1050103@drmicha.warpmail.net","subject":"Re: configuring cherry-pick to always use -x?","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-02-15T09:18:28Z","receivedAt":"2011-02-15T09:18:28Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Michael J Gruber wrote:\n\n> - If you do want them on the same branch \"f-release\", you probably know\n> beforehand which commits you don't want on master. You can fake-merge\n> these (\"merge -Xours\") to master and merge the others\n\nFor the record, I think that should be -sours.\n\nI think it's just a typo but the difference is big --- -sours means\n\"supersede by pretending to merge but actually keeping our version\",\nwhile -Xours means \"do a normal merge but be sloppy and favor our\nchange when encountering adjacent or overlapping changes\".\n\nI suppose -Xours should have been named -Xfavor-ours,\n-Xsloppy-favoring-ours, or something similarly explicit.\n\n> git checkout master\n> git merge f-release\n> #be happy if it succeeds, identify problematic commit X if not; decide\n> whether X belongs on master; if yes resolve, if not reset and:\n> git merge X^\n> git merge -Xours X\n> #back to start\n\nThanks for a nice example.\nJonathan\n"},{"id":"161168","messageId":"4D5A4761.6010308@drmicha.warpmail.net","threadId":"26500","inReplyTo":"20110215091828.GA22661@elie","subject":"Re: configuring cherry-pick to always use -x?","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-02-15T09:29:05Z","receivedAt":"2011-02-15T09:29:05Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Jonathan Nieder venit, vidit, dixit 15.02.2011 10:18:\n> Michael J Gruber wrote:\n> \n>> - If you do want them on the same branch \"f-release\", you probably know\n>> beforehand which commits you don't want on master. You can fake-merge\n>> these (\"merge -Xours\") to master and merge the others\n> \n> For the record, I think that should be -sours.\n> \n> I think it's just a typo but the difference is big --- -sours means\n> \"supersede by pretending to merge but actually keeping our version\",\n> while -Xours means \"do a normal merge but be sloppy and favor our\n> change when encountering adjacent or overlapping changes\".\n\nYes, sorry and thanks.\n\n-Xours may still be useful to know for the OP, but for the complete\nfake-merge you need -sours. In fact, \"-sours\" has an awfully good\nmnemonic when used for fake-merging commits which you do not want to\ncherry-pick :)\n\nMichael\n"},{"id":"161169","messageId":"87vd0lwscm.fsf@kanis.fr","threadId":"26500","inReplyTo":"AANLkTimi=d0qbO3_-BEnPEJ+iy9B=_fksF7TiBE7HorC@mail.gmail.com","subject":"Re: configuring cherry-pick to always use -x?","fromName":"Ivan Kanis","fromEmail":"expire-by-2011-02-20@kanis.fr","sentAt":"2011-02-15T09:38:01Z","receivedAt":"2011-02-15T09:38:01Z","isPatch":false,"sender":{"key":"expire-by-2011-02-20@kanis.fr","avatar":null},"body":"Hi Junio,\n\nJunio C Hamano wrote:\n\n> On Mon, Feb 14, 2011 at 9:19 AM, Adam Monsen wrote:\n>> Is there a configuration option to make cherry-pick always include the\n>> source commit hash in the new commit log message?\n>\n> Not currently, but before we go any further, could you please justify\n> in what workflow it would make sense to use -x most of the time?\n>\n> We used to add the \"cherry-picked from\" by default in the very early\n> days, and stopped doing so for a reason, and also deliberately stayed\n> away from adding such a configuration to actively discourage the use\n> of -x without making the user thinking twice.\n\nCould you elaborate on the reason why -x is a bad idea?\n\nKind regards,\n-- \nIvan Kanis, Release Manager, Vision Objects,\nTel +33 2 28 01 84 44, Fax +33 2 40 25 89 20\nhttp://www.visionobjects.com\n\nWe meet no Stranger, but Ourself.\n -- Emily Dickinson \n"},{"id":"161192","messageId":"AANLkTinMBBKwtkQKgyqaN+oH4-k1Ks_6SbnU7thzuuYs@mail.gmail.com","threadId":"26500","inReplyTo":"4D5A401B.1050103@drmicha.warpmail.net","subject":"Re: configuring cherry-pick to always use -x?","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2011-02-15T16:16:03Z","receivedAt":"2011-02-15T16:16:03Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Tue, Feb 15, 2011 at 3:58 AM, Michael J Gruber\n wrote:\n> - If you do want them on the same branch \"f-release\", you probably know\n> beforehand which commits you don't want on master. You can fake-merge\n> these (\"merge -Xours\") to master and merge the others, which is somewhat\n> ugly but still better than cherry-picking everything. In some sense this\n> is \"manual rerere\" whose results are shared (pushed) easily.(*)\n\nI personally prefer cherry-pick, as the fake merge clutters mainline's\nhistory with the superseded commits.\n\nIt would be interesting to have a history simplification that given a\nmerge M of parents A and B, ignored commits $(merge-base A B)..B where\nM is TREESAME to A. Hmm, that's effectively \"git rev-list .\" isn't it?\n\nj.\n"},{"id":"161212","messageId":"4D5AEA2F.9000606@gmail.com","threadId":"26500","inReplyTo":"4D5A401B.1050103@drmicha.warpmail.net","subject":"release maintenance vs. release engineering (was: configuring cherry-pick to always use -x?)","fromName":"Adam Monsen","fromEmail":"haircut@gmail.com","sentAt":"2011-02-15T21:03:43Z","receivedAt":"2011-02-15T21:03:43Z","isPatch":false,"sender":{"key":"haircut@gmail.com","avatar":"https://avatars.githubusercontent.com/u/50639?v=4"},"body":"Michael J Gruber wrote:\n> I don't quite understand how cherry picks could conflict less then\n> merges if the release branch contains fixes only.\n\nThe last time I experienced a painful merge from f-release to master, it\nwas because some files had been culled from master but left extant on\nf-release. Not too hard to resolve, actually. But I really only needed\none change pulled into master, and when I cherry picked instead of\nmerging the whole branch, there were no conflicts, and master ended up\ncontaining exactly what I wanted.\n\n> My impression is that \"f-release\" actually\n> mixes release engineering and maintenance. Two possible remedies:\n> \n> - Separate release engineering from maintenance and merge only the\n> latter to master\n\nAh, thank you! This is invaluable advice. I think I'll go with this\noption since mixing release engineering and maintenance is exactly what\nI'm doing. Hopefully it's worth the added complexity of having another\npublic branch.\n\nI pushed an example to https://github.com/meonkeys/releaseBranchDemo\nthat I'll share with my developers.\n\n\"git merge -sours\" will definitely be something useful to add to the\nquiver too.\n"}]}