5 ms·

> 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 ver

> 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 3y ago
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-empty-directory-to-a-git-repository https://stackoverflow.com/questions/115983/how-do-i-add-an-e...
- nereye 3y ago
  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 https://portal.perforce.com/s/article/3447 for Perforce.
  - marcosdumay 3y ago
    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.
    - thwarted 3y ago
      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.
    - pif 3y ago
      > 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 3y ago
        As an aside, aren't folders in *nix also files ? So how did this happen with git, written by Linus ??
DinaCoder99 3y ago
> 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.
Pet_Ant 3y ago
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 3y ago
  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 3y ago
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.

jankovicsandras 3y ago

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-empty-directory-to-a-git-repository https://stackoverflow.com/questions/115983/how-do-i-add-an-e...

nereye 3y ago
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 https://portal.perforce.com/s/article/3447 for Perforce.
- marcosdumay 3y ago
  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.
  - thwarted 3y ago
    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.
  - pif 3y ago
    > 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 3y ago
      As an aside, aren't folders in *nix also files ? So how did this happen with git, written by Linus ??

DinaCoder99 3y ago

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

Pet_Ant 3y ago

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 3y ago
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 3y ago

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.