From: "J. Bruce Fields" <bfields@citi.umich.edu>
To: Junio C Hamano <junkio@cox.net>
Cc: git@vger.kernel.org, "J. Bruce Fields" <bfields@citi.umich.edu>
Subject: [PATCH] user-manual: more detailed merge discussion
Date: Sun, 4 Mar 2007 16:59:15 -0500 [thread overview]
Message-ID: <11730455601849-git-send-email-bfields@citi.umich.edu> (raw)
In-Reply-To: <11730455602463-git-send-email-bfields@citi.umich.edu>
From: J. Bruce Fields <bfields@citi.umich.edu>
Add more details on conflict, including brief discussion of file stages.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
---
Documentation/user-manual.txt | 102 +++++++++++++++++++++++++++++++----------
1 files changed, 77 insertions(+), 25 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 907f122..ffd673e 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1168,18 +1168,46 @@ the working tree in a special state that gives you all the
information you need to help resolve the merge.
Files with conflicts are marked specially in the index, so until you
-resolve the problem and update the index, git commit will fail:
+resolve the problem and update the index, gitlink:git-commit[1] will
+fail:
-------------------------------------------------
$ git commit
file.txt: needs merge
-------------------------------------------------
-Also, git status will list those files as "unmerged".
+Also, gitlink:git-status[1] will list those files as "unmerged", and the
+files with conflicts will have conflict markers added, like this:
+
+-------------------------------------------------
+<<<<<<< HEAD:file.txt
+Hello world
+=======
+Goodbye
+>>>>>>> 77976da35a11db4580b80ae27e8d65caf5208086:file.txt
+-------------------------------------------------
+
+All you need to do is edit the files to resolve the conflicts, and then
+
+-------------------------------------------------
+$ git add file.txt
+$ git commit
+-------------------------------------------------
+
+Note that the commit message will already be filled in for you with
+some information about the merge. Normally you can just use this
+default message unchanged, but you may add additional commentary of
+your own if desired.
+
+The above is all you need to know to resolve a simple merge. But git
+also provides more information to help resolve conflicts:
+
+Getting conflict-resolution help during a merge
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
All of the changes that git was able to merge automatically are
already added to the index file, so gitlink:git-diff[1] shows only
-the conflicts. Also, it uses a somewhat unusual syntax:
+the conflicts. It uses an unusual syntax:
-------------------------------------------------
$ git diff
@@ -1200,14 +1228,32 @@ conflict will have two parents instead of the usual one: one parent
will be HEAD, the tip of the current branch; the other will be the
tip of the other branch, which is stored temporarily in MERGE_HEAD.
-The diff above shows the differences between the working-tree version
-of file.txt and two previous versions: one version from HEAD, and one
-from MERGE_HEAD. So instead of preceding each line by a single "+"
-or "-", it now uses two columns: the first column is used for
-differences between the first parent and the working directory copy,
-and the second for differences between the second parent and the
-working directory copy. Thus after resolving the conflict in the
-obvious way, the diff will look like:
+During the merge, the index holds three versions of each file. Each of
+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.
+-------------------------------------------------
+
+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 gitlink:git-diff[1] can use the information in
+the index to show only those conflicts.
+
+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
+each line by a single "+" or "-", it now uses two columns: the first
+column is used for differences between the first parent and the working
+directory copy, and the second for differences between the second parent
+and the working directory copy. (See the "COMBINED DIFF FORMAT" section
+of gitlink:git-diff-files[1] for a details of the format.)
+
+After resolving the conflict in the obvious way (but before updating the
+index), the diff will look like:
-------------------------------------------------
$ git diff
@@ -1225,26 +1271,37 @@ This shows that our resolved version deleted "Hello world" from the
first parent, deleted "Goodbye" from the second parent, and added
"Goodbye world", which was previously absent from both.
-The gitlink:git-log[1] command also provides special help for merges:
+Some special diff options allow diffing the working directory against
+any of these stages:
+
+-------------------------------------------------
+$ git diff -1 file.txt # diff against stage 1
+$ git diff --base file.txt # same as the above
+$ git diff -2 file.txt # diff against stage 2
+$ git diff --ours file.txt # same as the above
+$ git diff -3 file.txt # diff against stage 3
+$ git diff --theirs file.txt # same as the above.
+-------------------------------------------------
+
+The gitlink:git-log[1] and gitk[1] commands also provide special help
+for merges:
-------------------------------------------------
$ git log --merge
+$ gitk --merge
-------------------------------------------------
-This will list all commits which exist only on HEAD or on MERGE_HEAD,
-and which touch an unmerged file.
+These will display all commits which exist only on HEAD or on
+MERGE_HEAD, and which touch an unmerged file.
-We can now add the resolved version to the index and commit:
+Each time you resolve the conflicts in a file and update the index:
-------------------------------------------------
$ git add file.txt
-$ git commit
-------------------------------------------------
-Note that the commit message will already be filled in for you with
-some information about the merge. Normally you can just use this
-default message unchanged, but you may add additional commentary of
-your own if desired.
+the different stages of that file will be "collapsed", after which
+git-diff will (by default) no longer show diffs for that file.
[[undoing-a-merge]]
undoing a merge
@@ -2988,11 +3045,6 @@ provides.
Simplify beginning by suggesting disconnected head instead of
temporary branch creation?
-Explain how to refer to file stages in the "how to resolve a merge"
-section: diff -1, -2, -3, --ours, --theirs :1:/path notation. The
-"git ls-files --unmerged --stage" thing is sorta useful too,
-actually. And note gitk --merge.
-
Add more good examples. Entire sections of just cookbook examples
might be a good idea; maybe make an "advanced examples" section a
standard end-of-chapter section?
--
1.5.0.gb75812-dirty
next prev parent reply other threads:[~2007-03-04 22:08 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-04 21:59 Documentation (mostly user manual) patches J. Bruce Fields
2007-03-04 21:59 ` [PATCH] Documentation: mention module option to git-cvsimport J. Bruce Fields
2007-03-04 21:59 ` [PATCH] user-manual: reset to ORIG_HEAD not HEAD to undo merge J. Bruce Fields
2007-03-04 21:59 ` [PATCH] user-manual: ensure generated manual references stylesheet J. Bruce Fields
2007-03-04 21:59 ` [PATCH] user-manual: insert earlier of mention content-addressable architecture J. Bruce Fields
2007-03-04 21:59 ` [PATCH] user-manual: how to replace commits older than most recent J. Bruce Fields
2007-03-04 21:59 ` J. Bruce Fields [this message]
2007-03-04 21:59 ` [PATCH] glossary: Add definitions for dangling and unreachable objects J. Bruce Fields
2007-03-05 0:45 ` Yasushi SHOJI
2007-03-16 12:44 ` [PATCH] user-manual: ensure generated manual references stylesheet Robert Pluim
2007-03-16 14:24 ` J. Bruce Fields
[not found] ` <7C0AC446-57CA-480B-A14E-1E861E2FCBA7@silverinsanity.com>
2007-03-16 15:36 ` J. Bruce Fields
[not found] ` <7DA766E4-D88F-4248-BD29-1E0B403BF0BE@silverinsanity.com>
2007-03-16 17:02 ` J. Bruce Fields
2007-03-05 3:14 ` Documentation (mostly user manual) patches Junio C Hamano
2007-03-05 18:38 ` J. Bruce Fields
2007-03-11 4:35 ` J. Bruce Fields
2007-03-11 4:35 ` [PATCH 1/6] glossary: fix overoptimistic automatic linking of defined terms J. Bruce Fields
2007-03-11 4:35 ` [PATCH 2/6] user-manual: fix inconsistent example J. Bruce Fields
2007-03-11 4:35 ` [PATCH 3/6] user-manual: fix inconsistent use of pull and merge J. Bruce Fields
2007-03-11 4:35 ` [PATCH 4/6] user-manual: fix missing colon in git-show example J. Bruce Fields
2007-03-11 4:35 ` [PATCH 5/6] user-manual: fix rendering of history diagrams J. Bruce Fields
2007-03-11 4:35 ` [PATCH 6/6] user-manual: install user manual stylesheet with other web documents J. Bruce Fields
2007-03-11 4:39 ` [PATCH 2/6] user-manual: fix inconsistent example J. Bruce Fields
2007-03-13 19:31 ` Ramsay Jones
2007-03-14 23:19 ` J. Bruce Fields
2007-03-11 5:35 ` Documentation (mostly user manual) patches Junio C Hamano
2007-03-07 20:19 ` Ramsay Jones
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=11730455601849-git-send-email-bfields@citi.umich.edu \
--to=bfields@citi.umich.edu \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).