![]() But they all got copied into the index first! 3 So the frozen-form files are there, ready to go into the next commit. The frozen (and compressed and Git-only) files came out of the commit, and got expanded into useful form in your work-tree. So when you git checkout some commit, Git fills in your work-tree with unfrozen (and de-compressed and otherwise de-Git-ified) copies of all of your files. Whatever is different in those two commits, those are the changes.įiles that are frozen for all time are great for archival, but useless for getting any new work done. For instance, suppose you compare the latest commit to the second-latest. They do not hold changes to files! To see changes, you must compare one commit to some other commit. The fundamental nature of Git is that it is all about commits. This frozen copy came out of the current commit. The way this works is that the index holds a copy of-well, really, a reference to-a frozen, ready-to-commit version of each of your files. What I like to say about the index, to summarize it in a nutshell, is that it holds the next commit you plan to make. So the index, the staging area, or the cache all refer to the same thing-which is mostly a file inside the. While a lot of Git calls it the index, other Git documentation calls it the staging area-which refers to how you use it-and some really old parts of Git leave a trace where the same thing is sometimes called the cache. Let's start with this: there are actually three different terms for this thing. So let's take a brief look at what exactly the index is. But without a good clear definition of what "the index" actually is in the first place, knowing this isn't much help. You will have to throw away this merge commit, in some way or another.Ī conflicted merge means that Git's index has taken on an expanded role. Unfortunately, using git add to resolve conflicts is almost irreversible-I'll go more into the "almost" part in a bit-and a subsequent git commit makes it completely irreversible. ![]() It's the git add -u step (or its equivalent, really) that caused the problem: that declared to Git that all conflicts were resolved, after which you could commit. git commit -a is loosely 1 the same as git add -u git commit.You literally cannot commit while you have unresolved merge conflicts. ![]() Retrospectively, that sounds like a bad idea. I was trying to commit the resolved conflicts and leave the unresolved ones to a colleague of mine. What I'm going to write about here is what really happened, and why: For a TL DR see David Sugar's answer: you must throw out, or at least stop using, the merge commit you made. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |