![]() ![]() It makes two commits, or sometimes three. The git stash command itself, when it makes a stash, really just makes some commits. So: having staged some files really means making new, pre-de-duplicated copies and replacing the old pre-de-duplicated index copies with the new ones. If they're all-new, committing now will add one all-new file (technically, one all-new blob object) to the repository's object database. The other files, that you updated with git add, are also pre-de-duplicated: if they match any committed file anywhere in the repository, committing now will re-use the old file. ![]() It's just that some of them still match the existing committed files: they're pre-de-duplicated duplicates. In fact, though, Git's index / staging-area has every file in it. Once the index copy of some file is different from the committed copy, Git starts calling that file staged for commit. (So was the old one: it's just that it matched the copy from the commit you checked out!) This replaces the old copy that was in the index / staging-area. Git reads your working tree copy of the file, and compresses and de-duplicates it to turn it into the Git-only format, and drops that into the cache. When you run git add, what Git does replace the cached index copies. They still match the old committed copies, because they're not yet changed. Initially, the cached copies here exactly match the commit you checked out.Īs you work on the working tree, the cached index copies get out of sync with the working tree copies. These are in what Git calls, variously, the index, or the staging area, or-rarely these days-the cache. Instead, Git keeps all of the Git-ized files from the last commit. When you make a new commit, Git will have to re-Git-ize all the files, and this process would be very slow, so Git doesn't just do it over again. They are copies, made from those files but the files inside the Git repository are in a different, Git-only format. ![]() The working tree files are not the ones that are inside the Git repository. You do your work here, in your working tree. Git calls this area, with the usable files that you can work on and with, your working tree. Git uses the names database to find the big ugly hash ID of that particular commit, then uses the archive inside that commit to populate a working tree full of usable files. This is what git checkout or the new (since Git 2.23) git switch is for: you tell Git get me the latest master commit or get me the latest develop commit. Or rather, you can't use it until you first have Git un-archive it, to turn its saved archive back into ordinary files. What all this means is that you cannot actually use any commit. To make this archive not use up all your disk space quickly, the stored files inside commits are in a special, read-only, Git-only, compressed and de-duplicated form. And, each commit stores a full archive of every file. Nothing about any commit can ever change, once you make the commit. With all that in mind, remember also that every commit is completely, totally, 100% read-only. Commits themselves store the commit numbers of other commits, so once we find some particularly interesting commit-such as the latest master or develop commit, for instance-we can use that commit to find other interesting commits but we need the hash ID of that one particular commit, to get started. Each commit is numbered, with a unique (and big and ugly) hash ID that appears random, so we need some mechanism to find particularly interesting commits, such as the most recent commit for some branch. The names are mostly used to find the commits. One holds all the commits and other internal Git objects, and the other holds names: branch names, tag names, and other such names. The main bulk of a Git repository consists of two databases. Before I get to the next steps, though, I want to describe exactly what this all means. I wrote some code, staged it I wanted to do commit. There's no automated way to get back what you had. The short answer is that you may have to do a lot of work, or just a little work. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |