[Pulp-dev] PUP-3: Proposal to change our git workflow

Patrick Creech pcreech at redhat.com
Thu May 25 14:30:19 UTC 2017


I've come late to this topic, and wanted to wait till voting time to form an opinion, so I apologize
if some of the reasons I'm voting -1 have already been discussed and brought up.

While trying to come up with a decision on this topic, I googled "git merge vs cherry-pick".  The
overwhelming ammount of search results were basically 'don't cherry-pick!'.  The page that I favored
is [0].  It brings up some good points about loosing git's internal tracking of commits.  It seems
cherry-picks do get new commit id's instead of using the same ones.  While this site is basically a
'Don't cherry pick' opinion piece, it did make me think about our motivations for moving away.

One of my concerns is we are talking about adding more procedure and complexity, and I'm personally
questionable of the benefit.  Based on what i've read, people are using this strategy successfully,
so maybe I'm wrong on this assumption.

The main reason that I've noticed for peoples motivations for cherry-picking is 'Our merge workflow
has bit us repeatedly in the past, let's not do that anymore!'.  The second to last paragraph under
'Motivation' spells this out spectacularly.  The reasons for +1's with people I've spoken too have
seemed more of a vote -against- our current merge forward process than -for- cherry-picking.

I'm more in favor of us re-evaluating when and how we manage the merge forwards (as it does appear
our current automation has been a big source of pain at least once), and believe that just adding
better process and diligence around our current way of doing things will probably be better than
inventing a new process and figuring out the pain points as we go there.  

[0] https://dan.bravender.net/2011/10/20/Why_cherry-picking_should_not_be_part_of_a_normal_git_workf

On Wed, 2017-05-24 at 16:00 -0400, David Davis wrote:
> I’d like to kick off the voting on PUP-3 which is the proposal to change our git workflow by using
> cherry-picks instead of merging changes forward. The proposal can be viewed here:
> https://github.com/daviddavis/pups/blob/pup3/pup-0003.md
> Feel free to submit any comments/nitpicks/etc on the PR[0]. 
> PUP-1 outlines our voting system:
> https://github.com/pulp/pups/blob/master/pup-0001.md
> But to sum it up:
> +1: "Will benefit the project and should definitely be adopted."
> +0: "Might benefit the project and is acceptable."
> -0: "Might not be the right choice but is acceptable."
> -1: "Not the right choice and should definitely not be adopted."
> I’ll set the initial deadline for the voting to be June 5th 9pm UTC.
> [0] https://github.com/pulp/pups/pull/3
> David
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20170525/41042297/attachment.sig>

More information about the Pulp-dev mailing list