Live data from Hacker News

What is in that .git directory?

blog.meain.io

1–10 of 47 posts

Re: What is in that .git directory?

#2
If you'd like a more in-depth treatment of the topic, let me suggest chapter 10 of the git book:

https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Po...

> But what gets sent to the other git repo? It is everything that is in objects and under refs.

Not everything under refs. Just the refs that you push. What gets pushed depends on how you configure git, what arguments you provide to `git push` and how the refspecs are configured for the remote under `.git/config`:

https://git-scm.com/book/en/v2/Git-Internals-The-Refspec

e.g., I regularly use `git push origin +HEAD:develop` to force push the checked out branch to a destination branch named `develop`.

A couple additional points not mentioned:

There are also tag objects. You create these with `git tag -a`. These are also called annotated tags. They carry their own message and point to a commit. Without `-a` you create a so-called lightweight tag which is just an entry under `refs/tags` pointing directly to a commit (as opposed to pointing to a tag object).

https://git-scm.com/docs/git-tag

All those loose objects get packed up into pack files periodically to save space and improve git's speed. You can manually run `git gc` but git will do so for you automatically every so many commits. You'll find the pack files under `.git/objects/pack`:

https://git-scm.com/book/en/v2/Git-Internals-Packfiles

Re: What is in that .git directory?

#3
By 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 that "delta compression" message when you commit is about^2. The 51Gb file though I don't have an explanation for as of yet, I'm guessing something terrible happened before I joined, and people didn't find the courage to forego the history just yet. But at least I got an entertaining read out of it.

^1: https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Po...

^2: https://git-scm.com/book/en/v2/Git-Internals-Packfiles

Re: What is in that .git directory?

#4

By 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…

Unpack the files (git-unpack). Maybe it was one large file that someone added, then deleted in a later commit. You'd have to rewrite history to get rid of it entirely. Alternately it might be a bunch of medium sized files that were added and removed. It may take a little while to track down, but I'd start by unpacking.

This stack-overflow looks like it contains a reasonable description about how to rewrite history to remove objects:

https://stackoverflow.com/questions/11050265/remove-large-pa...

It might be easier to declare repo bankruptcy. Seed a new repo from the existing repo's source files. Have the commit message point to the old repo. Stop using the old repo. Yes, you lose history and folks trying to perform repo archeology will have to jump to the old repo.

But rewriting history to remove large files can be equally as awful since references to git commit IDs tend to end up in places you don't expect and when you rewrite history, you change the commit IDs.

Good luck.

Re: What is in that .git directory?

#5
post #4

By 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…

Unpack the files (git-unpack). Maybe it was one large file that someone added, then deleted in a later commit. You'd have to rewrite history to get rid of it entirely. Alternately it might be a bunch of medium sized files that were added and removed. It may take a little while to track down, but I'd start by unpacking. This stack-overflow looks like it contains a reasonable description about how to rewrite history to…

Thanks! Yeah I plan to get to the bottom of it. I will probably propose to just keep a branch with full history somewhere (we need to keep history for auditability) and reset the main branch from a recent state.

Re: What is in that .git directory?

#6
post #4

Earlier quoted context omitted.

Unpack the files (git-unpack). Maybe it was one large file that someone added, then deleted in a later commit. You'd have to rewrite history to get rid of it entirely. Alternately it might be a bunch of medium sized files that were added and removed. It may take a little while to track down, but I'd start by unpacking. This stack-overflow looks like it contains a reasonable description about how to rewrite history to…

Thanks! Yeah I plan to get to the bottom of it. I will probably propose to just keep a branch with full history somewhere (we need to keep history for auditability) and reset the main branch from a recent state.

That won't shrink the repo. Any reference will keep all the objects alive and they all get packed together. If you only care about reducing clone size see this post:

https://github.blog/2020-12-21-get-up-to-speed-with-partial-...

To be clear, I was not suggesting deleting the old repo. Keep it for historical purposes, whether you rewrite or start fresh.

Re: What is in that .git directory?

#7
post #4

Earlier quoted context omitted.

Unpack the files (git-unpack). Maybe it was one large file that someone added, then deleted in a later commit. You'd have to rewrite history to get rid of it entirely. Alternately it might be a bunch of medium sized files that were added and removed. It may take a little while to track down, but I'd start by unpacking. This stack-overflow looks like it contains a reasonable description about how to rewrite history to…

Thanks! Yeah I plan to get to the bottom of it. I will probably propose to just keep a branch with full history somewhere (we need to keep history for auditability) and reset the main branch from a recent state.

If it helps, I wrote a very long and detailed blog post several years ago about the techniques I used to rewrite my team's Git repo history (including stripping out junk files, _and_ actually rewriting source file contents via formatting and codemods for _old_ commits):

https://blog.isquaredsoftware.com/2018/11/git-js-history-rew...

I specifically was looking for techniques that would let me quickly iterate over ~15000 commits.

granted, the repo size I was working with was only a few GB, but hopefully there's some pieces there you can find useful.

Post reply on HN