Re: [git-users] git merge -- resolving conflicts?

[Michael]

On 2016-08-16, at 5:53 AM, Konstantin Khomoutov 
 wrote:

> On Mon, 15 Aug 2016 12:16:46 -0700
> Michael  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
>> 
>> 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
> correct.
> 
> 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:
> 
> | ::, 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
> 
> and
> 
>  $ 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
> them.
> 
> 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.

Ok. So, 
1. Looking at a conflicting file with three entries in the conflict section. 
The middle is the "common ancestor". There is a "top" and a "bottom". One of 
these is selected by "-X ours", and the other is selected by "-X theirs". Which 
is which?

2. If I do "git merge --abort", and then want to say "git merge ", I can do 
"git merge -X ours", or "git merge -X theirs", and get the merge where there 
are no conflicts, and the us or them hunks when there is a conflict. That's 
good for the small cases, where there's only one or two conflicts that resolve 
cleanly.

But how would I, in a large merge that does not have such a clean solution, say 
"Merge this file with -X ours, merge that file with -X theirs, leave this other 
file -- poem.txt -- unchanged because I have to manually edit all 4 lines (But 
still give me all three variants), and this other file has some hunks for 
"ours", some hunks for "theirs", so this one file needs to be run in the 3-way 
editor?

3. You say that a merge that leaves a conflict is already completed, so trying 
to re-run merge makes no sense. To me, a merge that has not 

Re: [git-users] git merge -- resolving conflicts?

[Konstantin Khomoutov]

On Mon, 15 Aug 2016 12:16:46 -0700
Michael  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
correct.

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:

| ::, 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

and

  $ 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
them.

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.

Re: [git-users] git merge -- resolving conflicts?

[Michael]

On 2016-08-15, at 7:16 AM, Konstantin Khomoutov 
 wrote:

> On Sat, 13 Aug 2016 18:15:17 -0700
> Michael_google gmail_Gersten  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
>>>  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".

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

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

---
Entertaining minecraft videos
http://YouTube.com/keybounce

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

Re: [git-users] git merge -- resolving conflicts?

[Konstantin Khomoutov]

On Sat, 13 Aug 2016 18:15:17 -0700
Michael_google gmail_Gersten  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
> >  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.

Re: [git-users] git merge -- resolving conflicts?

[Philip Oakley]

From: "Michael_google gmail_Gersten" 

On Fri, Jul 29, 2016 at 12:02 PM, Konstantin Khomoutov
 wrote:


On Fri, 29 Jul 2016 09:10:06 -0700
Michael  wrote:

> After doing a "git merge", I wind up with a few conflicts.
>
> My files have the three states.
>
> I am finding that I almost always want the third state (between ===
> and >>>) to resolve these conflicts.
>
> How can I tell merge, AFTER seeing the conflicts, and looking at
> them, to use the third option for resolution?
>
> To clarify: I'm not asking for the third state in all cases. I'm not
> asking for those files to replace everything else (that's what I
> understand the "--ours" option does). I'm not asking to do this on
> the initial merge command before I've seen what the conflicts are
> going to turn out to be.
>
> 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
 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?

Also: Why "ours" and "theirs"? Which one is which? I'm one person with
multiple branches.

--

Quick comment:

There is a difference between a merge STRATEGY and the strategy OPTIONS. 
This can be confusing, and I can't say I have my head fully around it, but 
do have a re-read of the merge manual page with that in mind.


There is,essentially, an "Ours/Theirs" in both.

Philip
--
(though one of the merge 'theirs', IIRC for the whole tree, was removed as 
being 'nonesense' a while ago) 


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

Re: [git-users] git merge -- resolving conflicts?

[Michael_google gmail_Gersten]

On Fri, Jul 29, 2016 at 12:02 PM, Konstantin Khomoutov
 wrote:
>
> On Fri, 29 Jul 2016 09:10:06 -0700
> Michael  wrote:
>
> > After doing a "git merge", I wind up with a few conflicts.
> >
> > My files have the three states.
> >
> > I am finding that I almost always want the third state (between ===
> > and >>>) to resolve these conflicts.
> >
> > How can I tell merge, AFTER seeing the conflicts, and looking at
> > them, to use the third option for resolution?
> >
> > To clarify: I'm not asking for the third state in all cases. I'm not
> > asking for those files to replace everything else (that's what I
> > understand the "--ours" option does). I'm not asking to do this on
> > the initial merge command before I've seen what the conflicts are
> > going to turn out to be.
> >
> > 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
>  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?

Also: Why "ours" and "theirs"? Which one is which? I'm one person with
multiple branches.

-- 
This message may have been spell checked by a laptop kitten.

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

Re: [git-users] git merge -- resolving conflicts?

[Konstantin Khomoutov]

On Fri, 29 Jul 2016 09:10:06 -0700
Michael  wrote:

> After doing a "git merge", I wind up with a few conflicts.
> 
> My files have the three states.
> 
> I am finding that I almost always want the third state (between ===
> and >>>) to resolve these conflicts.
> 
> How can I tell merge, AFTER seeing the conflicts, and looking at
> them, to use the third option for resolution?
> 
> To clarify: I'm not asking for the third state in all cases. I'm not
> asking for those files to replace everything else (that's what I
> understand the "--ours" option does). I'm not asking to do this on
> the initial merge command before I've seen what the conflicts are
> going to turn out to be.
> 
> 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
 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.

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

[git-users] git merge -- resolving conflicts?

[Michael]

After doing a "git merge", I wind up with a few conflicts.

My files have the three states.

I am finding that I almost always want the third state (between === and >>>) to 
resolve these conflicts.

How can I tell merge, AFTER seeing the conflicts, and looking at them, to use 
the third option for resolution?

To clarify: I'm not asking for the third state in all cases. I'm not asking for 
those files to replace everything else (that's what I understand the "--ours" 
option does). I'm not asking to do this on the initial merge command before 
I've seen what the conflicts are going to turn out to be.

After I've done the "git merge" and it has failed, how can I then auto-select 
on a file by file basis?

---
Entertaining minecraft videos
http://YouTube.com/keybounce

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