A Method of Breaking Git

[Christian Marangi]

On Tue, Oct 24, 2023 at 01:40:22PM +0200, Bjørn Mork wrote:
> 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)
> 

Also agree that this is a problem. lost of history is problematic and I
already had some problem trying to find why something was added 

Luckly this happen only on kernel bump so not that usual...

My problem with the "copy - resurrect" is that we would still lose
history (but this time on the old file) and have some bloat with an
additional commit... So I would like if there was a better solution

Anyway I have also found this [1]... if it does actually works, it might be
THE solution to our specific problem. Wonder if someone can test it on a
sample repository.

[1] https://devblogs.microsoft.com/oldnewthing/20190919-00/?p=102904

-- 
	Ansuel