Re: [git-users] git merge -- resolving conflicts?
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?
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?
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?
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?
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