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

Tue May 30 09:48:47 UTC 2017

+0 from me

I think community contributions can be handled well in both cases,
merge-forward or cherry-pick.
As for the difficulty it is more a matter of habit, in my opinion.

I expect the cherry-pick approach to be less error-prone and mostly for
that reason I would give it a try with all the drawbacks it has.

On Fri, May 26, 2017 at 6:24 PM, Ina Panova <ipanova at redhat.com> wrote:

> Usually, you tend not have your PR opened for months,especially if it is a
> bugfix tracked in our sprint :)
>
> Really, what is difficult about step 5 and 6 i don't understand? you pull
> changes so branch is up to date, then you merge into this branch, then you
> push to upstream. If there are conflicts you are resolving them locally,
> then pushing upstream.
>
> What i want to say in other words - right now the merge or PRs takes me
> like 2 mins going through whole chain of branch-dev to master. Rarely i
> need to solve conflicts, but honestly saying i do not remember when was
> last time i've been solving those.
>
> With new approach it will be, merge here, cherry pick there, open pr for
> cherry picks, merge pr, open redmine, change it,etc
>
> Those are my personal 2 cents.
> I am opened to try this out, i just find that this new approach does not
> cover the cost of steps and time involved for making the git history
> cleaner and other things mentioned previously in my email
>
>
>
> --------
> Regards,
>
> Ina Panova
> Software Engineer| Pulp| Red Hat Inc.
>
> "Do not go where the path may lead,
>  go instead where there is no path and leave a trail."
>
> On Fri, May 26, 2017 at 5:46 PM, David Davis <daviddavis at redhat.com>
> wrote:
>
>> The current workflow is more than a two-step process. To expand all the
>> steps:
>>
>> 1. Decide what x.y-dev branch to open a PR against
>> 2. Open a PR against that branch
>> 3. After the PR is accepted, decide if you can actually still merge it
>> against the branch. This is necessary if for example, if I opened a PR
>> several months ago against 2.12-dev and it was since released. Then I have
>> to update the PR to point to 2.13-dev.
>> 4. Merge the PR
>> 5. Merge the x.y-dev branch to master locally
>> 6. Push the local changes directly to the upstream repository
>>
>> These steps 5 and 6 seem more error prone in that no one is reviewing
>> them. In the git cherry-pick workflow, having someone reviewing the
>> cherry-picks should reduce errors. Also, since you’re moving individual
>> commits instead of merging whole branches together, mistakes should be far
>> less disastrous if they do somehow occur.
>>
>>
>> David
>>
>> On Fri, May 26, 2017 at 10:29 AM, Ina Panova <ipanova at redhat.com> wrote:
>>
>>> -0
>>>
>>> I don't know, i am personally not super excited about cherry-picking,
>>> too many involved resources imho in order to compensate crazy git history.
>>>
>>> 1. submit pr against master
>>> 2. decide into which branches it should be cherry-picked
>>> 3. submit PRs against those branches
>>> 4. Find someone to approve it( person can approve it right away or can
>>> forget), you then need again to bother the person to approve the PR, plus
>>> you also can forget about them.
>>> 5. If the bugfix/rfe/hotfix consists of several PRs, like platform and
>>> plugin, you need to take care of more PRs and be sure you opened all of
>>> them and merged all of them.
>>> 6. since the commit id changes, you need to keep track of the info
>>> externally. That means open Redmine and update it.
>>>
>>>
>>> With merge forward you just merge forward and need to take care of:
>>>
>>> 1. be sure you merged all PRs through all branches.
>>> 2. solve conflicts occasionally.
>>>
>>>
>>> The concern Brian brought up - that contributors do not know against
>>> which branch to submit PR. Instead of asking them to re-submit PR against
>>> different branch we can cherry pick this,
>>> We don't have that 'big traffic' of PRs from contributors and once in a
>>> while we can cherry pick if the PR was submitted against wrong branch.
>>>
>>> Another thing which was stated in the motivation was 'We've also seen
>>> some mistakes where branches are accidentally merged into other branches. "
>>> I guess we will have much higher chance to make a mistake or forget
>>> something between steps 1-6 mentioned for cherry-picking then steps 1-2
>>> mentioned for merging forward.
>>>
>>>
>>>
>>> --------
>>> Regards,
>>>
>>> Ina Panova
>>> Software Engineer| Pulp| Red Hat Inc.
>>>
>>> "Do not go where the path may lead,
>>>  go instead where there is no path and leave a trail."
>>>
>>> On Thu, May 25, 2017 at 6:49 PM, Sean Myers <sean.myers at redhat.com>
>>> wrote:
>>>
>>>> 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).
>>>>
>>>>
>>>> _______________________________________________
>>>> Pulp-dev mailing list
>>>> Pulp-dev at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Pulp-dev mailing list
>>> Pulp-dev at redhat.com
>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>
>>>
>>
>
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20170530/29bb39fc/attachment.htm>