From: "Karl Hasselström" <kha@treskal.com>
To: Catalin Marinas <catalin.marinas@gmail.com>
Cc: git@vger.kernel.org, Jon Smirl <jonsmirl@gmail.com>
Subject: [StGit PATCH] Make "stg repair" help text more helpful
Date: Fri, 30 Nov 2007 07:35:50 +0100 [thread overview]
Message-ID: <20071130063516.27500.85249.stgit@yoghurt> (raw)
In-Reply-To: <20071128164113.GA20749@diana.vm.bytemark.co.uk>
Specifically, point out that if messing up the branch with git
commands was a mistake, the user should run "git reset", not "stg
repair".
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
Is this an improvement?
stgit/commands/common.py | 4 +--
stgit/commands/repair.py | 63 ++++++++++++++++++++++++++++------------------
2 files changed, 41 insertions(+), 26 deletions(-)
diff --git a/stgit/commands/common.py b/stgit/commands/common.py
index 6318cdd..bf804e6 100644
--- a/stgit/commands/common.py
+++ b/stgit/commands/common.py
@@ -114,8 +114,8 @@ def check_head_top_equal(crt_series):
if not crt_series.head_top_equal():
raise CmdException(
"""HEAD and top are not the same. This can happen if you
- modify a branch with git. The "repair" command can
- fix this situation.""")
+ modify a branch with git. "stg repair --help" explains
+ more about what to do next.""")
def check_conflicts():
if os.path.exists(os.path.join(basedir.get(), 'conflicts')):
diff --git a/stgit/commands/repair.py b/stgit/commands/repair.py
index c36db07..aa34792 100644
--- a/stgit/commands/repair.py
+++ b/stgit/commands/repair.py
@@ -26,32 +26,47 @@ from stgit.out import *
from stgit.run import *
from stgit import stack, git
-help = 'StGit-ify any git commits made on top of your StGit stack'
+help = 'Fix StGit metadata if branch was modified with git commands'
usage = """%prog [options]
-"repair" will repair three kinds of inconsistencies in your StGit
-stack, all of them caused by using plain git commands on the branch:
-
- 1. If you have made regular git commits on top of your stack of
- StGit patches, "repair" converts them to StGit patches,
- preserving their contents.
-
- 2. Merge commits cannot become patches; if you have committed a
- merge on top of your stack, "repair" will simply mark all
- patches below the merge unapplied, since they are no longer
- reachable. If this is not what you want, use "git reset" to get
- rid of the merge and run "repair" again.
-
- 3. The applied patches are supposed to be precisely those that are
- reachable from the branch head. If you have used e.g. "git reset"
- to move the head, some applied patches may no longer be
- reachable, and some unapplied patches may have become reachable.
- "repair" will correct the appliedness of such patches.
-
-Note that these are "inconsistencies", not "errors"; furthermore,
-"repair" will repair them reliably. As long as you are satisfied
-with the way "repair" handles them, you have no reason to avoid
-causing them in the first place if that is convenient for you."""
+If you modify an StGit stack (branch) with some git commands -- such
+as commit, pull, merge, and rebase -- you will leave the StGit
+metadata in an inconsistent state. In that situation, you have two
+options:
+
+ 1. Use "git reset" or similar to undo the effect of the git
+ command(s).
+
+ 2. Use "stg repair". This will fix up the StGit metadata to
+ accomodate the modifications to the branch. Specifically, it will
+ do the following:
+
+ * If you have made regular git commits on top of your stack of
+ StGit patches, "stg repair" makes new StGit patches out of
+ them, preserving their contents.
+
+ * However, merge commits cannot become patches; if you have
+ committed a merge on top of your stack, "repair" will simply
+ mark all patches below the merge unapplied, since they are no
+ longer reachable. If this is not what you want, use "git
+ reset" to get rid of the merge and run "stg repair" again.
+
+ * The applied patches are supposed to be precisely those that
+ are reachable from the branch head. If you have used e.g.
+ "git reset" to move the head, some applied patches may no
+ longer be reachable, and some unapplied patches may have
+ become reachable. "stg repair" will correct the appliedness
+ of such patches.
+
+ "stg repair" will fix these inconsistencies reliably, so as long
+ as you like what it does, you have no reason to avoid causing
+ them in the first place. For example, you might find it
+ convenient to make commits with a graphical tool and then have
+ "stg repair" make proper patches of the commits.
+
+NOTE: If using git commands on the stack was a mistake, running "stg
+repair" is _not_ what you want. In that case, what you want is option
+(1) above."""
directory = DirectoryGotoToplevel()
options = []
next prev parent reply other threads:[~2007-11-30 6:36 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-27 22:17 stgit: lost all my patches again Jon Smirl
2007-11-27 22:24 ` Jakub Narebski
2007-11-27 23:12 ` Jon Smirl
2007-11-28 9:34 ` Karl Hasselström
2007-11-28 10:17 ` StGit hooks Karl Hasselström
2007-11-28 11:44 ` Andreas Ericsson
2007-11-28 12:19 ` Karl Hasselström
2007-11-28 13:14 ` Andreas Ericsson
2007-11-28 13:26 ` Karl Hasselström
2007-11-28 14:11 ` Andreas Ericsson
2007-11-28 14:53 ` Jon Smirl
2007-11-28 14:58 ` Andreas Ericsson
2007-11-28 15:40 ` Karl Hasselström
2007-11-28 17:06 ` Andreas Ericsson
2007-11-28 17:21 ` Karl Hasselström
2007-11-28 19:31 ` Junio C Hamano
2007-11-28 15:06 ` stgit: lost all my patches again Jon Smirl
2007-11-28 16:04 ` Karl Hasselström
2007-11-28 16:21 ` Jon Smirl
2007-11-28 16:41 ` Karl Hasselström
2007-11-28 16:58 ` Jon Smirl
2007-11-28 17:19 ` Karl Hasselström
2007-11-30 6:35 ` Karl Hasselström [this message]
2007-11-28 0:37 ` Junio C Hamano
2007-11-28 2:59 ` Jon Smirl
2007-11-28 6:32 ` Karl Hasselström
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20071130063516.27500.85249.stgit@yoghurt \
--to=kha@treskal.com \
--cc=catalin.marinas@gmail.com \
--cc=git@vger.kernel.org \
--cc=jonsmirl@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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.