StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>In addition, this <a href="http://git.661346.n2.nabble.com/how-do-you-review-auto-resolved-files-td7306131.html" rel="nofollow noreferrer">more recent thread (2012)</a> details the notion of "auto-resolution" with Git:</p> <blockquote> <p>My definition for "auto-resolve":<br> "During a merge, the working tree files are updated to reflect the result of the merge... When both sides made changes to different areas of the same file, git picks both sides automatically, and leaves its up to you to make sure you review those merge results for correctness after git has made the merge commit."</p> <p>IOW, an "auto-resolve" specifically means that both sides (ours and theirs) made changes to <code>file(a)</code> since the common-ancestor version of <code>file(a)</code>, and git picked both sides without raising a merge-conflict.<br> (The reason I came up with the term "auto-resolve" is because in the <code>git-merge</code> output the term "Auto-merging" can also indicate that only one side (theirs) changed <code>file(a)</code> since the common-ancestor and that git is just "fast-forwarding" theirs <code>file(a)</code> on top of common-ancestor <code>file(a)</code>.) </p> </blockquote> <p><a href="http://git.661346.n2.nabble.com/template/NamlServlet.jtp?macro=user_nodes&user=159550" rel="nofollow noreferrer">Junio C Hamano</a> raises in answer an important point:</p> <blockquote> <ul> <li>know <strong>git is stupid and errs on the safe side</strong>, punting anything remotely complex;</li> <li>know that textual non-conflicts that occur in the same file have the same risk of having semantic conflict across different files, so singling out "touched the same file but did not conflict" any special is pointless, but in either case, the chance of having such a conflict is small enough that completing the merge (and other merges) first and then checking the overall result is more efficient use of your time, because you have to eyeball the result at least once anyway before pushing it out. </li> </ul> </blockquote> <hr> <p>Update 5 and a half years later, May 2018 (Git 2.18, Q2 2018)</p> <p><strong>"<code>git mergetools</code>" learned talking to guiffy</strong>.</p> <p>See <a href="https://github.com/git/git/commit/6ceb658c9905cad2436810370c6590fc260a6b64" rel="nofollow noreferrer">commit 6ceb658</a> (05 Apr 2018) by <a href="https://github.com/" rel="nofollow noreferrer">Bill Ritcher (``)</a>.<br> <sup>(Merged by <a href="https://github.com/gitster" rel="nofollow noreferrer">Junio C Hamano -- <code>gitster</code> --</a> in <a href="https://github.com/git/git/commit/da36be5f08252cdcbfe37710990dea4c4025567a" rel="nofollow noreferrer">commit da36be5</a>, 25 Apr 2018)</sup> </p> <blockquote> <h2>mergetools: add support for <code>guiffy</code></h2> <p>Add <code>guiffy</code> as <code>difftool</code> and <code>mergetool</code>.</p> <p><code>guiffy</code> is available on Windows, Linux, and MacOS</p> </blockquote>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload