Re: Git help for kernel archeology, suppress diffs caused by CVS keyword expansion

On Jul 22 2007 14:48, Jon Smirl wrote:

It would really be useful if git diff had an option for suppressing
diffs caused by CVS keyword expansion. I run into this problem over
and over when trying to recover stuff out of old kernel sources that
people checked into CVS and then posted CVS diffs to fulfill their GPL
obligations. I sometimes wonder if vendors are doing this on purpose
to make it more difficult to recover the changes they made to the
code.

To prevent this in the future, I'd love to see a patch removing all
CVS keywords from the kernel sources.

I say: yes please. Even svn (which Linus dislikes very much) has cvs
keywords disabled by default. And at the same time, a patch to
CodingStyle not to include CVS tags, and a patch to checkpatch.pl
to enforce it :)

Quick grep of kernel shows 1,535 $Id, 197 $Log, 441 $Revision, 144 $Date. I
guestimate that this would remove about 5,000 lines form the kernel source
and touch 1,700 files. Would this be accept or do those expansions contain
useful info?

Common argument for $Id$ tags has been, that upon a problem, a user
can look into dmesg (or whatever log is appropraite - it's not
limited to the kernel) for the version string instead of figuring it
out himself (by means or rpm -q, or whatever hides it).

For the Linux kernel however, I do not think it is important, since:

- the code of a module changes faster than you can think (e.g.
  a change in the network code touched a network filesystem). Result:
  same $Id$ tag in the vendor's version AND the mainline version.
  So the tag is useless.

- you know what version you are running, mingetty usually prints it
  for you; uname -a also shows it.

- if you have a problem, people kindly ask you to bisect anyway, in
  which case $Id$ numbers become irrelevant anyway, because you got
  the git SHA1 ids.

Yep, that's pretty much it from my side. Conclusion: Remove CVS
tags from kernel.



	Jan
--