[apparmor] test git repo

[John Johansen]

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.