[flagged]
What is in that .git directory?
11–20 of 47 posts
Re: What is in that .git directory?
#12[flagged]
sqlite? god please no
sqlite is great when everything is working as designed, but breaks completely on any badness.
The file-based git approach is on the other hand is incredibly resilent - and "resilent" is exactly what I want from my version control system.
For example, I sync all my computers, including .git dirs, with unison. And sadly, I am not a perfect human being, so I often generate conflicts (like make different commits on same branch in same git checkout and thentry to sync this using file-based sync tool). And git survives such abuse and just works. It also survives partially deleted files, bad transfers.. sometimes you need to dig a bit, but you can recover it.
Re: What is in that .git directory?
#13[flagged]
Does that break things like cherry-pick ? I’m intrigued.
Re: What is in that .git directory?
#14[flagged]
sqlite? god please no sqlite is great when everything is working as designed, but breaks completely on any badness. The file-based git approach is on the other hand is incredibly resilent - and "resilent" is exactly what I want from my version control system. For example, I sync all my computers, including .git dirs, with unison. And sadly, I am not a perfect human being, so I often generate conflicts (like make diff…
Did you get that backwards?
sqlite is a proper database that actually tests its resilience.
Just because you can't sync a sqlite file, that doesn't mean it isn't resilient it just means you need to back it up via pushing to another repo or using the backup command. Syncing by just copying files over while a disk is still being used is fragile in general.
Re: What is in that .git directory?
#15[flagged]
[deleted]
Re: What is in that .git directory?
#16On the same topic, I usually refer back to this fantastic talk on how to add and commit a file without using git add or git commit: https://www.youtube.com/watch?v=mdvlu_R8EWE
Re: What is in that .git directory?
#17By random chance I ended up in the git internals doc^1 today, also lovely refered to as plumbing and porcelain. It's a fantastic read, very well explained. I wish all doc was written with such explicit care to be understood. It reads like a good friend is trying to explain you something. What got me into that was a 51Gb ".pack" file that I wanted to understand. If you wonder about that, they're pack files, and what t…
Check the git verify-pack subcommand, particularly the -s and -v flags.
Re: What is in that .git directory?
#18Earlier quoted context omitted.
sqlite? god please no sqlite is great when everything is working as designed, but breaks completely on any badness. The file-based git approach is on the other hand is incredibly resilent - and "resilent" is exactly what I want from my version control system. For example, I sync all my computers, including .git dirs, with unison. And sadly, I am not a perfect human being, so I often generate conflicts (like make diff…
Did you get that backwards? sqlite is a proper database that actually tests its resilience. Just because you can't sync a sqlite file, that doesn't mean it isn't resilient it just means you need to back it up via pushing to another repo or using the backup command. Syncing by just copying files over while a disk is still being used is fragile in general.
No, they didn't get it backwards.
Testing is great for resilience, but "content files generally only get added, not modified or deleted" is even better.
Copying files around may be fragile but people want to do it and get lots of value out of it.
Re: What is in that .git directory?
#19Earlier quoted context omitted.
sqlite? god please no sqlite is great when everything is working as designed, but breaks completely on any badness. The file-based git approach is on the other hand is incredibly resilent - and "resilent" is exactly what I want from my version control system. For example, I sync all my computers, including .git dirs, with unison. And sadly, I am not a perfect human being, so I often generate conflicts (like make diff…
Did you get that backwards? sqlite is a proper database that actually tests its resilience. Just because you can't sync a sqlite file, that doesn't mean it isn't resilient it just means you need to back it up via pushing to another repo or using the backup command. Syncing by just copying files over while a disk is still being used is fragile in general.
have you seen sqlite official documentation on corruption resistance? https://www.sqlite.org/howtocorrupt.html
supported failure modes, tested and handled:
"application crash, or an operating-system crash, or even a power failure" - so basically proper atomic renames. git does this well.
unsupported failure modes:
"Backup or restore while a transaction is active" - when you backup your machine, do you really treat each sqlite specially? I know I don't.
"Deleting a hot journal" - or, you know, downloading database file and forgetting to grab journal at the same time
"Multiple links to the same file" - did you ever hardlink or bind-mounted a database file? prepare for corruption...
-----
Don't get me wrong, it takes some skill to implement proper safe file handling, and a random person off the street would be better off with sqlite.
But git specifically took the effort and designed the system so that the database is resilent in all sort of crazy conditions, and even if not, it's easy to recover. Switching git to sqlite would be all downside, no upside.
Re: What is in that .git directory?
#20Nice post, thanks for sharing! I found that another way to learn about Git internals is following a very step by step re-implementation of Git. It really was a very cool and efficient way for me to understand what's in the .git repository.
See for example the ugit [1] "build Git from scratch in Python" series for that.