On Sun, 3 Mar 2013 15:16:46 -0800 (PST) Tom Green <tomgreen1...@gmail.com> wrote:
>>>> I did a GIT STASH (working in Windows command line). Now I >>>> can't restore from it >>>> I get the message: >>>> TECHNOTE/git.TXT: needs merge >>>> unable to refresh index [...] > Thanks again, and for some reason -- not sure exactly what did it -- > the files are back in my working directory. So my problem is > resolved, but I would still like to understand. Anyhow, the urgency > is gone. You're right, I'm new to GIT, so I'm not offended by > anything. > I did a GIT STATUS and saw the same file as unmerged. It said that I > needed to resolve conflicts, but I didn't understand how to do that. > I'm not sure if this did it, but I edit the file and removed the > lines with "<<<<<<< Updated upstream" and ">>>>>>> Stashed changes" > and saved it. Okay, that "">>>>>>> Stashed changes" line provides the necessary clue so I think I'm able to reconstruct what have happened. Application of a stash record might result in conflicts. This is to be expected: if you have checked out some commit A (usually this is a tip of a branch), did some local changes on top of it, stashed them, then checked out some other commit B and then attempted to apply the stash record made against the files of that commit A, the `git stash` machinery will have to apply the stashed changes to a different set of files with their contents quite possibly different compared to the set of files of that commit A, against which the stashed changes have been recorded. By now you could probably see that if both the commit B and your stashed changes changed the same piece(s) of a file as recorded in the commit A, an attempt to apply those stashed changes to that file as recorded in the commit B will result in a conflict. Note that bringing the commit B into the work tree might not necessarely result from checking out another branch or something like this -- you might as well just record a number of commits on top of that base commit A, moving the tip of the current branch forward. So that is what most probably have happened. You stashed your local changes, checked out some other branch or recorded a number of commits (thus moving the current branch forward) then applied the stashed changes which *did* work but resulted in conflicts. Since you are seemingly not familiar with merging conflicts and their resolution, you ignored the message from `git stash` about conflicts. The next time you tried to apply the same stash record `git stash` noticed you had merge conflicts in the index and refused to proceed without even trying. Now let's debunk how merge conflicts are handled by Git... > - Does GIT look for the ">>>>>>>" markers in the file to see if I > resolved the conflict? > - Or does it somehow check the file date? No to both questions. It's actually simpler. When Git detects a conflict while merging a file, it records this fact in the index entry for that particular file. This special kind of entry actually refers to the versions of both "sides" of merging, known as "ours" and "theirs" -- referring to the base version of the file and its version which was attempted to be merged. (This, by the way, allows to easily replace the contents of a file with conflicts in the work tree using `git checkout --ours -- <filename>` and `git checkout --theirs ...`, respectively.) Git also replaces each conflicting chunk in the file with the chunks from the both sides of the merge, and decorates them with the conflict markers. To resolve conflicts for a file, you must do two things, in this order: 1) Actually resolve the conflicts. This either means fixing the file, replacing each conflicting part with the correct text (obviously, the conflict markers should be removed as well) or just overwriting the file with the version beleived to be correct (see above). 2) Stage the updated content of the file for the next commit by just `git add`-ing it. This simply replaces the special "in conflict" index entry for that file with a "normal" entry. Repeat for each file with conflicts until `git status` shows you that everything is okay. Of course, not having formal conflicts in the index does not mean your data is correct. I mean, after resolving merge conflicts you might have to ensure the state of your code is sensible (by running a test suite or similar means). [...] > Also, another stupid question: > - Does the term INDEX refer to what GIT-GUI calls STAGED CHANGES? Yes. The term "staging area" is used to refer to the index as this is the place where the changes are staged for the next commit. Note that "the cache" was another (earlier) term used to refer to the index. The remnants of this might be seen in some git commands, like `git diff --cached` to see the diff between the HEAD and the index and `git rm --cached` for removing entries from the index and not from the work tree etc. > The top of my tree (from GITK) looked roughly like this. > > * Local uncommitted changes > * STASH > * Saving GIT.TXT so I can un-stash > | * STASH WIP on Master... Commit xyz (I don'r remmeber doing > | this) / > | * index on master 090ecd0 Commit xyz > | / > * Commit xyz > | Yes, a stash record is not just a dumb patchset. Each stash record saves both the staged changes (what's in the index compared to the HEAD) and the local unstaged changes (what's in the work tree compared to the index). So each stash record is represented with two commits; here they are those "index on master 090ecd0 ..." and "WIP on Master ..." commits. To round up... Your main problem seems to be lack of general knowledge about how to operate a VCS system (and Git in general): knowing how to deal with merge conflicts is crucial. Hence consider reading some introductory material on the topic. The "Pro Git" book, freely available online [1] is usually the first recommendation. [2] lists more choices. And please, next time you report a problem, care to provide as must information on it as possible -- this would save e-mail roundtrips. Another hint is that if you need really quick help, consider asking on the Git IRC channel instead [3]. 1. http://www.git-scm.com/book 2. http://www.git-scm.com/documentation 3. http://www.git-scm.com/community -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
