A Method of Breaking Git

[Bjørn Mork]

Ack on the broken history problem.

I don't think it's necessary to keep two separate histories though.  The
main issue is the periodical removal of files keeping parts of history,
resulting in an increasing number of file names to follow for the
complete history.

Doing

 git mv config-5.15 config-6.1
 git commit -m 'move Linux 5.15 kernel configuration to Linux 6.1 configuration'
 cp config-6.1 config-5.15
 git commit -m 'resurrect Linux 5.15 kernel configuration' config-5.15

would make sure that config-6.1 kept all the history.  It results in a
history-less config-5.15, but IMHO that's a minor issue.  The point is
to maintain full history attached to one file.  The name of this file is
not important.

The duplicate history attached to the older filename is less
interesting. It will still show changes happening after the split of
course. And you'll most likely start with the "master" history in any
case, and only look at the other file in case there are differences not
explained by that history.

(Note that two separate commits are required since git is "smart" enough
to detect what happens if you try to squash them)


Bjørn