On Sat, 13 Aug 2016 18:15:17 -0700
Michael_google gmail_Gersten <keybou...@gmail.com> wrote:

> > > After I've done the "git merge" and it has failed, how can I then
> > > auto-select on a file by file basis?
> >
> > I think you want
> >
> >   $ git checkout --ours .
> >   $ git add -u
> >   $ git commit
> >
> > "The trick" is that `git checkout` working on files, and not given a
> > <tree-ish> argument to take contents from, uses the index, and for
> > unmerged entries, the index stores two versions of the entry's
> > content: theirs and ours.
> >
> > You might also use `git checkout --ours` on individual files, of
> > course.
> Here's what I cannot understand. I want the merged combination.
> I don't want "my" version of the file.
> I don't want "their" version of the file.
> I want the merge, and the conflict in this file resolved by "mine" or
> "theirs".
> What I see is this:
> 1. If I know that there is a conflict first, I can tell "git merge" to
> use "--ours" or "--theirs". But that's "resolve the conflict by taking
> my file / their file". No merging where there is no conflict. But
> since this is a "before doing merge", it is useless after you merge.
> 2. If I find a conflict afterwards, I can use "git checkout --ours" or
> "git checkout --theirs" to use the entire file. Again, no merging
> where there is no conflict.
> I am probably misunderstanding something.
> How can I keep all non-conflicting merges and still resolve the
> conflicting hunks?

OK, that's what Philip Oakley hinted at: the "recursive" merge strategy
has the "ours" strategy option.  To cite the documentation:

| The recursive strategy can take the following options:
| ours
|     This option forces conflicting hunks to be auto-resolved cleanly
| by favoring our version. Changes from the other tree that do not
| conflict with our side are reflected to the merge result. For a
| binary file, the entire contents are taken from our side.
| This should not be confused with the ours merge strategy, which does
| not even look at what the other tree contains at all. It discards
| everything the other tree did, declaring our history contains all
| that happened in it.

So doing

    $ git merge -s recursive -X ours

will auto-resolve any non-conflicting merges by actually recording the
merged state and in case of a conflict, it will pick the "ours" state
(see below).

> 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".

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