[Pulp-dev] Merging forward commits
daviddavis at redhat.com
Tue Mar 21 19:18:38 UTC 2017
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> wrote:
> 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
>> 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 on
>> a given branch, whether we're cherry-picking or we're merging forward, as
>> 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