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 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 NNTP newsgroup(s).