[Pulp-dev] Merging forward commits

[David Davis]

I’ve been working on the PUP for cherry-picking changes across our branches
and I’ve opened a PR. Feedback would be much appreciated.

https://github.com/pulp/pups/pull/3

Also, I wanted to mention that it might be worth discussing how we can
improve our merge forward process even if we don’t want to use
cherry-picking instead. We’ve seen a couple accidental merges and I was
wondering if there might be some way to prevent that? Two options I can
think of. First maybe we could merge forward less often? I’m not sure how
to time this. Secondly, perhaps we could use code reviews/PRs to confirm
merges?

Thanks.

David

On Tue, Mar 21, 2017 at 4:08 PM, Brian Bouterse <bbouters at redhat.com> wrote:

> I would really like to collaborate on this. First one to start it; let the
> other know.
>
> On Tue, Mar 21, 2017 at 3:18 PM, David Davis <daviddavis at redhat.com>
> wrote:
>
>> So I was planning on doing that actually. Although, if you have the spare
>> cycles, go for it.
>>
>>
>> David
>>
>> On Tue, Mar 21, 2017 at 2:49 PM, Brian Bouterse <bbouters at redhat.com>
>> wrote:
>>
>>>  I plan to turn this thread into a formal RFC once that process has been
>>> ratified.
>>>
>>> On Tue, Mar 21, 2017 at 11:13 AM, Sean Myers <sean.myers at redhat.com>
>>> wrote:
>>>
>>>> On 02/06/2017 12:09 PM, Ina Panova wrote:
>>>> > Seems like we are trying to choose/figure out what's more important -
>>>> > linear commit history which is readable or confidence and ability to
>>>> track
>>>> > where exactly change had been applied?
>>>> >
>>>> > I agree with Mike and think that merging forward is so super simple,
>>>> i must
>>>> > admit i had issues to understand this strategy from the beginning but
>>>> now i
>>>> > could do that even with closed eyes.
>>>>
>>>> The problem, as has become very clear in the past few days, is that
>>>> merging
>>>> forward does not give us the confidence (or ability) to track where
>>>> exactly
>>>> a change has been applied. All it tells us is what commit hashes exist
>>>> on a
>>>> branch, which is not the same thing. You can record a commit hash as
>>>> merged
>>>> without bringing its changes forward, which is a necessary step in
>>>> fixing
>>>> merge-forward mistakes. The best way to see if a specific change exists
>>>> on
>>>> a given branch, whether we're cherry-picking or we're merging forward,
>>>> as I
>>>> understand it, is to use 'git cherry'.
>>>>
>>>>
>>>> _______________________________________________
>>>> 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/20170411/d9a2bb8b/attachment.htm>