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] undoing git init?

[Pablo Rodríguez]

On 08/15/2016 10:58 AM, Magnus Therning wrote:
> Pablo Rodríguez writes:
> 
>> Dear list,
>>
>> I wanted to initialize a git repo in a directory, but I mistakenly
>> reinitialized an existing repo in another directory.
>>
>> Two basic questions:
>>
>> - How can I undo this? (All files from this repo have been removed [as
>> anyone should expect].)
>>
>> - If there were some uncommited modifications in the now deleted files,
>> would it be a way to recover also these modifications?
>>
>> Many thanks for your help,
> 
> I think it would help to know what exact commands you ran, and have an
> example of what you want to undo.
> 
> My quick testing suggests that the man page for git-init is correct when
> it states that
> 
>   Running git init in an existing repository is safe. It will not
>   overwrite things that are already there.

Hi Magnus,

after writing my original message, I checked git init in a brand new
repository and I realized that I deleted the files myself (assuming I
was working on a different repository).

It was all my fault. Next time I will move to trash instead of delete
files. (I copied directories, because it was the fastest way of doing it.)

Many thanks for your help,


Pablo
-- 
http://www.ousia.tk

-- 
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] undoing git init?

[Pablo Rodríguez]

On 08/13/2016 08:47 AM, Gabby Romano wrote:
> The parent git repo didn't recognise the action you did there? If it
> did, you may try working with tour try to recover the files.in
> general,redoing git init is deleting the .git folder...

Hi Gabby,

after practising with a brand new repository, I realized that I also
removed the files myself (thinking I was doing it in a different
repository).

The problem was that I didn’t realize in which directory (and which git
repo) I was working.

Many thanks for your help,


Pablo
-- 
http://www.ousia.tk

-- 
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] undoing git init?

[Magnus Therning]

Pablo Rodríguez  writes:

> Dear list,
>
> I wanted to initialize a git repo in a directory, but I mistakenly
> reinitialized an existing repo in another directory.
>
> Two basic questions:
>
> - How can I undo this? (All files from this repo have been removed [as
> anyone should expect].)
>
> - If there were some uncommited modifications in the now deleted files,
> would it be a way to recover also these modifications?
>
> Many thanks for your help,

I think it would help to know what exact commands you ran, and have an
example of what you want to undo.

My quick testing suggests that the man page for git-init is correct when
it states that

  Running git init in an existing repository is safe. It will not
  overwrite things that are already there.

/M

-- 
Magnus Therning  OpenPGP: 0x927912051716CE39
email: mag...@therning.org   jabber: mag...@therning.org
twitter: magthe   http://therning.org/magnus

If our ideas of intellectual property are wrong, we must change them,
improve them and return them to their original purpose. When
intellectual property rules diminish the supply of new ideas, they
steal from all of us.
 — Andrew Brown, November 19, 2005, The Guardian

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


signature.asc
Description: PGP signature