From: Junio C Hamano Date: Mon, 23 Nov 2009 00:28:06 +0000 (-0800) Subject: Merge branch 'tr/maint-merge-ours-clarification' (early part) X-Git-Tag: v1.6.6-rc0~14 X-Git-Url: https://git.lorimer.id.au/gitweb.git/diff_plain/c50230f75109677d7adf0bd94f99d17f35a519a6?hp=-c Merge branch 'tr/maint-merge-ours-clarification' (early part) * 'tr/maint-merge-ours-clarification' (early part): rebase docs: clarify --merge and --strategy Documentation: clarify 'ours' merge strategy --- c50230f75109677d7adf0bd94f99d17f35a519a6 diff --combined Documentation/git-rebase.txt index 33e0ef1f6d,167c8bed59..ca5e1e8653 --- a/Documentation/git-rebase.txt +++ b/Documentation/git-rebase.txt @@@ -228,13 -228,23 +228,23 @@@ OPTION Use merging strategies to rebase. When the recursive (default) merge strategy is used, this allows rebase to be aware of renames on the upstream side. + + + Note that a rebase merge works by replaying each commit from the working + branch on top of the branch. Because of this, when a merge + conflict happens, the side reported as 'ours' is the so-far rebased + series, starting with , and 'theirs' is the working branch. In + other words, the sides are swapped. -s :: --strategy=:: Use the given merge strategy. - If there is no `-s` option, a built-in list of strategies - is used instead ('git-merge-recursive' when merging a single - head, 'git-merge-octopus' otherwise). This implies --merge. + If there is no `-s` option 'git-merge-recursive' is used + instead. This implies --merge. + + + Because 'git-rebase' replays each commit from the working branch + on top of the branch using the given strategy, using + the 'ours' strategy simply discards all patches from the , + which makes little sense. -q:: --quiet:: @@@ -368,17 -378,14 +378,17 @@@ By replacing the command "pick" with th the files and/or the commit message, amend the commit, and continue rebasing. +If you just want to edit the commit message for a commit, replace the +command "pick" with the command "reword". + If you want to fold two or more commits into one, replace the command "pick" with "squash" for the second and subsequent commit. If the commits had different authors, it will attribute the squashed commit to the author of the first commit. -In both cases, or when a "pick" does not succeed (because of merge -errors), the loop will stop to let you fix things, and you can continue -the loop with `git rebase --continue`. +'git-rebase' will stop when "pick" has been replaced with "edit" or +when a command fails due to merge errors. When you are done editing +and/or resolving conflicts you can continue with `git rebase --continue`. For example, if you want to reorder the last 5 commits, such that what was HEAD~4 becomes the new HEAD. To achieve that, you would call