lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sun, 24 May 2020 17:12:21 -0400
From:   Sasha Levin <>
To:     Linus Torvalds <>
Cc:     Greg KH <>,
        Heikki Krogerus <>,
        Andrew Morton <>,
        Linux Kernel Mailing List <>,
        Stephen Rothwell <>
Subject: Re: [GIT PULL] Driver core fixes for 5.7-rc7 - take 2

On Sun, May 24, 2020 at 03:45:50PM -0400, Sasha Levin wrote:
>On Sun, May 24, 2020 at 10:05:28AM -0700, Linus Torvalds wrote:
>>Sasha mentioned "--follow", which also happens to show that commit,
>>but that's more of an incidental happenstance than anything else. "git
>>log --follow" is kind of a special case, where git stops doing some of
>>the pathname-based simplifying, because if the file shows up from
>>nothing, git will try to then figure out where it came from. The fact
>>that "--follow" this ends up not pruning irrelevant history as
>>aggressively is more of an implementation artifact than anything else.
>>So generally, don't use "--follow". It's kind of a hack to emulate
>>"track changes to a file", but it is a hack, and it fundamentally is a
>>bogus operation (for all the same reasons that the CVS/SCCS/SVN/etc
>>notion of a "file identity" is complete garbage and leads to
>>fundamental problems).
>Interesting. My thinking around --follow was that it's like
>--full-history in the sense that it won't prune history, but it would
>also keep listing history beyond file renames.
>The --follow functionality is quite useful when looking at older
>branches and trying to understand where changes should go into on those
>older branches.
>We also do have some notion of "file identity" in the kernel; it's
>prevalent with "quirk files". Look at these for example:
> - drivers/mmc/core/quirks.h
> - sound/pci/hda/patch_*.c
> - drivers/hid/hid-quirks.c
>We know that patches to those files are likely to contain quirks (which
>we usually want to take into the Stable branches) so I might have a
>script that monitors a list of these "special" files in which case I
>need to see a complete list of commits that went into those files.

(and I'd like to see the reverts too, so that I could apply that revert
to Stable trees as well. If a revert doesn't show up in git log we might
miss doing a backport of it).


Powered by blists - more mailing lists