# configuring cherry-pick to always use -x? 12 messages from 2011-02-14 to 2011-02-15. Participants: Adam Monsen, Jay Soffian, Junio C Hamano, Michael J Gruber, Jonathan Nieder, Ivan Kanis. Thread: https://gitlist.dev/t/26500 ## Adam Monsen, 2011-02-14 17:19 Subject: configuring cherry-pick to always use -x? Message-ID: <4D596435.9020605@gmail.com> URL: https://gitlist.dev/e/4D596435.9020605%40gmail.com ``` Is there a configuration option to make cherry-pick always include the source commit hash in the new commit log message? e.g., make "git cherry-pick" always behave like "git cherry-pick -x"? My most frequent use case for cherry picking is between publicly visible branches. I have the following configuration option set: alias.cpx=cherry-pick -x but I rarely remember to use it. ``` ## Jay Soffian, 2011-02-14 18:09 Subject: Re: configuring cherry-pick to always use -x? Message-ID: URL: https://gitlist.dev/e/AANLkTin0xB%3DhJ-v21%2BesT6Zqj2f53XiwD8tBW4qFkuVy%40mail.gmail.com In-Reply-To: <4D596435.9020605@gmail.com> ``` On Mon, Feb 14, 2011 at 12:19 PM, Adam Monsen wrote: > Is there a configuration option to make cherry-pick always include the > source commit hash in the new commit log message? > > e.g., make "git cherry-pick" always behave like "git cherry-pick -x"? Nope, but one would be appreciated. :-) > My most frequent use case for cherry picking is between publicly visible > branches. > > I have the following configuration option set: > >  alias.cpx=cherry-pick -x > > but I rarely remember to use it. It's worse than that. I like to keep the message generated after a cherry-pick conflict, but the original commit authorship. I have this, which I call recommit: #!/bin/sh # Used after a cherry-pick conflicts to commit with the original # authorship (commit -c) but keep the newly generated commit message # self=$(cd "$(dirname "$0")" && pwd -P)/$(basename "$0") . "$(git --exec-path)/git-sh-setup" require_work_tree cd_to_toplevel test -f .git/MERGE_MSG || die "No .git/MERGE_MSG" if test "$GIT_EDITOR" = "$self" then cat .git/MERGE_MSG > .GIT/COMMIT_EDITMSG exit 0 fi if sha1=$(sed -ne \ 's/^(cherry picked from commit \([a-f0-9]\{40\}\))$/\1/p' .git/MERGE_MSG) then export GIT_EDITOR="$self" git commit -c $sha1 fi I've had it on my TODO list for a while now to: 1. add a config option to enable -x by default 2. improve the cherry-pick conflict UX. I was thinking of out CHERRY_HEAD on conflict and then adding a cherry-pick --continue option which acts like rebase --continue. CHERRY_HEAD is what was being picked at the time of conflict and can be used by the bash completion script for proper prompting, as well as obviously the --continue option. j. ``` ## Junio C Hamano, 2011-02-14 21:05 Subject: Re: configuring cherry-pick to always use -x? Message-ID: URL: https://gitlist.dev/e/AANLkTimi%3Dd0qbO3_-BEnPEJ%2Biy9B%3D_fksF7TiBE7HorC%40mail.gmail.com In-Reply-To: <4D596435.9020605@gmail.com> ``` On Mon, Feb 14, 2011 at 9:19 AM, Adam Monsen wrote: > Is there a configuration option to make cherry-pick always include the > source commit hash in the new commit log message? Not currently, but before we go any further, could you please justify in what workflow it would make sense to use -x most of the time? We used to add the "cherry-picked from" by default in the very early days, and stopped doing so for a reason, and also deliberately stayed away from adding such a configuration to actively discourage the use of -x without making the user thinking twice. ``` ## Junio C Hamano, 2011-02-14 21:23 Subject: Re: configuring cherry-pick to always use -x? Message-ID: URL: https://gitlist.dev/e/AANLkTinpY2B0g-U4No-8rV7TFV5-z%3Dx7AAGqgHNR7Wrt%40mail.gmail.com In-Reply-To: ``` On Mon, Feb 14, 2011 at 10:09 AM, Jay Soffian wrote: > I've had it on my TODO list for a while now to: > ... > 2. improve the cherry-pick conflict UX. I was thinking of out > CHERRY_HEAD on conflict and then adding a cherry-pick --continue > option which acts like rebase --continue. CHERRY_HEAD is what was > being picked at the time of conflict and can be used by the bash > completion script for proper prompting, as well as obviously the > --continue option. Yes, we have so far only "use commit -c $that_one", which is an obvious and low hanging fruit for improvement. Thanks. ``` ## Adam Monsen, 2011-02-14 21:50 Subject: Re: configuring cherry-pick to always use -x? Message-ID: <4D59A39C.9090402@gmail.com> URL: https://gitlist.dev/e/4D59A39C.9090402%40gmail.com In-Reply-To: ``` Junio C Hamano wrote: > could you please justify in what workflow it would make sense to use > -x most of the time? Sure. Summary: two long-lived publicly visible branches. Details: Mifos is what I'm usually working on lately. We have branches "master" and "f-release" both present in our public git repository called "head" (hosted at sf.net). master is the bleeding edge of development, f-release is a release maintenance branch recently created off the tip of master. I expect both to live on forever (even though commits to f-release will eventually cease). Right after f-release was cut, we merged f-release to master every day or so to make sure bugfixes for f-release were also propagated to future releases. After a while, merging resulted in too many conflicts and we started cherry picking instead. This process is described generally at http://mifosforge.jira.com/wiki/display/MIFOS/Release+Branch+Merging+Policy . If the source commit is present in the log message of the new (cherry picked) commit, it's easy to (1) find the source commit (gitweb creates a hyperlink, for instance) and (2) know that, when viewing the log of master, a particular commit is also present on another branch. Right now I just keep reminding folks to use -x. For (2), I generally assume that branch is a release branch, but come to think of it, it would be nice to know what branch a commit was cherry picked from. For example: "(cherry picked from BRANCHNAME commit c6e08938e352f3ec99a29a67dd192945d2bcf00d)" would be better than the current message generated by -x. See also: http://mifosforge.jira.com/wiki/display/MIFOS/Mifos+Version+Control+Guide ``` ## Jay Soffian, 2011-02-14 21:53 Subject: Re: configuring cherry-pick to always use -x? Message-ID: URL: https://gitlist.dev/e/AANLkTikKXLBf2HYk2CZmVMzgVhYUAL%3DURFTZ851eb5do%40mail.gmail.com In-Reply-To: ``` On Mon, Feb 14, 2011 at 4:05 PM, Junio C Hamano wrote: > Not currently, but before we go any further, could you please justify > in what workflow it would make sense to use -x most of the time? In one of my repos, most of the time my cherry-picks are between two public branches. Perhaps a better enhancement would be something like: branch..annotate_cherry_pick = {true, false} which could be set to true for source branches that you wish to default to -x. Or, maybe it makes sense in cases where the source branch is a remote-tracking branch: cherry_pick.annotate = {local, remote} I'm not sure how good a remote-tracking branch is as an indicator of 'public branch', though, so I think explicitly configuring it per-branch makes more sense. I hesitate there only because we don't currently put remote-tracking branches in the branch section names. j. ``` ## Michael J Gruber, 2011-02-15 08:58 Subject: Re: configuring cherry-pick to always use -x? Message-ID: <4D5A401B.1050103@drmicha.warpmail.net> URL: https://gitlist.dev/e/4D5A401B.1050103%40drmicha.warpmail.net In-Reply-To: <4D59A39C.9090402@gmail.com> ``` Adam Monsen venit, vidit, dixit 14.02.2011 22:50: > Junio C Hamano wrote: >> could you please justify in what workflow it would make sense to use >> -x most of the time? > > Sure. Summary: two long-lived publicly visible branches. > > Details: > Mifos is what I'm usually working on lately. We have branches "master" > and "f-release" both present in our public git repository called "head" > (hosted at sf.net). master is the bleeding edge of development, > f-release is a release maintenance branch recently created off the tip > of master. I expect both to live on forever (even though commits to > f-release will eventually cease). > > Right after f-release was cut, we merged f-release to master every day > or so to make sure bugfixes for f-release were also propagated to future > releases. After a while, merging resulted in too many conflicts and we > started cherry picking instead. > > This process is described generally at > http://mifosforge.jira.com/wiki/display/MIFOS/Release+Branch+Merging+Policy I don't quite understand how cherry picks could conflict less then merges if the release branch contains fixes only. Also, I don't think the advice to use "merge+revert" is a good one. All of this indicates a suboptimal use of branches. My impression is that "f-release" actually mixes release engineering and maintenance. Two possible remedies: - Separate release engineering from maintenance and merge only the latter to master - If you do want them on the same branch "f-release", you probably know beforehand which commits you don't want on master. You can fake-merge these ("merge -Xours") to master and merge the others, which is somewhat ugly but still better than cherry-picking everything. In some sense this is "manual rerere" whose results are shared (pushed) easily.(*) Michael (*) If that is cryptic, I mean something like: git checkout master git merge f-release #be happy if it succeeds, identify problematic commit X if not; decide whether X belongs on master; if yes resolve, if not reset and: git merge X^ git merge -Xours X #back to start ``` ## Jonathan Nieder, 2011-02-15 09:18 Subject: Re: configuring cherry-pick to always use -x? Message-ID: <20110215091828.GA22661@elie> URL: https://gitlist.dev/e/20110215091828.GA22661%40elie In-Reply-To: <4D5A401B.1050103@drmicha.warpmail.net> ``` Michael J Gruber wrote: > - If you do want them on the same branch "f-release", you probably know > beforehand which commits you don't want on master. You can fake-merge > these ("merge -Xours") to master and merge the others For the record, I think that should be -sours. I think it's just a typo but the difference is big --- -sours means "supersede by pretending to merge but actually keeping our version", while -Xours means "do a normal merge but be sloppy and favor our change when encountering adjacent or overlapping changes". I suppose -Xours should have been named -Xfavor-ours, -Xsloppy-favoring-ours, or something similarly explicit. > git checkout master > git merge f-release > #be happy if it succeeds, identify problematic commit X if not; decide > whether X belongs on master; if yes resolve, if not reset and: > git merge X^ > git merge -Xours X > #back to start Thanks for a nice example. Jonathan ``` ## Michael J Gruber, 2011-02-15 09:29 Subject: Re: configuring cherry-pick to always use -x? Message-ID: <4D5A4761.6010308@drmicha.warpmail.net> URL: https://gitlist.dev/e/4D5A4761.6010308%40drmicha.warpmail.net In-Reply-To: <20110215091828.GA22661@elie> ``` Jonathan Nieder venit, vidit, dixit 15.02.2011 10:18: > Michael J Gruber wrote: > >> - If you do want them on the same branch "f-release", you probably know >> beforehand which commits you don't want on master. You can fake-merge >> these ("merge -Xours") to master and merge the others > > For the record, I think that should be -sours. > > I think it's just a typo but the difference is big --- -sours means > "supersede by pretending to merge but actually keeping our version", > while -Xours means "do a normal merge but be sloppy and favor our > change when encountering adjacent or overlapping changes". Yes, sorry and thanks. -Xours may still be useful to know for the OP, but for the complete fake-merge you need -sours. In fact, "-sours" has an awfully good mnemonic when used for fake-merging commits which you do not want to cherry-pick :) Michael ``` ## Ivan Kanis, 2011-02-15 09:38 Subject: Re: configuring cherry-pick to always use -x? Message-ID: <87vd0lwscm.fsf@kanis.fr> URL: https://gitlist.dev/e/87vd0lwscm.fsf%40kanis.fr In-Reply-To: ``` Hi Junio, Junio C Hamano wrote: > On Mon, Feb 14, 2011 at 9:19 AM, Adam Monsen wrote: >> Is there a configuration option to make cherry-pick always include the >> source commit hash in the new commit log message? > > Not currently, but before we go any further, could you please justify > in what workflow it would make sense to use -x most of the time? > > We used to add the "cherry-picked from" by default in the very early > days, and stopped doing so for a reason, and also deliberately stayed > away from adding such a configuration to actively discourage the use > of -x without making the user thinking twice. Could you elaborate on the reason why -x is a bad idea? Kind regards, -- Ivan Kanis, Release Manager, Vision Objects, Tel +33 2 28 01 84 44, Fax +33 2 40 25 89 20 http://www.visionobjects.com We meet no Stranger, but Ourself. -- Emily Dickinson ``` ## Jay Soffian, 2011-02-15 16:16 Subject: Re: configuring cherry-pick to always use -x? Message-ID: URL: https://gitlist.dev/e/AANLkTinMBBKwtkQKgyqaN%2BoH4-k1Ks_6SbnU7thzuuYs%40mail.gmail.com In-Reply-To: <4D5A401B.1050103@drmicha.warpmail.net> ``` On Tue, Feb 15, 2011 at 3:58 AM, Michael J Gruber wrote: > - If you do want them on the same branch "f-release", you probably know > beforehand which commits you don't want on master. You can fake-merge > these ("merge -Xours") to master and merge the others, which is somewhat > ugly but still better than cherry-picking everything. In some sense this > is "manual rerere" whose results are shared (pushed) easily.(*) I personally prefer cherry-pick, as the fake merge clutters mainline's history with the superseded commits. It would be interesting to have a history simplification that given a merge M of parents A and B, ignored commits $(merge-base A B)..B where M is TREESAME to A. Hmm, that's effectively "git rev-list ." isn't it? j. ``` ## Adam Monsen, 2011-02-15 21:03 Subject: release maintenance vs. release engineering (was: configuring cherry-pick to always use -x?) Message-ID: <4D5AEA2F.9000606@gmail.com> URL: https://gitlist.dev/e/4D5AEA2F.9000606%40gmail.com In-Reply-To: <4D5A401B.1050103@drmicha.warpmail.net> ``` Michael J Gruber wrote: > I don't quite understand how cherry picks could conflict less then > merges if the release branch contains fixes only. The last time I experienced a painful merge from f-release to master, it was because some files had been culled from master but left extant on f-release. Not too hard to resolve, actually. But I really only needed one change pulled into master, and when I cherry picked instead of merging the whole branch, there were no conflicts, and master ended up containing exactly what I wanted. > My impression is that "f-release" actually > mixes release engineering and maintenance. Two possible remedies: > > - Separate release engineering from maintenance and merge only the > latter to master Ah, thank you! This is invaluable advice. I think I'll go with this option since mixing release engineering and maintenance is exactly what I'm doing. Hopefully it's worth the added complexity of having another public branch. I pushed an example to https://github.com/meonkeys/releaseBranchDemo that I'll share with my developers. "git merge -sours" will definitely be something useful to add to the quiver too. ```