[Pulp-dev] Merging forward commits
bbouters at redhat.com
Tue Mar 21 20:08:50 UTC 2017
I would really like to collaborate on this. First one to start it; let the
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.
> On Tue, Mar 21, 2017 at 2:49 PM, Brian Bouterse <bbouters at redhat.com>
>> I plan to turn this thread into a formal RFC once that process has been
>> On Tue, Mar 21, 2017 at 11:13 AM, Sean Myers <sean.myers at redhat.com>
>>> 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
>>> > where exactly change had been applied?
>>> > I agree with Mike and think that merging forward is so super simple, i
>>> > 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
>>> forward does not give us the confidence (or ability) to track where
>>> 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
>>> 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
>>> 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
>> Pulp-dev mailing list
>> Pulp-dev at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pulp-dev