11–20 of 36 posts
Earlier quoted context omitted.
The former, until you run git gc, in which case the latter happens.
Wow! Running git gc just shrunk my .git folder from 18MB to only 3MB.
Earlier quoted context omitted.
Wow! Running git gc just shrunk my .git folder from 18MB to only 3MB.
did it have binary data? if so try moving to lfs and running bfg cleaner and watch it shrink even more
Nice walkthrough! I did not know about FETCH_HEAD. Another (complementing) way of getting an idea how Git works is by reading the source of Isomorphic Git[0]. Being in JS and with fewer (as of now) features, it’s a bit more accessible than reference Git. [0] E.g. https://github.com/isomorphic-git/isomorphic-git/blob/main/s...
A dumb question: if I make a commit changing just a single line in a large file, does this create a completely new object/blob with the entire contents of the file? Or does it store it in a more space-efficient manner?
The former, until you run git gc, in which case the latter happens.
In particular I'm thinking of the case where there's an append-only file keeping a log, to commit the changes every so often without having to make a blob copy of the file first (which may be relatively large)?
Earlier quoted context omitted.
did it have binary data? if so try moving to lfs and running bfg cleaner and watch it shrink even more
No binary data. Just an ordinary git repo with a bunch of source code files (mostly C and Lua).
Earlier quoted context omitted.
Wow! Running git gc just shrunk my .git folder from 18MB to only 3MB.
git gc runs automatically when some threshold is met in the number of "loose" objects (objects that were created by e.g. git add and that haven't been packed yet). I don't remember what the threshold is, though.
Earlier quoted context omitted.
The former, until you run git gc, in which case the latter happens.
Do you know if there's an easy way to do this without running git gc? Say by just supplying a diff or something? In particular I'm thinking of the case where there's an append-only file keeping a log, to commit the changes every so often without having to make a blob copy of the file first (which may be relatively large)?
The closest would be to create a pack manually that contains a diff against the previous version but that'd require manual work.
It would be possible, for example, to modify git-fast-import to a) allow to take diffs as input b) allow to store those diffs (these are different things to deal with). The downside is that the more packs there are, the slower object lookup is, which can make everything much slower. Newer versions of git have cross-pack indexes to deal with that, though, but I don't think that's enabled by default.
Another option would be to add a new format for loose objects that allows to store diffs, but that has backwards compatibility implications.
This was really really educational. Git internals seem rather simple. Does anyone have a really good visual explanation of what's being done to the tree and such when commits and merges and rebases are done? I still don't quite grok it intimately enough.
[0] https://sransara.com/notes/2019/build-yourself-a-git/ [1] https://en.wikipedia.org/wiki/Directed_acyclic_graph [2] https://en.wikipedia.org/wiki/Persistent_data_structure
Earlier quoted context omitted.
The former, until you run git gc, in which case the latter happens.
Do you know if there's an easy way to do this without running git gc? Say by just supplying a diff or something? In particular I'm thinking of the case where there's an append-only file keeping a log, to commit the changes every so often without having to make a blob copy of the file first (which may be relatively large)?