[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.

[marcosdumay]

Yet, it's wrong.

Just the fact that people keep using placeholder files should be enough to convince anybody. But if you want to use git for software development, well, almost all development conventions mandate directory intentionally kept empty or to exist before their contents exist. I've never seen anybody decide on something that doesn't.

[pif]

> almost all development conventions mandate directory intentionally kept empty or to exist before their contents exist

Never heard about this, nor can I imagine what purpose it could serve.

[BlueTemplar]

As an aside, aren't folders in *nix also files ? So how did this happen with git, written by Linus ??

[thwarted]

Object stores like S3 work similarly, the entire path is to an object, and unless there is data at a path, the path doesn't exist. And you don't need to create the prefix before storing something with that prefix. That the tooling abstracts that a way to make it look more like a filesystem is a layer on top.

[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.