On Mon, 15 Aug 2016 12:16:46 -0700
Michael <keybou...@gmail.com> wrote:

> >> Also: Why "ours" and "theirs"? Which one is which? I'm one person
> >> with multiple branches.
> > 
> > Well, sure it's a bit philosophical because there are different
> > ways to _look_ at what a merge is.  To explain the meaning of these
> > terms, consider that merging is reconciling two (or more) lines of
> > history. In a classic case, merging is used to introduce someone
> > else's changes into our own developments.  Sure, that someone else
> > can perfectly be you yourself but that does not change much -- read
> > on. ;-) Consider that merging -- no matter which strategy is used
> > -- always has the single "receiving" state: this is what checked
> > out into your work tree.  This commit (HEAD points at it) will be
> > recorded as the so-called "first parent" of the merge commit.  Now
> > look at it this way: we have some state, currently checked out,
> > which is "our work", and typically what we're merging is "their
> > work".  So that's what these names mean: "ours" is the side which
> > receives the merge while "theirs" is the side which is being merged
> > (integrated) into "ours".
> Fair enough. Can you explain it terms of the three sets of changes?
> Git puts the original in the middle, and then an "above" and a
> "below". Which of "above" and "below" is "ours" and "theirs"?

Quite close.  Git uses different terminology but you got the essense

When a merge conflict is detected for a file, Git:

1) Updates the entry for that file in the index to make it contain
   several so-called "stages":
   0) "Ours" version -- that one which was there in this index entry
      before we begun to merge.
   1) The version fron the common ancestor commit.
   2) The version from HEAD.
   3) The version being merged.

2) Updates the file in the work tree to contain conflict markers and the
   conflicting chunks of text between them (and the text from the common
   ancestor if the "diff3" style of conflict markers was set).

To cite the `gitrevisions` manual page:

| :<n>:<path>, e.g. :0:README, :README
|     A colon, optionally followed by a stage number (0 to 3) and
| a colon, followed by a path, names a blob object in the index at the
| given path. A missing stage number (and the colon that follows it)
| names a stage 0 entry. During a merge, stage 1 is the common ancestor,
| stage 2 is the target branch’s version (typically the current branch),
| and stage 3 is the version from the branch which is being merged.

So when the merge resulted in conflicts, for each unmerged entry you
can fetch its different stages, like in

  $ git show :3:path/to/my/file/with/conflict


  $ git checkout :2:path/to/my/file/with/conflict

The "--ours" and "--theirs" command-line options are human-friendly
shortcuts to not make you memorize the most common stage numbers and
using them directly.

So if we're talking about the tree trees, the first one (HEAD) is not
touched if there was a conflict, the index is updated in a special way
and the work tree is updated in a special way as well.

To resolve a conflict you run any commands you wish which update the
index entry for the file constituting that conflict.  However you do
that is up to you -- you could use `git reset` or `git add`.

This makes sense because a commit is always cut from the index.
So if merging failed to complete, you need to put the index in the form
ready to be committed.

> Also, can I do
> >  $ git merge -s recursive -X ours
> after starting a merge? i.e. -- if I find that there are conflicts,
> and I look at them with git diff, can I use this after starting, to
> resolve? (Git merge normally tells me that there is a merge in
> progress).

This has no sense.  `git merge` performs the merge, and once it
completed, there's no sense to run it again because the merge was
already happened (with the index and the work tree updated and a
special ref MERGE_HEAD created -- waiting for the next commit to
happen to get picked up).  If there are conflicts, you need to resolve

On the other hand, it's possible to run `git merge --abort` and re-try
it with different options controlling the strategy and its parameters.

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/d/optout.

Reply via email to