Thomas Rast [off-list ref] writes:
Matthieu Moy wrote:
quoted
Martin von Zweigbergk [off-list ref] writes:
quoted
Remove the undocumented and unused '--verify' flag from interactive
rebase.
I don't think this change is good. If a command has a --no-whatever
flag, one expects the --whatever flag to exist too, even if it's a
no-op.
[...]
quoted
I think a better change would be to add a comment like
--verify)
# no-op, exists because --no-verify exists too.
Shouldn't that be
OK_TO_SKIP_PRE_REBASE=
instead, so that it undoes the effect of an earlier --no-verify?
Yes, right. Useful when an alias contains --no-whatever in particular.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
On Mon, 22 Nov 2010, Matthieu Moy wrote:
Thomas Rast [off-list ref] writes:
quoted
Matthieu Moy wrote:
quoted
Martin von Zweigbergk [off-list ref] writes:
quoted
Remove the undocumented and unused '--verify' flag from interactive
rebase.
I don't think this change is good. If a command has a --no-whatever
flag, one expects the --whatever flag to exist too, even if it's a
no-op.
[...]
quoted
I think a better change would be to add a comment like
--verify)
# no-op, exists because --no-verify exists too.
Shouldn't that be
OK_TO_SKIP_PRE_REBASE=
instead, so that it undoes the effect of an earlier --no-verify?
Yes, right. Useful when an alias contains --no-whatever in particular.
Alright, how about something like this instead?
(I hope this is the correct way of including a patch. I have only used
'git send-email before'. I noticed that Jeff seems to remove the first
three lines and put a '-- 8> --' before, but others do not. What does
the mysterious header mean?)
----
From 90c14fe48ab921ae60000e4f9de02f97f867e273 Mon Sep 17 00:00:00 2001
From: Martin von Zweigbergk <redacted>
Date: Mon, 22 Nov 2010 20:42:50 +0100
Subject: [PATCH] rebase: support --verify
Interactive rebase allows the '--verify' option to be passed, but it will
be ignored. Implement proper support for the option for both interactive
and non-interactive rebase by making it override any previous
'--no-verify'.
Signed-off-by: Martin von Zweigbergk <redacted>
---
Documentation/git-rebase.txt | 4 ++++
git-rebase--interactive.sh | 2 ++
git-rebase.sh | 3 +++
3 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index f3753a8..1f5ce74 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -279,6 +279,10 @@ which makes little sense.
--no-verify::
This option bypasses the pre-rebase hook. See also linkgit:githooks[5].
+--verify::
+ Allows the pre-rebase hook to run, which is the default. This option can
+ be used to override --no-verify. See also linkgit:githooks[5].
+
-C<n>::
Ensure at least <n> lines of surrounding context match before
and after each change. When fewer lines of surrounding
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index a27952d..4eabe54 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -28,6 +28,7 @@ continue continue rebasing process
abort abort rebasing process and restore original branch
skip skip current patch and continue rebasing process
no-verify override pre-rebase hook from stopping the operation
+verify allow pre-rebase hook to run
root rebase all reachable commmits up to the root(s)
autosquash move commits that begin with squash!/fixup! under -i
"
@@ -727,6 +728,7 @@ do
OK_TO_SKIP_PRE_REBASE=yes
;;
--verify)
+ OK_TO_SKIP_PRE_REBASE=
;;
--continue)
is_standalone "$@" || usage
diff --git a/git-rebase.sh b/git-rebase.sh
index 3d194b1..595fca2 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -206,6 +206,9 @@ do
--no-verify)
OK_TO_SKIP_PRE_REBASE=yes
;;
+ --verify)
+ OK_TO_SKIP_PRE_REBASE=
+ ;;
--continue)
test -d "$dotest" -o -d "$GIT_DIR"/rebase-apply ||
die "No rebase in progress?"
--
1.7.3.2.190.gfb4ae
On Nov 22, 2010, at 12:21 PM, Martin von Zweigbergk wrote:
(I hope this is the correct way of including a patch. I have only used
'git send-email before'. I noticed that Jeff seems to remove the first
three lines and put a '-- 8> --' before, but others do not. What does
the mysterious header mean?)
It's actually 8< or >8, and it's a little ASCII icon of a pair of scissors.
If a line consists mainly of dashes and scissors then `git am --scissors`
can split the mail on that line and treat the rest of the body after that
line as a patch.
-Kevin Ballard
On Mon, Nov 22, 2010 at 06:24:10PM -0800, Kevin Ballard wrote:
On Nov 22, 2010, at 12:21 PM, Martin von Zweigbergk wrote:
quoted
(I hope this is the correct way of including a patch. I have only used
'git send-email before'. I noticed that Jeff seems to remove the first
three lines and put a '-- 8> --' before, but others do not. What does
the mysterious header mean?)
It's actually 8< or >8, and it's a little ASCII icon of a pair of scissors.
If a line consists mainly of dashes and scissors then `git am --scissors`
can split the mail on that line and treat the rest of the body after that
line as a patch.
Yep. I don't know if Junio actually uses --scissors these days. Before
it existed, he would just snip the parts above the marker manually,
which was not a big deal because he reads his mail in emacs. If that is
still the case, then it doesn't really matter what the marker is, as
long as he recognizes it, and it is not "---", which is the special
marker for splitting commit message from cover letter.
That being said, people other than Junio may apply your patch, so if you
are going to use such a marker, making it look scissor-like is probably
the best thing to do.
-Peff