On 2016-08-16, at 5:53 AM, Konstantin Khomoutov <flatw...@users.sourceforge.net> wrote:
> 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 >> >> 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: > > | :<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 > > 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 resolved cleanly, and is "in progress", has not completed; so a command that is specialized for cleaning up unfinished merges makes sense. Of all the git commands, a command that cleans up merges on a file by file basis is closer to "git merge" (clean up a merge on a tree by tree basis) than to any other command. --- 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.
