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

Ina Panova ipanova at redhat.com
Fri May 26 16:24:33 UTC 2017


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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20170526/6d2bd259/attachment.htm>


More information about the Pulp-dev mailing list