given. Set it to <tt>always</tt> if you want this behavior when the\r
start-point is either a local or remote branch.\r
</p>\r
-<div class="para"><p>If no <em>-b</em> option was given, a name will be made up for you, by stripping\r
-the part up to the first slash of the tracked branch. For example, if you\r
-called <em>git checkout --track origin/next</em>, the branch name will be <em>next</em>.</p></div>\r
+<div class="para"><p>If no <em>-b</em> option was given, the name of the new branch will be\r
+derived from the remote branch, by attempting to guess the name\r
+of the branch on remote system. If "remotes/" or "refs/remotes/"\r
+are prefixed, it is stripped away, and then the part up to the\r
+next slash (which would be the nickname of the remote) is removed.\r
+This would tell us to use "hack" as the local branch when branching\r
+off of "origin/hack" (or "remotes/origin/hack", or even\r
+"refs/remotes/origin/hack"). If the given name has no slash, or the above\r
+guessing results in an empty name, the guessing is aborted. You can\r
+exlicitly give a name with <em>-b</em> in such a case.</p></div>\r
</dd>\r
<dt>\r
--no-track\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 2008-08-20 09:13:27 UTC\r
+Last updated 2008-08-24 03:33:55 UTC\r
</div>\r
</div>\r
</body>\r
given. Set it to `always` if you want this behavior when the
start-point is either a local or remote branch.
+
-If no '-b' option was given, a name will be made up for you, by stripping
-the part up to the first slash of the tracked branch. For example, if you
-called 'git checkout --track origin/next', the branch name will be 'next'.
+If no '-b' option was given, the name of the new branch will be
+derived from the remote branch, by attempting to guess the name
+of the branch on remote system. If "remotes/" or "refs/remotes/"
+are prefixed, it is stripped away, and then the part up to the
+next slash (which would be the nickname of the remote) is removed.
+This would tell us to use "hack" as the local branch when branching
+off of "origin/hack" (or "remotes/origin/hack", or even
+"refs/remotes/origin/hack"). If the given name has no slash, or the above
+guessing results in an empty name, the guessing is aborted. You can
+exlicitly give a name with '-b' in such a case.
--no-track::
Ignore the branch.autosetupmerge configuration variable.
</li>\r
<li>\r
<p>\r
-Resolve the conflicts. <tt>git diff</tt> would report only the\r
- conflicting paths because of the above 2. and 3.\r
- Edit the working tree files into a desirable shape\r
- (<em>git mergetool</em> can ease this task), <em>git-add</em> or <em>git-rm</em>\r
- them, to make the index file contain what the merge result\r
- should be, and run <em>git-commit</em> to commit the result.\r
+Resolve the conflicts. Git will mark the conflicts in\r
+ the working tree. Edit the files into shape and\r
+ <em>git-add</em> to the index. <em>git-commit</em> to seal the deal.\r
+</p>\r
+</li>\r
+</ul></div>\r
+<div class="para"><p>You can work through the conflict with a number of tools:</p></div>\r
+<div class="ilist"><ul>\r
+<li>\r
+<p>\r
+Use a mergetool. <em>git mergetool</em> to launch a graphical\r
+ mergetool which will work you through the merge.\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+Look at the diffs. <em>git diff</em> will show a three-way diff,\r
+ highlighting changes from both the HEAD and remote versions.\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+Look at the diffs on their own. <em>git log --merge -p <path></em>\r
+ will show diffs first for the HEAD version and then the\r
+ remote version.\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+Look at the originals. <em>git show :1:filename</em> shows the\r
+ common ancestor, <em>git show :2:filename</em> shows the HEAD\r
+ version and <em>git show :3:filename</em> shows the remote version.\r
</p>\r
</li>\r
</ul></div>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 2008-08-06 06:19:09 UTC\r
+Last updated 2008-08-24 03:33:55 UTC\r
</div>\r
</div>\r
</body>\r
up working tree changes made by 2. and 3.; 'git-reset --hard' can
be used for this.
- * Resolve the conflicts. `git diff` would report only the
- conflicting paths because of the above 2. and 3.
- Edit the working tree files into a desirable shape
- ('git mergetool' can ease this task), 'git-add' or 'git-rm'
- them, to make the index file contain what the merge result
- should be, and run 'git-commit' to commit the result.
+ * Resolve the conflicts. Git will mark the conflicts in
+ the working tree. Edit the files into shape and
+ 'git-add' to the index. 'git-commit' to seal the deal.
+You can work through the conflict with a number of tools:
+
+ * Use a mergetool. 'git mergetool' to launch a graphical
+ mergetool which will work you through the merge.
+
+ * Look at the diffs. 'git diff' will show a three-way diff,
+ highlighting changes from both the HEAD and remote versions.
+
+ * Look at the diffs on their own. 'git log --merge -p <path>'
+ will show diffs first for the HEAD version and then the
+ remote version.
+
+ * Look at the originals. 'git show :1:filename' shows the
+ common ancestor, 'git show :2:filename' shows the HEAD
+ version and 'git show :3:filename' shows the remote version.
SEE ALSO
--------