[apparmor] test git repo

[intrigeri]

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 :)

> 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.

Cheers,
-- 
intrigeri