git/list[1] front-page[2] threads[3] people[4] search[5] about
 

[PATCH 2/2 v2] user-manual: Document that "git merge" doesn't like uncommited changes.

From
Matthieu Moy <matthieu.moy@imag.fr>
Date
Nov 22, 2009, 22:26 UTC
Message-ID
<1258928778-32419-2-git-send-email-Matthieu.Moy@imag.fr>
In-Reply-To
<1258732767-12741-1-git-send-email-Matthieu.Moy@imag.fr>

We explain the user why uncommited changes can be problematic with merge, and point to "commit" and "stash" for the solution. While talking about commited Vs uncommited changes, we also make it clear that the result of a merge is normally commited.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
 Documentation/user-manual.txt |   20 ++++++++++++++++++--
 1 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 269ec47..c09f4b2 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1183,7 +1183,23 @@ $ git merge branchname
 -------------------------------------------------
 
 merges the development in the branch "branchname" into the current
-branch.  If there are conflicts--for example, if the same file is
+branch.
+
+A merge is made by combining the changes made in "branchname" and the
+changes made up to the latest commit in your current branch since
+their histories forked. The work tree is overwritten by the result of
+the merge when this combining is done cleanly, or overwritten by a
+half-merged results when this combining results in conflicts.
+Therefore, if you have uncommitted changes touching the same files as
+the ones impacted by the merge, Git will refuse to proceed. Most of
+the time, you will want to commit your changes before you can merge,
+and if you don't, then linkgit:git-stash[1] can take these changes
+away while you're doing the merge, and reapply them afterwards.
+
+If the changes are independant enough, Git will automatically complete
+the merge and commit the result (or reuse an existing commit in case
+of <<fast-forwards,fast-forward>>, see below). On the other hand,
+if there are conflicts--for example, if the same file is
 modified in two different ways in the remote branch and the local
 branch--then you are warned; the output may look something like this:
 
@@ -1679,7 +1695,7 @@ Sharing development with others
 Getting updates with git pull
 -----------------------------
 
-After you clone a repository and make a few changes of your own, you
+After you clone a repository and commit a few changes of your own, you
 may wish to check the original repository for updates and merge them
 into your own work.
 
-- 
1.6.5.3.435.g5f2e3.dirty
Previous: Matthieu MoyNext: Junio C Hamano
Message 11 of 12 in “Explain newbies the "commit before pull" flow”
  1. 0/2 Explain newbies the "commit before pull" flowMatthieu Moy, Nov 20, 2009
  2. 1/2 merge-recursive: point the user to commit when file would be overwritten.Matthieu Moy, Nov 20, 2009
  3. Junio C HamanoNov 20, 2009
  4. Matthieu MoyNov 22, 2009
  5. 2/2 user-manual: Document that "git merge" doesn't like uncommited changes.Matthieu Moy, Nov 20, 2009
  6. Junio C HamanoNov 20, 2009
  7. Matthieu MoyNov 22, 2009
  8. Junio C HamanoNov 22, 2009
  9. Matthieu MoyNov 23, 2009
  10. 1/2 merge-recursive: point the user to commit when file would be overwritten.Matthieu Moy, Nov 22, 2009
  11. 2/2 user-manual: Document that "git merge" doesn't like uncommited changes.Matthieu Moy, Nov 22, 2009
  12. Junio C HamanoNov 23, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.