On 10/03/2017 12:16 AM, intrigeri wrote: > Hi, > > Steve Beattie: >> On Sat, Sep 30, 2017 at 07:50:56AM +0200, intrigeri wrote: >>> One thing I've noticed is that the way changes are backported from >>> master to older branches (i.e. tons of cherry-picks) makes history >>> hard to analyze, i.e. it's very hard to tell "what do we have in >>> master but not in apparmor-2.11". One way we fix that problem in other >>> projects is to fork topic branches not off master, but off the oldest >>> maintenance branch the topic branch is a candidate for, and then we >>> merge the topic branch into all candidate maintenance branches, no >>> cherry-pick involved, no commit duplication, and history becomes more >>> useful :)
Hrmmm this is problematic. Many patches come out of development and then end up being backported/reworked as fixes for older releases. > >> Do you have a smallish example git tree you can point to? > > I'm afraid not. I could cook one if the above explanation is > not sufficient. > >> I want to make sure it looks nothing like what upstream php does[1], >> which makes it nearly impossible to tease out how a patch was >> cherry-picked for a specific newer branch[2], > > [...] > >> [1] http://git.php.net/?p=php-src.git > >> [2] For a specific random example: https://bugs.php.net/bug.php?id=74111 >> aka CVE-2017-12933. Original commit is >> >> http://git.php.net/?p=php-src.git;a=commit;h=f8c514ba6b7962a219296a837b2dbc22f749e736 >> which got applied to the php 5.6 branch and then >> merged forward onto the php 7.x branches... but possibly as >> >> http://git.php.net/?p=php-src.git;a=commit;h=3a25a56a92ac1d0d6028a8ecd32ccf03bcd71ade >> ? However, doing 'git tag --contains' on >> f8c514ba6b7962a219296a837b2dbc22f749e736 and >> 3a25a56a92ac1d0d6028a8ecd32ccf03bcd71ade shows both commits in >> the 7.0.22 tag... so what actually applies to 7.0? Attempting to >> use tig to visualize what's happening just leads to nonsense. > > So apparently that commit was cherry-picked into the 7.x branch *and* > the 5.x branch was merged into 7.x, which results in a duplicate > commit on 7.x, that's indeed totally confusing. IMO one should either > cherry-pick or merge forward, but doing both gives the worst of both > worlds. This is not what I'm proposing. Instead, I'm suggesting we do > merge forward only and essentially forget that cherry-pick exists. > I don't see how that would work. Often the code is different enough that merging forward just doesn't work, and cherry-picked patches are more of backported patches. At which point you are now doing backports and forward merges which isn't what you want. -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
