Re: history damage in linux.git

From: John Keeping <john@keeping.me.uk>
Date: Apr 21, 2016, 13:19 UTC
Message-ID: <20160421131916.GB1589@serenity.lan>
In-Reply-To: <20160421113004.GA3140@aepfle.de>

On Thu, Apr 21, 2016 at 01:30:04PM +0200, Olaf Hering wrote:

Show 24 quoted lines

> To track the changes in hyperv related files I created some scripts
> years ago to automate the process of finding relevant commits in
> linux.git. Part of that process is to record the tag when a commit
> appeared in mainline. This worked fine, until very recently.
> 
> Suddenly years-old commits are declared as having-just-arrived in
> linux.git. Look at this example:
> 
>   $ git log --oneline -- drivers/input/serio/hyperv-keyboard.c
>   2048157 Drivers: hv: vmbus: fix the building warning with hyperv-keyboard
>   62238f3 Input: hyperv-keyboard - register as a wakeup source
>   c3c4d99 Input: hyperv-keyboard - pass through 0xE1 prefix
>   aed06b9 Input: add a driver to support Hyper-V synthetic keyboard
>   $ git describe --contains aed06b9
>   v4.6-rc1~9^2~792
>   $ git show aed06b9 | head
>   commit aed06b9cfcabf8644ac5f6f108c0b3d01522f88b
>   Author: K. Y. Srinivasan <kys@microsoft.com>
>   Date:   Wed Sep 18 12:50:42 2013 -0700
> 
> Obviously that and other commits are in the tree since a very long time.
> 
> How can I find out whats going on? Is my git(1) 2.8.1 broken, or did
> Linus just pull some junk tree (and does he continue to do so)?

I suspect it indicates that an old tree was pulled in such that the path to v4.6-rc1 is shorter than to the older version. The commit is clearly in v3.13-rc1:

	$ git tag --contains aed06b9cfcabf8644ac5f6f108c0b3d01522f88b
	v3.13
	v3.13-rc1
	v3.13-rc2
	[snip]

The behaviour of describe is a bit clearer if you limit it to v3.*:

	$ git describe --match='v3.*' --contains aed06b9cfcabf8644ac5f6f108c0b3d01522f88b
	v3.13-rc7~9^2~14^2~42

	$ git describe --match='v3.13-rc1' --contains aed06b9cfcabf8644ac5f6f108c0b3d01522f88b
	v3.13-rc1~65^2^2~42

It seems that the path to v4.6-rc1 is "more direct" than to either of these commits: there is only one second-parent merge transition.

>From a quick look, I think the problem is in commit c155c7492c9a ("Merge

branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input") which merges a branch that has repeatedly had master merged back into it but does not build on any recent releases. The most recent tag on the first-parent history of that branch is v3.0-rc4.

I think it is as simple as git-describe (or git-name-rev which is used in the --contains case) preferring a less branchy path, which has been introduced in v4.6 with the merge commit above.