Yii2: About code comparison results (2.0.14.1 => 2.0.14)

[frontbear]

yiisoft/yii2 Changes

https://github.com/yiisoft/yii2/compare/2.0.14...2.0.14.1

yiisoft/yii2-framework Changes

https://github.com/yiisoft/yii2-framework/compare/2.0.14...2.0.14.1

Is it normal ?

[SilverFire]

Not really. We had an infrastructure problem with subsplit updating. Need to check in details

[cebe]

So here is what happened:

First of all what you see is github showing a weird version of the diff, if you check the diff locally you have two options:

1. Make a diff on the tree objects (note the two dots between the versions):

   $ git diff 2.0.14..2.0.14.1 --stat |tail -1
    27 files changed, 253 insertions(+), 80 deletions(-)
   

   this is exactly the same as you get in the yiisoft/yii2 repo:

   $ git diff 2.0.14..2.0.14.1 --stat framework/ |tail -1
    27 files changed, 253 insertions(+), 80 deletions(-)
   

   The same result if you use two or three dots in the diff in yiisoft/yii2 repo.

2. Make a diff, taking all commit history into account (note the three dots between the versions):

   $ git diff 2.0.14...2.0.14.1 --stat |tail -1
    931 files changed, 111229 insertions(+), 60853 deletions(-)
   

   This is also what github does and what is looking weird.

So why is the diff on github and with ... looking weird?

We were using git 1.8.1.1 on an old server to create the subtree split before, which resulted in a git history which ends at commit https://github.com/yiisoft/yii2-framework/commit/1c9cf916b1394681c7d043e79e1522c33e5bc6c1 (tagged as 2.0.14) on the subsplit repo.

We have now moved our infrastructure to a new server in the process of setting up the new yiiframework.com website. We are creating the subsplit with git 2.11.0 now, which causes different commit hashes for the same commits, resulting in a second history to be created starting from the initial commit https://github.com/yiisoft/yii2-framework/commit/fc7c1f5673cfa3b756e23867e9f4d925c29b9033 The 2.0.14.1 tag is made on the new history branch as commit https://github.com/yiisoft/yii2-framework/commit/d99969394c66dc3606134af092b8ec561ea5d7c6. On this branch the original release commit for 2.0.14 has another commit hash, which is https://github.com/yiisoft/yii2-framework/commit/28b1fd66b59dc658b09999310b2a37fa98df6312

so if you compare the tags with ... git will summarize all history going down to the inital commit and back up from there to find 2.0.14, which results in the weird diff.

We are not going to re-create tags on the new commit history as the tags are signed.

Why is the history different in different git versions?

From the git subtree docs:

Repeated splits of exactly the same history are guaranteed to be
identical (i.e. to produce the same commit ids). Because of this, if
you add new commits and then re-split, the new commits will be attached
as commits on top of the history you generated last time, so 'git merge'
and friends will work as expected.

So normally we would expect this to not happen, however a bugfix in the way commit messages are created has happend shortly after 1.8.1.1: https://github.com/git/git/commit/a5b8e28e4eb5762c9da68b56efdf45d6c885bd56 This causes the commit messages to not contain a newline at the end in the new history branch, resulting in different commit hashes.

Result

We are staying with the new git version and leave everything as is, because:

• there is no problems with the files (the tree objects are equal)
• only the diff shown on github is weird, if you use .. locally you see the expected diff
• we do not want to re-create signed tags.

[frontbear]

This is a very detailed explanation, thank you very much!