Sublime sidebar folders/files not refreshing on git checkout?

Question

When I create/delete a folder or file in one of my branches, and then checkout another branch, the updates aren't reflected in my folders, however they are reflected on my site. I'm using sftp for sublime and for some reason I can't seem to get the sidebar to update new file changes when I checkout other branches. Anyone have any ideas to get this working?

Answer 1

TL;DR: you must git add the file and then git commit the updated index.

(This is based on comments above.)

If you created a file in the work-tree, but have not git add-ed the file, that's an untracked file. The precise definition of untracked file is a file that is not in the index. The index is also called the staging area since it's where you update (i.e., stage) the files for the next commit you will make. The git add step copies the file into the index, ready for the next git commit to commit it. You have to finish this process with the git commit (well, you have to finish it eventually—you can wait, if you like, and copy more files into the index, or even overwrite the one you just copied in).

Git leaves untracked files alone, at least as much as it can. As long as the file is untracked (is not in the index) you can switch branches all you like and the file just sits there.

Once you add and commit the file, it becomes an ordinary file in that commit, just like every other file in that commit. The git commit step simply packages up every file that is in the index, in the form it has in the index right when you run git commit, and makes that into a new, read-only (completely),¹ permanent (mostly),² commit.

Note that when you change an existing work-tree file, the older version is still in the index (if it's in there at at all, i.e., if the file is tracked). You still have to git add modified-file to copy the updated version into the index. That's why Git is constantly forcing you to git add everything: you must first copy it into the index, even if there's already an older version in the index.

Checking out any existing commit fills the index and work-tree with the files from that commit. Checking out some other commit will remove, from the index and work-tree, any files that were in your previous checked-out commit but are not in your new checked-out commit. (Note that in some cases, you can carry un-committed changes around in your index and work-tree while switching branches, but sometimes you can't do this. The details are kind of messy.)

Hence, after running git add new-file and git commit while on branch feature-A, doing git checkout feature-B will switch you from the new commit, which has the file (it's in the index → tracked, and in the work-tree → visible) to your existing older commit on feature-B. The older commit doesn't have the new file, so it comes out of the index and Git removes it from your work-tree.

Note that now that the tip commit of feature-A has the file. If you are still on feature-B and you create the file and leave it untracked, it's just an untracked file. It's not in the index. You now can't git checkout feature-A because Git will have to overwrite your untracked file. You must remove it (so that it's not in the way) or add-and-commit it (so that it's tracked and clean) so that Git can blow away that copy and replace it with the copy from feature-A.

(Exercise: when you do check out the commit from feature-A, will the file that was new back then, be in the index?)

---

¹Every object stored inside a Git repository is always completely read-only. There are four object types: commit, tree, blob, and annotated tag. The two you will see most directly are commit and blob: commit objects hold your commits, and blob objects hold your file data.

²Commits stick around as long as you can find them. A branch name like master identifies one particular commit, and that commit finds its parent. The parent commit finds its own parent, which finds yet another parent, and so on. In general, in Git, you will add new commits without ever forgetting / abandoning the old ones, by the simple method of having the new commit remember, as its parent, whichever commit was the latest on some branch before then. The branch name will then just identify the newest commit.

Every once in a while you find that some commit was terrible and should be forgotten. As long as you haven't given that commit to someone else, you can simply adjust your branch names and other existing commits to forget or abandon the one you don't like. Forgotten / abandoned commit IDs get saved in a side log called a reflog, for a while. Eventually the reflog entries expire, and only then will Git really reclaim the commit. The reflog entries live for at least 30 days by default, so you have up to a month to change your mind and get a commit back, after abandoning it.

This all means that commits are mostly permanent. They are not 100% guaranteed permanent, but they won't be lost by accident. Since they're also read-only, this means that your historical files, which are saved in these commits, are available to you forever.