lists.openwall.net   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 15:45:50 -0400
From:   Sasha Levin <sashal@...nel.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Greg KH <gregkh@...uxfoundation.org>,
        Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Stephen Rothwell <sfr@...b.auug.org.au>
Subject: Re: [GIT PULL] Driver core fixes for 5.7-rc7 - take 2

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.

-- 
Thanks,
Sasha

Powered by blists - more mailing lists