[Pulp-dev] Merging forward commits

[Ina Panova]

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.

+1 of writing down the benefits of cherry-picking and clear our
expectations.



--------
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, Feb 2, 2017 at 6:50 PM, David Davis <daviddavis at redhat.com> wrote:

> I think the merging forward seems pretty straightforward as well (with
> some exceptions) but one of the my concerns is expecting community
> contributors to know our process, the last release branch, etc when they
> open a PR. Maybe this isn’t something to worry about though if we don’t
> have enough contributions from outside the core Pulp team.
>
> Another one of my concerns is the git history being cluttered by merging
> forward every time we commit a bug fix or hot fix (see my original email).
> Thinking through this a bit though, what if we merged forward commits less
> often? One option might be to only merge forward when we do a release.
>
> Also, I like the idea of creating a proposal and trying out cherrypicking
> to see what the benefits would be and if we actually meet those benefits by
> cherrypicking.
>
>
> David
>
> On Thu, Feb 2, 2017 at 10:46 AM, Michael Hrivnak <mhrivnak at redhat.com>
> wrote:
>
>> This comes up periodically, and we've had split opinions for a long time.
>> I've been in the camp that likes merging, and finds it intuitive. But I'm
>> open to trying cherry-picking since there is a lot of interest.
>>
>> I must admit, I am always surprised when people describe merging forward
>> as complicated. For me, it boils down to this:
>>
>> - Features happen on master. No merging or cherry-picking required.
>> - Bug fixes happen on the last release branch. Merge your bugfix branch
>> to master and the release branch. Simple.
>> - Hotfixes are a rare exception that require slightly more thought, but
>> are still easy to reason about. If in doubt, "git merge-base [list all the
>> places you want to merge your fix]" tells you where to branch from.
>>
>> That's the extent of my thought process when merging forward. I am
>> generally interested to know more about how this process causes friction.
>>
>> But all of that said, I'm very happy to give cherry-picking a try. As
>> Brian said, my main concern would just be tracking where a change has been
>> applied. This is something I value a lot in the merge model.
>>
>> If we do switch, I think we should first write down specifically what
>> benefits we expect to get. That would help in two ways: 1) Make sure
>> everyone is on the same page about what we expect to gain. I suspect there
>> are differing assumptions across the group. 2) Enable us to evaluate
>> afterward to what extent the change was successful.
>>
>> Lastly, our current branching model was inspired by this classic approach:
>>
>> http://nvie.com/posts/a-successful-git-branching-model/
>>
>> If you're not familiar, it's worth a read for perspective. Their
>> "develop" branch is our "master". And obviously we don't do things in quite
>> the same way, but the general principles are the same.
>>
>> Michael
>>
>> On Thu, Feb 2, 2017 at 3:34 PM, Brian Bouterse <bbouters at redhat.com>
>> wrote:
>>
>>> The main concern for me is how to track the cherry picks in Redmine.
>>> Using the rebase and merge approach, or if Github had a dedicate cherry
>>> pick feature, we still need a way in Redmine to know if any given bugfix
>>> has been applied to older release streams, i.e. the current bugfix release
>>> stream.
>>>
>>> On Wed, Feb 1, 2017 at 12:18 PM, Jeremy Audet <jaudet at redhat.com> wrote:
>>>
>>>> > Thinking out loud, it would be nice if github would support a
>>>> "cherry pick" PR
>>>>
>>>> I think you can. The submitter just needs to open a PR against some
>>>> branch other than master, and the merger needs to select the rebase
>>>> and merge <https://github.com/blog/2243-rebase-and-merge-pull-requests>
>>>> GUI option.
>>>>
>>>
>>>
>>> _______________________________________________
>>> 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/20170206/84b5247b/attachment.htm>