4 ms·
The former, until you run git gc, in which case the latter happens.
by glandium 6y ago
The former, until you run git gc, in which case the latter happens.
- ufo 6y agoWow! Running git gc just shrunk my .git folder from 18MB to only 3MB.
- sitzkrieg 6y agodid it have binary data? if so try moving to lfs and running bfg cleaner and watch it shrink even more
- glandium 6y agogit 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.
- gwelps 6y agoDo 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)?
- fiddlerwoaroof 6y agoThis is sort of a worst-case scenario for git: there are patch-based DVCSes that would handle this scenario better (darcs and pijul), but those have their own set of trade offs (I think they end up being slower for large histories).
- pmeunier 6y agoApplying a patch in Darcs usued to be in O(2^n), and now apparently O(n^2), where n is the size of history. Applying a patch in Pijul is in O(p c log n), where p is the size of the patch and c the size of the largest "deletion-insertion conflict" p is involved in, where a "deletion-insertion conflict" is a situation where Alice deletes a block of text while Bob adds stuff in that same block. Note that this is a rough bound, since all non-conflicting operations in a patch are in O(log n), except those involved in a "deletion-insertion conflict", which are in O(c log n). So, Pijul is in fact faster than Git for merging (and rebasing). The only tradeoff at the moment is that going arbitrarily far back in history isn't as fast as it could be (this will be fixed very soon).
- fiddlerwoaroof 6y agoInteresting, I’ve been following these systems for a while, but I didn’t realize that pijul had solved the performance issues. Is pijul’s on-disk format stable yet?
- pmeunier 6y ago> Is pijul’s on-disk format stable yet? Probably. The patch format is very unlikely to change. The repository format may change a little bit still. I'd say it's probably ok to try and learn it now, but you should maybe wait for a few weeks before using it for something serious. On the other hand, we use it for itself, and I use it personally for most of my projects.
- globular-toast 6y agoEh? Why would git gc get rid of the old blob? It will still be referenced by the old commits.
- glandium 6y agoIt doesn't. It packs it.
- globular-toast 6y agoIs git gc the only thing that can trigger packing?
- auscompgeek 6y agoAnswered above: https://news.ycombinator.com/item?id=25540122 https://news.ycombinator.com/item?id=25540122
- glandium 6y agoThere is also git pack-objects and git repack.