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

[Sean Myers]

On 05/25/2017 10:30 AM, Patrick Creech wrote:
> -1
> 
> 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.

Merging forward *does not* guarantee that the changes you're looking
for actually exist on a branch. git-cherry does. The article you
linked is citing a specific problem and blaming it on cherry-picking,
which is that when cherry-picking commits *with conflicts*, you can
confuse git-cherry. This is accounted for in the in the PUP, and for
good reasons.

> ...
> 
> 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.  

In my experience, only one merge-forward problem was caused by
automation (the mergepocalype, when 2.10 was considered "less than"
2.2, and got merged forward into a lower branch). The rest were
intelligent humans making mistakes, first with a bad merge, and second
by trusting that the appearance of a given commit hash on a branch
means that the *change* associated with that commit hash therefore
also appears on that branch (it does not). Perhaps ironically, any
improvement to the merge-forward process would likely involve using
git-cherry to track actual changes, ignoring what hash is where.

The suggestions that we invent a better process for merging forward
immeditaely followed by a suggestion to not invent a new process is a
little bit confusing. Either deal with the merge-forward papercuts or
the cherry-pick papercuts, it's inventing new process either way. When
it comes to the merging forward process, the intelligent humans were
(in my opinion) being diligent in their application of the process in
every failure case I can recall, and I don't think just throwing more
"diligence" at the problem will solve it.

On the other hand, cherry-picking back from master is not a new
process that we're inventing. This is a common workflow, not something
being invented by this PUP, so the opportunity to find help with this
process outside of this team is tremendously valuable. No such
opportunity exists with the merge-forward strategy without moving to a
more generally-accepted merging strategy like git flow(/driessen).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 866 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20170525/119faa2c/attachment.sig>