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

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

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.

Reply via email to