[ickyforce]

> GIT is already best model for keeping history of textual changes

Git doesn't even keep history of changes, just snapshots before and after the changes. A very common problem is viewing history of a single file as it gets modified and renamed - this information just isn't stored. It's common for tools to show file history incorrectly - i.e. a previous version is removed and the new one (with small changes) magically appears.

[jankovicsandras]

This. Git is not an Edit history. Another surprising (at least to me) thing is that you can't add empty directories (without placeholder files) : https://stackoverflow.com/questions/115983/how-do-i-add-an-e...

[nereye]

This is not an uncommon behavior in source code control systems, e.g. both Perforce and Mercurial behave like Git too.

E.g. see https://portal.perforce.com/s/article/3447 for Perforce.

[Pet_Ant]

My pet peeve is that in enterprise development is that files grow into monsterous god objects: ten of thousands of lines long. There is no way to track that a single file was split into multiple files. They are all sucessors of it. When I go to a split of a file I want to see the history and blame of the method not just "brand new, created yesterday". This has led to the "pattern" of never moving anything because you will get blamed for it in the marginalia and it will be up to you to pull the old version and find the real author.

[jmholla]

Have you tried `tig`? I can't remember trying out exactly this, but I wouldn't be surprised if it has better support than `git` for this kind of thing?

[andrewla]

I would argue the reason that git is the answer going forward is that what you describe is a UX issue, not a data structure issue.

There's nothing stopping a UI tool from figuring out that a file was moved or split into multiple files -- it just has to do so from looking at the state before and the state after. Git has gotten better at this over the years and keeps improving, so newer versions of git will be able to look at existing git repositories and synthesize better views of the history.

[DinaCoder99]

> Git doesn't even keep history of changes, just snapshots before and after the changes.

This seems like splitting hairs given you can trivially derive one from the other.