Re: irt: Re: Core statement on version control systems

[Andrew Cagney <andrew.cagney%gmail.com@localhost>]

On Mon, 20 Oct 2025 at 19:19, Greg A. Woods <woods%planix.ca@localhost> wrote:

> He also initially posted a blog entry about the first steps to Git here,
> and it's more or less a rationale document (it was also in the above
> docs collection but was elided at some point):
>
> http://bsdimp.blogspot.com/2020/09/freebsd-subversion-to-git-migration.html

Thanks,  here's a link to "why" (it's missing from HEAD)
https://github.com/bsdimp/freebsd-git-docs/blob/72f477ac46d98b6c733684a4e50f1208228a3cfe/git-why.md

> > > That list is missing at least two critical points where git falls
> > > short:
> > >    - storing file rename data
> >
> > Is that a real requirement?  Or a hangover from a better CVS wishlist?
>
> For what it's worth I just did a file rename in a project, and
> introduced a number of changes in the file during the rename, and Git
> (2.35) picked up on it all, rename and changes all clearly marked.

Which is why I'm skeptical towards the requirement.  It's only correct
when the rename/copy is a commit on its own.
Edit the new file and the lines quickly become blurred.  Especially
when the edits are pulling in code from elsewhere.

> 4 files changed, 85 insertions(+), 48 deletions(-)
> Makefile                           | 35 ++++++++++++++-----
> Makefile.end                       | 26 +++++++++-----
> Makefile.inc                       |  2 +-
> Makefile.internal => Makefile.main | 70 ++++++++++++++++++++++----------------
>
> Maybe that's not what some people would call "storing rename data", but
> it works for me!