4 ms·
If the file was ever staged with `git add`, it'll be in the git object store (note, git doesn't have a cache, it maintains a whole repo) as a blob until the nex
by GrantMoyer 2y ago
If the file was ever staged with `git add`, it'll be in the git object store (note, git doesn't have a cache, it maintains a whole repo) as a blob until the next GC run, otherwise you're out of luck.
Even if it's in the object store though, it may be hard to find; if it was never commited, it was only ever referenced by the index, and now it's completely unrereferenced. Maybe you could enumerate all unreachable blobs, diff them with the current version of the file, and manually review all the blobs where the diff size is below some threshold.
- JohnMakin 2y ago> (note, git doesn't have a cache, it maintains a whole repo) ? not sure what you mean here, git definitely has a local cache. There is even a command like git rm --cached. Maybe we're getting into semantics nitpicking here, I'm talking about the file under .git/ that contains the staging area
- GrantMoyer 2y agoOh I see, I thought you were refering to the local repo as a cache of some central repo, which is a mistake I've often heard. The file you're refering to is the index; it's a list of git object IDs which make up the current staged state. It only has metadata, the actual contents of staged files are stored in the object store as blobs. Honestly, I'm not sure why some commands use --cached to mean "with respect to the index". The index is not a cache in the common sense of the word. It doesn't mirror state stored elsewhere in the repo and it's the single source of truth for current staged state.
- kadoban 2y agoI think the name was changed at some point and the old options were just too engrained to bother with.
- GrantMoyer 2y agoI dug through the Git mailing list, and lo and behold, the whole project used to be called "dir-cache", and was initially intended as a local cache over any arbitrary slow version control systems[1]. It looks like this is where the cache terminology lingers from, but the index already had its current name by the time Linus released the git source code. It seems like there was an effort to clean up the terminology pre-1.0[2], but obviously some things were missed. [1]: https://lore.kernel.org/git/Pine.LNX.4.58.0508051104510.3258@g5.osdl.org/ https://lore.kernel.org/git/Pine.LNX.4.58.0508051104510.3258... [2]: https://lore.kernel.org/git/200509020150.j821oXXM006699@laptop11.inf.utfsm.cl/ https://lore.kernel.org/git/200509020150.j821oXXM006699@lapt...