Re: [PATCH 0/2] Respecting core.autocrlf when showing objects
- From
- J. Bruce Fields <bfields@fieldses.org>
- Date
- Jun 12, 2008, 19:55 UTC
- Message-ID
- <20080612195553.GK13626@fieldses.org>
- In-Reply-To
- <7vtzfy8n4i.fsf@gitster.siamese.dyndns.org>
On Thu, Jun 12, 2008 at 12:33:01PM -0700, Junio C Hamano wrote:
Show 28 quoted lines
> Marius Storm-Olsen <marius@trolltech.com> writes: > > > Johannes Schindelin said the following on 11.06.2008 21:06: > >> On Wed, 11 Jun 2008, Marius Storm-Olsen wrote: > >>> 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.txt > >> > >> This 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-resolution > > Bruce, 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.
Show 36 quoted lines
> > 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