The ones you make Git shut up about are your ignored files. Last-well, almost last-given any untracked file-which by definition isn't in the index- git status will complain about it being untracked, unless you use an "ignore" file to make it shut up. ![]() Anything that is different is interesting: git status tells you not staged for commit, because you could update the index copy of the file (or remove it) to match the work-tree, after which it might not match the current commit any more. Index vs work-tree: anything that is the same is boring and git status says nothing. Anything that is different is interesting: git status tells you staged for commit, because if you ran git commit right now, the new commit you would make would be different from the current commit. HEAD vs index: anything that is the same is boring git status says nothing about that. To see what's different, you must have Git compare: The work-tree copy is there or not: Git does not really care, because Git will use the index copy for the next commit. The index copy is either there, so that the file is tracked, or not there, so that the file is untracked. Whatever you do, the HEAD copy of the file never changes. use various other Git commands, such as git rm -cached or special forms of git checkout that are now easier in Git 2.23+ via the new git restore, toĪchieve other manipulations of the index and/or work-tree.use (one form of) git reset to copy a file from the HEAD to the index without touching the work-tree and/or.use git rm to remove a file from both the index and the work-tree: now it's gone from both.use git add to copy a work-tree file into the index: now the two match, and if the file was not in the index at all before, now it is in the index.modify (or create or remove) a work-tree file however you like.There's the unchangeable copy in the HEAD commit, which has been copied into the index, which has been copied into your work-tree. The effect is that right after git checkout, all three copies of every tracked file match. None of your untracked files are touched here, only the tracked ones. So now all the index copies match all the work-tree copies. Meanwhile, this same git checkout also removes from your work-tree all the tracked files from the commit you had out a moment ago, and replaces them with the files from the index that are from the new HEAD commit. 1 So now HEAD, which is the commit you just checked out, and the index match. When you first git checkout some commit-each commit is uniquely specified by its big ugly hash ID, so that you can check out old ones if you like-Git reads the commit's files into the index, so that all the committed files are there and no other files are there. ![]() If the work-tree copy of a tracked file is missing, it looks deleted, as compared to the (not-deleted) index copy. It's in your computer's ordinary format, so you can do anything you like with this copy. This is the only version of the file that you can see with your ordinary computer tools. It too is in the special internal Git format for files (a "blob object", in Git terms) but for your own purposes you can just think of it as a whole separate physical copy, because you can, at any time, overwrite it with a new copy, or remove it. Technically this is really a reference to a copy somewhere else. It's in a special Git-only format and is quite tricky to find: you have to have Git extract it into a usable form. The HEAD copy of the file, like any committed copy of any file, is read-only. If there is no HEAD copy, the file is new: it will be an added file in the next commit, as compared to the current commit. There is the HEAD (current commit) copy, which is where the file came from initially. Remember that at all times, there are, in effect, three active copies of a tracked file, though two of them can be missing: (It's more complicated than that-because the index has a few additional roles-but that's the short version.) A new git commit simply packages up the files that are in the index to make the snapshot for the new commit. The index is also perhaps best described as what will go into the next commit. An untracked file is, by definition, a file that is not in the index, but is in your work-tree-the area in which you do your everyday work. At the same time, only untracked files can be ignored. In Git, tracked simply means is present in the index. Git ls-files can show you what's in the index, but it's not very user friendly. ![]() There is one thing that's missing, which is a quick and easy way to see the special flags that you can set in the index. If a file isn't showing up, and you think it might be ignored, git check-ignore -v is useful: it will tell you why the file is ignored, if it is ignored, or say nothing if it's not ignored. Basically, git status is Git's best attempt to tell you everything at once.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |