Re: [PATCH 0/2] Respecting core.autocrlf when showing objects
From: J. Bruce Fields <hidden>
Date: 2016-06-15 22:44:44
Possibly related (same subject, not in this thread)
- 2016-06-15 · Re: [PATCH 0/2] Respecting core.autocrlf when showing objects · Marius Storm-Olsen <hidden>
- 2016-06-15 · Re: [PATCH 0/2] Respecting core.autocrlf when showing objects · Junio C Hamano <hidden>
- 2016-06-15 · Re: [PATCH 0/2] Respecting core.autocrlf when showing objects · Jon Loeliger <hidden>
- 2016-06-15 · [PATCH 0/2] Respecting core.autocrlf when showing objects · Marius Storm-Olsen <hidden>
- 2016-06-15 · Re: [PATCH 0/2] Respecting core.autocrlf when showing objects · Johannes Schindelin <hidden>
On Thu, Jun 12, 2008 at 12:33:01PM -0700, Junio C Hamano wrote:
Marius Storm-Olsen [off-list ref] writes:quoted
Johannes Schindelin said the following on 11.06.2008 21:06:quoted
On Wed, 11 Jun 2008, Marius Storm-Olsen wrote:quoted
Well, consider this: Say you are merging two branches, and know that you want to just use the parts which conflict from the branch being merged in. Then you simply do: git merge side git show :3:file.txt > file.txtThis is not really how I would do things. I would do git checkout side file.txt here.Uhm, 'git checkout side file.txt' is not the same file content (ignoring EOLs please) as 'git show :3:file.txt'. Ref: user-manual.html#conflict-resolutionBruce, I think the comment in this quoted section is wrong. True, the combined diff can show only the interesting differences between the three, but that is not because we munge stage #2 and #3. They contain verbatim copies from the HEAD and the MERGE_HEAD respectively, and the combining logic runs three-way diffs between the three stages to discard the hunks that the result comes solely from either stage #2 or stage #3.
Oops, thanks for catching that! I don't know how I got the idea it worked that way. (Is there any advantage, then, to the :n:filename syntax to a user? Is it useful in any cases when they couldn't use HEAD or MERGE_HEAD instead? If not I might be tempted to cut this bit entirely (or postpone it till later.) --b.
quoted hunk ↗ jump to hunk
So perhaps something like this is in order... --- Documentation/user-manual.txt | 15 +++++++-------- 1 files changed, 7 insertions(+), 8 deletions(-)diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index bfde507..64a820b 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt@@ -1254,16 +1254,15 @@ these three "file stages" represents a different version of the file: ------------------------------------------------- $ git show :1:file.txt # the file in a common ancestor of both branches -$ git show :2:file.txt # the version from HEAD, but including any - # nonconflicting changes from MERGE_HEAD -$ git show :3:file.txt # the version from MERGE_HEAD, but including any - # nonconflicting changes from HEAD. +$ git show :2:file.txt # the version from HEAD. +$ git show :3:file.txt # the version from MERGE_HEAD. ------------------------------------------------- -Since the stage 2 and stage 3 versions have already been updated with -nonconflicting changes, the only remaining differences between them are -the important ones; thus linkgit:git-diff[1] can use the information in -the index to show only those conflicts. +When you ask linkgit:git-diff[1] to show the conflicts, it runs a +three-way diff between the conflicted merge results in the work tree with +stages 2 and 3 to show only hunks whose contents come from both sides, +mixed (in other words, when a hunk's merge results come only from stage 2, +that part is not conflicting and is not shown. Same for stage 3). The diff above shows the differences between the working-tree version of file.txt and the stage 2 and stage 3 versions. So instead of preceding