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

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

From
Matthieu Moy <matthieu.moy@imag.fr>
Date
Nov 20, 2009, 15:59 UTC
Message-ID
<1258732767-12741-3-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.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
 Documentation/user-manual.txt |   14 +++++++++++---
 1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 269ec47..6b4a037 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1176,14 +1176,22 @@ How to merge
 ------------
 
 You can rejoin two diverging branches of development using
-linkgit:git-merge[1]:
+linkgit:git-merge[1].
 
 -------------------------------------------------
 $ 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.  Note that Git merges committed changes, but not the working
+tree itself.  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 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 +1687,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 5 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.