git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
To: git@vger.kernel.org
Cc: Junio C Hamano <gitster@pobox.com>,
	Jonathan Nieder <jrnieder@gmail.com>,
	Drew Northup <drew.northup@maine.edu>,
	Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Subject: [PATCH v4] rebase: clarify "restore the original branch"
Date: Wed, 13 Jul 2011 23:47:06 -0400	[thread overview]
Message-ID: <1310615226-3251-1-git-send-email-martin.von.zweigbergk@gmail.com> (raw)
In-Reply-To: <1310322661-24924-1-git-send-email-martin.von.zweigbergk@gmail.com>

The description for 'git rebase --abort' currently says:

    Restore the original branch and abort the rebase operation.

The "restore" can be misinterpreted to imply that the original branch
was somehow in a broken state during the rebase operation. It is also
not completely clear what "the original branch" is --- is it the
branch that was checked out before the rebase operation was called or
is the the branch that is being rebased (it is the latter)? Although
both issues are made clear in the DESCRIPTION section, let us also
make the entry in the OPTIONS secion more clear.

Also remove the term "rebasing process" from the usage text, since the
user already knows that the text is about "git rebase".

Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
---

While reading some sample output in an unrelated mail from Jeff, I
noticed that we actually use "restore" in a few more places (I had
originally seached for "abort" to find places to update). This patch
fixes those places.

I used the term "check out" instead of "reset HEAD to", because I
think the concept feels more familiar to many people, even though
"reset HEAD to" is technically more correct.

The phrase "restore the original branch" is also used in git-am, where
I think it makes even less sense. I rarely use git-am, but I think it
always applies the patches to the current branch, so there "restore
the original branch" really means "resets the (current) branch to the
original position (where it was when git-am was started)", doesn't it?


 Documentation/git-rebase.txt |    8 ++++++--
 git-rebase.sh                |   10 +++++-----
 2 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index a9e0e50..504945c 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -45,7 +45,7 @@ with a different commit message or timestamp will be skipped).
 It is possible that a merge failure will prevent this process from being
 completely automatic.  You will have to resolve any such merge failure
 and run `git rebase --continue`.  Another option is to bypass the commit
-that caused the merge failure with `git rebase --skip`.  To restore the
+that caused the merge failure with `git rebase --skip`.  To check out the
 original <branch> and remove the .git/rebase-apply working files, use the
 command `git rebase --abort` instead.
 
@@ -232,7 +232,11 @@ leave out at most one of A and B, in which case it defaults to HEAD.
 	Restart the rebasing process after having resolved a merge conflict.
 
 --abort::
-	Restore the original branch and abort the rebase operation.
+	Abort the rebase operation and reset HEAD to the original
+	branch. If <branch> was provided when the rebase operation was
+	started, then HEAD will be reset to <branch>. Otherwise HEAD
+	will be reset to where it was when the rebase operation was
+	started.
 
 --skip::
 	Restart the rebasing process by skipping the current patch.
diff --git a/git-rebase.sh b/git-rebase.sh
index d7855ea..38cbee7 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -13,7 +13,7 @@ It then attempts to create a new commit for each commit from the original
 It is possible that a merge failure will prevent this process from being
 completely automatic.  You will have to resolve any such merge failure
 and run git rebase --continue.  Another option is to bypass the commit
-that caused the merge failure with git rebase --skip.  To restore the
+that caused the merge failure with git rebase --skip.  To check out the
 original <branch> and remove the .git/rebase-apply working files, use the
 command git rebase --abort instead.
 
@@ -57,9 +57,9 @@ whitespace=!       passed to 'git apply'
 ignore-whitespace! passed to 'git apply'
 C=!                passed to 'git apply'
  Actions:
-continue!          continue rebasing process
-abort!             abort rebasing process and restore original branch
-skip!              skip current patch and continue rebasing process
+continue!          continue
+abort!             abort and check out the original branch
+skip!              skip current patch and continue
 "
 . git-sh-setup
 set_reflog_action rebase
@@ -72,7 +72,7 @@ ok_to_skip_pre_rebase=
 resolvemsg="
 When you have resolved this problem run \"git rebase --continue\".
 If you would prefer to skip this patch, instead run \"git rebase --skip\".
-To restore the original branch and stop rebasing run \"git rebase --abort\".
+To check out the original branch and stop rebasing run \"git rebase --abort\".
 "
 unset onto
 strategy=
-- 
1.7.6.51.g07e0e

      reply	other threads:[~2011-07-14  3:47 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-02  2:38 [PATCH 2/2] git-rebase.txt: clarify that --abort checks out <branch> Martin von Zweigbergk
2011-07-05 21:43 ` Drew Northup
2011-07-06  2:19   ` Martin von Zweigbergk
2011-07-06  2:52     ` Jonathan Nieder
2011-07-06 13:25       ` Drew Northup
2011-07-08  2:27 ` [PATCH v2] " Martin von Zweigbergk
2011-07-08 16:07   ` Junio C Hamano
2011-07-10 18:07     ` Martin von Zweigbergk
2011-07-10 18:31   ` [PATCH v3] " Martin von Zweigbergk
2011-07-14  3:47     ` Martin von Zweigbergk [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1310615226-3251-1-git-send-email-martin.von.zweigbergk@gmail.com \
    --to=martin.von.zweigbergk@gmail.com \
    --cc=drew.northup@maine.edu \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jrnieder@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).