-<p>where the first argument is going to be used as the commit message if\r
-the merge can be resolved automatically.</p>\r
-<p>Now, in this case we've intentionally created a situation where the\r
-merge will need to be fixed up by hand, though, so git will do as much\r
-of it as it can automatically (which in this case is just merge the <tt>example</tt>\r
-file, which had no differences in the <tt>mybranch</tt> branch), and say:</p>\r
-<div class="listingblock">\r
-<div class="content">\r
-<pre><tt> Trying really trivial in-index merge...\r
- fatal: Merge requires file-level merging\r
- Nope.\r
- ...\r
- Auto-merging hello\r
- CONFLICT (content): Merge conflict in hello\r
- Automatic merge failed/prevented; fix up by hand</tt></pre>\r
-</div></div>\r
-<p>which is way too verbose, but it basically tells you that it failed the\r
-really trivial merge ("Simple merge") and did an "Automatic merge"\r
-instead, but that too failed due to conflicts in <tt>hello</tt>.</p>\r
-<p>Not to worry. It left the (trivial) conflict in <tt>hello</tt> in the same form you\r
-should already be well used to if you've ever used CVS, so let's just\r
-open <tt>hello</tt> in our editor (whatever that may be), and fix it up somehow.\r
-I'd suggest just making it so that <tt>hello</tt> contains all four lines:</p>\r
-<div class="listingblock">\r
-<div class="content">\r
-<pre><tt>Hello World\r
-It's a new day for git\r
-Play, play, play\r
-Work, work, work</tt></pre>\r
-</div></div>\r
-<p>and once you're happy with your manual merge, just do a</p>\r
-<div class="listingblock">\r
-<div class="content">\r
-<pre><tt>$ git commit hello</tt></pre>\r
-</div></div>\r
-<p>which will very loudly warn you that you're now committing a merge\r
-(which is correct, so never mind), and you can write a small merge\r
-message about your adventures in git-merge-land.</p>\r
-<p>After you're done, start up <tt>gitk --all</tt> to see graphically what the\r
-history looks like. Notice that <tt>mybranch</tt> still exists, and you can\r
-switch to it, and continue to work with it if you want to. The\r
-<tt>mybranch</tt> branch will not contain the merge, but next time you merge it\r
-from the <tt>master</tt> branch, git will know how you merged it, so you'll not\r
-have to do _that_ merge again.</p>\r
-<p>Another useful tool, especially if you do not always work in X-Window\r
-environment, is <tt>git show-branch</tt>.</p>\r
-<div class="listingblock">\r
-<div class="content">\r
-<pre><tt>$ git show-branch master mybranch\r
-* [master] Merge work in mybranch\r
- ! [mybranch] Some work.\r
---\r
-+ [master] Merge work in mybranch\r
-++ [mybranch] Some work.</tt></pre>\r
-</div></div>\r
-<p>The first two lines indicate that it is showing the two branches\r
-and the first line of the commit log message from their\r
-top-of-the-tree commits, you are currently on <tt>master</tt> branch\r
-(notice the asterisk <tt>*</tt> character), and the first column for\r
-the later output lines is used to show commits contained in the\r
-<tt>master</tt> branch, and the second column for the <tt>mybranch</tt>\r
-branch. Three commits are shown along with their log messages.\r
-All of them have plus <tt>+</tt> characters in the first column, which\r
-means they are now part of the <tt>master</tt> branch. Only the "Some\r
-work" commit has the plus <tt>+</tt> character in the second column,\r
-because <tt>mybranch</tt> has not been merged to incorporate these\r
-commits from the master branch. The string inside brackets\r
-before the commit log message is a short name you can use to\r
-name the commit. In the above example, <em>master</em> and <em>mybranch</em>\r
-are branch heads. <em>master~1</em> is the first parent of <em>master</em>\r
-branch head. Please see <em>git-rev-parse</em> documentation if you\r
-see more complex cases.</p>\r
-<p>Now, let's pretend you are the one who did all the work in\r
-<tt>mybranch</tt>, and the fruit of your hard work has finally been merged\r
-to the <tt>master</tt> branch. Let's go back to <tt>mybranch</tt>, and run\r
-resolve to get the "upstream changes" back to your branch.</p>\r
-<div class="listingblock">\r
-<div class="content">\r
-<pre><tt>$ git checkout mybranch\r
-$ git merge "Merge upstream changes." HEAD master</tt></pre>\r
-</div></div>\r
-<p>This outputs something like this (the actual commit object names\r
-would be different)</p>\r
-<div class="listingblock">\r
-<div class="content">\r
-<pre><tt>Updating from ae3a2da... to a80b4aa....\r
- example | 1 +\r
- hello | 1 +\r
- 2 files changed, 2 insertions(+), 0 deletions(-)</tt></pre>\r
-</div></div>\r
-<p>Because your branch did not contain anything more than what are\r
-already merged into the <tt>master</tt> branch, the resolve operation did\r
-not actually do a merge. Instead, it just updated the top of\r
-the tree of your branch to that of the <tt>master</tt> branch. This is\r
-often called <em>fast forward</em> merge.</p>\r
-<p>You can run <tt>gitk --all</tt> again to see how the commit ancestry\r
-looks like, or run <tt>show-branch</tt>, which tells you this.</p>\r
-<div class="listingblock">\r
-<div class="content">\r
-<pre><tt>$ git show-branch master mybranch\r
-! [master] Merge work in mybranch\r
- * [mybranch] Merge work in mybranch\r
---\r
-++ [master] Merge work in mybranch</tt></pre>\r
-</div></div>\r
-</div>\r
-<h2>Merging external work</h2>\r
-<div class="sectionbody">\r
-<p>It's usually much more common that you merge with somebody else than\r
-merging with your own branches, so it's worth pointing out that git\r
-makes that very easy too, and in fact, it's not that different from\r
-doing a <tt>git merge</tt>. In fact, a remote merge ends up being nothing\r
-more than "fetch the work from a remote repository into a temporary tag"\r
-followed by a <tt>git merge</tt>.</p>\r
-<p>Fetching from a remote repository is done by, unsurprisingly,\r
-<tt>git fetch</tt>:</p>\r
-<div class="listingblock">\r
-<div class="content">\r
-<pre><tt>$ git fetch <remote-repository></tt></pre>\r
-</div></div>\r
-<p>One of the following transports can be used to name the\r
-repository to download from:</p>\r
-<dl>\r
-<dt>\r
-Rsync\r
-</dt>\r
-<dd>\r
-<p>\r
- <tt>rsync://remote.machine/path/to/repo.git/</tt>\r
-</p>\r
-<p>Rsync transport is usable for both uploading and downloading,\r
-but is completely unaware of what git does, and can produce\r
-unexpected results when you download from the public repository\r
-while the repository owner is uploading into it via <tt>rsync</tt>\r
-transport. Most notably, it could update the files under\r
-<tt>refs/</tt> which holds the object name of the topmost commits\r
-before uploading the files in <tt>objects/</tt> — the downloader would\r
-obtain head commit object name while that object itself is still\r
-not available in the repository. For this reason, it is\r
-considered deprecated.</p>\r
-</dd>\r
-<dt>\r
-SSH\r
-</dt>\r
-<dd>\r
-<p>\r
- <tt>remote.machine:/path/to/repo.git/</tt> or\r
-</p>\r
-<p><tt>ssh://remote.machine/path/to/repo.git/</tt></p>\r
-<p>This transport can be used for both uploading and downloading,\r
-and requires you to have a log-in privilege over <tt>ssh</tt> to the\r
-remote machine. It finds out the set of objects the other side\r
-lacks by exchanging the head commits both ends have and\r
-transfers (close to) minimum set of objects. It is by far the\r
-most efficient way to exchange git objects between repositories.</p>\r
-</dd>\r
-<dt>\r
-Local directory\r
-</dt>\r
-<dd>\r
-<p>\r
- <tt>/path/to/repo.git/</tt>\r
-</p>\r
-<p>This transport is the same as SSH transport but uses <tt>sh</tt> to run\r
-both ends on the local machine instead of running other end on\r
-the remote machine via <tt>ssh</tt>.</p>\r
-</dd>\r
-<dt>\r
-git Native\r
-</dt>\r
-<dd>\r
-<p>\r
- <tt>git://remote.machine/path/to/repo.git/</tt>\r
-</p>\r
-<p>This transport was designed for anonymous downloading. Like SSH\r
-transport, it finds out the set of objects the downstream side\r
-lacks and transfers (close to) minimum set of objects.</p>\r
-</dd>\r
-<dt>\r
-HTTP(S)\r
-</dt>\r
-<dd>\r
-<p>\r
- <tt>http://remote.machine/path/to/repo.git/</tt>\r
-</p>\r
-<p>Downloader from http and https URL\r
-first obtains the topmost commit object name from the remote site\r
-by looking at the specified refname under <tt>repo.git/refs/</tt> directory,\r
-and then tries to obtain the\r
-commit object by downloading from <tt>repo.git/objects/xx/xxx...</tt>\r
-using the object name of that commit object. Then it reads the\r
-commit object to find out its parent commits and the associate\r
-tree object; it repeats this process until it gets all the\r
-necessary objects. Because of this behaviour, they are\r
-sometimes also called <em>commit walkers</em>.</p>\r
-<p>The <em>commit walkers</em> are sometimes also called <em>dumb\r
-transports</em>, because they do not require any git aware smart\r
-server like git Native transport does. Any stock HTTP server\r
-that does not even support directory index would suffice. But\r
-you must prepare your repository with <tt>git-update-server-info</tt>\r
-to help dumb transport downloaders.</p>\r
-<p>There are (confusingly enough) <tt>git-ssh-fetch</tt> and <tt>git-ssh-upload</tt>\r
-programs, which are <em>commit walkers</em>; they outlived their\r
-usefulness when git Native and SSH transports were introduced,\r
-and not used by <tt>git pull</tt> or <tt>git push</tt> scripts.</p>\r
-</dd>\r
-</dl>\r
-<p>Once you fetch from the remote repository, you <tt>resolve</tt> that\r
-with your current branch.</p>\r
-<p>However — it's such a common thing to <tt>fetch</tt> and then\r
-immediately <tt>resolve</tt>, that it's called <tt>git pull</tt>, and you can\r
-simply do</p>\r
-<div class="listingblock">\r
-<div class="content">\r
-<pre><tt>$ git pull <remote-repository></tt></pre>\r
-</div></div>\r
-<p>and optionally give a branch-name for the remote end as a second\r
-argument.</p>\r
-<div class="admonitionblock">\r
-<table><tr>\r
-<td class="icon">\r
-<div class="title">Note</div>\r
-</td>\r
-<td class="content">You could do without using any branches at all, by\r
-keeping as many local repositories as you would like to have\r
-branches, and merging between them with <tt>git pull</tt>, just like\r
-you merge between branches. The advantage of this approach is\r
-that it lets you keep set of files for each <tt>branch</tt> checked\r
-out and you may find it easier to switch back and forth if you\r
-juggle multiple lines of development simultaneously. Of\r
-course, you will pay the price of more disk usage to hold\r
-multiple working trees, but disk space is cheap these days.</td>\r
-</tr></table>\r
-</div>\r
-<div class="admonitionblock">\r
-<table><tr>\r
-<td class="icon">\r
-<div class="title">Note</div>\r
-</td>\r
-<td class="content">You could even pull from your own repository by\r
-giving <em>.</em> as <remote-repository> parameter to <tt>git pull</tt>. This\r
-is useful when you want to merge a local branch (or more, if you\r
-are making an Octopus) into the current branch.</td>\r
-</tr></table>\r
-</div>\r
-<p>It is likely that you will be pulling from the same remote\r
-repository from time to time. As a short hand, you can store\r
-the remote repository URL in a file under .git/remotes/\r
-directory, like this:</p>\r