[PATCH v2] pull: warn on --verify-signatures with --rebase
Previously git-pull silently ignored the --verify-signatures option for
--rebase, potentially leaving users in the believe that the rebase
operation would check for valid GPG signatures.
Implementing --verify-signatures for git-rebase was talked about, but
doubts for a valid workflow rose up.
Since you usually merge other's branches into your branch you might have
an interest that their side has a valid GPG signature.
Rebasing, on the other hand, is you building something on top of
another's branch, essentially giving you the power to keep things sane.
If a valid use case is found, where --verify-signatures for git-rebase
looks sensible, that feature may be added then.
A warning was chosen in favor of emitting an error to prevent potential
breakage. A warning keeps things running, scripts for instance, while
still informing users about possibly unexpected behavior.
Signed-off-by: Alexander 'z33ky' Hirsch <1ze...@gmail.com>
---
The warning message was changed to make it clear that the pull (and
rebase) operation still proceeds.
And the commit message was amended with more reasoning about the change
and why alternative approaches were not used.
builtin/pull.c | 3 +++
t/t5520-pull.sh | 16
2 files changed, 19 insertions(+)
diff --git a/builtin/pull.c b/builtin/pull.c
index 1d7333c..b03bc39 100644
--- a/builtin/pull.c
+++ b/builtin/pull.c
@@ -815,6 +815,9 @@ static int run_rebase(const unsigned char *curr_head,
argv_array_push(&args, "--no-autostash");
else if (opt_autostash == 1)
argv_array_push(&args, "--autostash");
+ if (opt_verify_signatures &&
+ strcmp(opt_verify_signatures, "--verify-signatures") == 0)
+ warning(_("ignoring --verify-signatures for rebase"));
argv_array_push(&args, "--onto");
argv_array_push(&args, sha1_to_hex(merge_head));
diff --git a/t/t5520-pull.sh b/t/t5520-pull.sh
index 739c089..3159956 100755
--- a/t/t5520-pull.sh
+++ b/t/t5520-pull.sh
@@ -341,6 +341,22 @@ test_expect_success 'branch.to-rebase.rebase should
override pull.rebase' '
test new = "$(git show HEAD:file2)"
'
+test_expect_success "pull --rebase warns on --verify-signatures" '
+ git reset --hard before-rebase &&
+ git pull --rebase --verify-signatures . copy 2>err &&
+ test "$(git rev-parse HEAD^)" = "$(git rev-parse copy)" &&
+ test new = "$(git show HEAD:file2)" &&
+ test_i18ngrep "ignoring --verify-signatures for rebase" err
+'
+
+test_expect_success "pull --rebase does not warn on --no-verify-signatures" '
+ git reset --hard before-rebase &&
+ git pull --rebase --no-verify-signatures . copy 2>err &&
+ test "$(git rev-parse HEAD^)" = "$(git rev-parse copy)" &&
+ test new = "$(git show HEAD:file2)" &&
+ test_i18ngrep ! "verify-signatures" err
+'
+
# add a feature branch, keep-merge, that is merged into master, so the
# test can try preserving the merge commit (or not) with various
# --rebase flags/pull.rebase settings.
--
2.8.2
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pull: warn on --verify-signatures with --rebase
On Wed, May 18, 2016 at 09:04:24AM -0700, Junio C Hamano wrote:
> > Previously git-pull silently ignored the --verify-signatures option for
> > --rebase.
>
> Missing pieces information that would have made the patch more
> complete are answers to these questions:
>
> - Is that a bad thing? Why?
>
> - Assuming it is a bad thing, what is the solution this patch
>presents us? Teach rebase about the option? Error out the
>request? What is the reason why "warn" was chosen as the best
>way forward?
>
Is the warning a solution "for now" and might this become an error
should a valid usecase not be found after a while?
> > builtin/pull.c | 2 ++
> > t/t5520-pull.sh | 16
> > 2 files changed, 18 insertions(+)
> >
> > diff --git a/builtin/pull.c b/builtin/pull.c
> > index 1d7333c..0eafae7 100644
> > --- a/builtin/pull.c
> > +++ b/builtin/pull.c
> > @@ -815,6 +815,8 @@ static int run_rebase(const unsigned char *curr_head,
> > argv_array_push(&args, "--no-autostash");
> > else if (opt_autostash == 1)
> > argv_array_push(&args, "--autostash");
> > + if (opt_verify_signatures && strcmp(opt_verify_signatures,
> > "--verify-signatures") == 0)
>
> The logic looks OK. I would have written that long line as two
> lines, e.g.
>
> if (opt_verify_signatures &&
> !strcmp(opt_verify_signatures, "--verify-signatures")
>
> though.
>
I shall format it as per your suggestion in the next submission.
> > + warning(_("git-rebase does not support --verify-signatures"));
>
> Is this a good warning message?
>
> As a casual reader, my reaction to this warning would be "Does not
> support? Then what did it do instead? Did it refuse to integrate
> my changes on top of what happened on the remote?"
>
Indeed.
> Something like
>
> warning(_("ignored --verify-signatures as it is meaningless in rebase"));
>
> may convey what is going on better, in that it makes it clear that
> we are not failing "rebase" and instead we are ignoring "verify".
>
> It is way too long for the final version, though. A more concise
> way to say the same thing needs to be found.
>
Would "ignoring --verify-signatures for rebase" be sufficient? It does
not describe why it is ignored though.
With Regards,
Alexander Hirsch
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] pull: warn on --verify-signatures with --rebase
Previously git-pull silently ignored the --verify-signatures option for
--rebase.
Signed-off-by: Alexander 'z33ky' Hirsch <1ze...@gmail.com>
---
Sorry it took so long for the update.
I made git-pull warn instead or error and explained why "the
--verify-signatures option does not work for --rebase" in the message.
builtin/pull.c | 2 ++
t/t5520-pull.sh | 16
2 files changed, 18 insertions(+)
diff --git a/builtin/pull.c b/builtin/pull.c
index 1d7333c..0eafae7 100644
--- a/builtin/pull.c
+++ b/builtin/pull.c
@@ -815,6 +815,8 @@ static int run_rebase(const unsigned char *curr_head,
argv_array_push(&args, "--no-autostash");
else if (opt_autostash == 1)
argv_array_push(&args, "--autostash");
+ if (opt_verify_signatures && strcmp(opt_verify_signatures,
"--verify-signatures") == 0)
+ warning(_("git-rebase does not support --verify-signatures"));
argv_array_push(&args, "--onto");
argv_array_push(&args, sha1_to_hex(merge_head));
diff --git a/t/t5520-pull.sh b/t/t5520-pull.sh
index 739c089..d605450 100755
--- a/t/t5520-pull.sh
+++ b/t/t5520-pull.sh
@@ -341,6 +341,22 @@ test_expect_success 'branch.to-rebase.rebase should
override pull.rebase' '
test new = "$(git show HEAD:file2)"
'
+test_expect_success "pull --rebase warns on --verify-signatures" '
+ git reset --hard before-rebase &&
+ git pull --rebase --verify-signatures . copy 2>err &&
+ test "$(git rev-parse HEAD^)" = "$(git rev-parse copy)" &&
+ test new = "$(git show HEAD:file2)" &&
+ test_i18ngrep "git-rebase does not support --verify-signatures" err
+'
+
+test_expect_success "pull --rebase does not warn on --no-verify-signatures" '
+ git reset --hard before-rebase &&
+ git pull --rebase --no-verify-signatures . copy 2>err &&
+ test "$(git rev-parse HEAD^)" = "$(git rev-parse copy)" &&
+ test new = "$(git show HEAD:file2)" &&
+ test_i18ngrep ! "verify-signatures" err
+'
+
# add a feature branch, keep-merge, that is merged into master, so the
# test can try preserving the merge commit (or not) with various
# --rebase flags/pull.rebase settings.
--
2.8.2
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] pull: make --rebase --verify-signatures illegal
Previously git-pull would silently ignore the --verify-signatures
option.
Signed-off-by: Alexander 'z33ky' Hirsch <1ze...@gmail.com>
---
I made the error-message conform to the CodingGuidelines (removed
capitalization and full stop).
Also, in the previous mail I said that I proposed a patch for git-pull
last December, when I actually meant git-rebase.
builtin/pull.c | 2 ++
t/t5520-pull.sh | 14 ++
2 files changed, 16 insertions(+)
diff --git a/builtin/pull.c b/builtin/pull.c
index d98f481..b6e1507 100644
--- a/builtin/pull.c
+++ b/builtin/pull.c
@@ -809,6 +809,8 @@ static int run_rebase(const unsigned char *curr_head,
argv_array_push(&args, "--no-autostash");
else if (opt_autostash == 1)
argv_array_push(&args, "--autostash");
+ if (opt_verify_signatures && strcmp(opt_verify_signatures,
"--verify-signatures") == 0)
+ die(_("the --verify-signatures option does not work for
--rebase"));
argv_array_push(&args, "--onto");
argv_array_push(&args, sha1_to_hex(merge_head));
diff --git a/t/t5520-pull.sh b/t/t5520-pull.sh
index 739c089..cb8f741 100755
--- a/t/t5520-pull.sh
+++ b/t/t5520-pull.sh
@@ -341,6 +341,20 @@ test_expect_success 'branch.to-rebase.rebase should
override pull.rebase' '
test new = "$(git show HEAD:file2)"
'
+test_expect_success "pull --rebase --verify-signatures is illegal" '
+ git reset --hard before-rebase &&
+ test_must_fail git pull --rebase --verify-signatures . copy 2>err &&
+ test "$(git rev-parse HEAD)" = "$(git rev-parse before-rebase)" &&
+ test_i18ngrep "The --verify-signatures option does not work for
--rebase." err
+'
+
+test_expect_success "pull --rebase --no-verify-signatures" '
+ git reset --hard before-rebase &&
+ git pull --rebase --no-verify-signatures . copy &&
+ test "$(git rev-parse HEAD^)" = "$(git rev-parse copy)" &&
+ test new = "$(git show HEAD:file2)"
+'
+
# add a feature branch, keep-merge, that is merged into master, so the
# test can try preserving the merge commit (or not) with various
# --rebase flags/pull.rebase settings.
--
2.8.0
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] pull: make --rebase --verify-signatures illegal
Previously git-pull would silently ignore the --verify-signatures
option.
Signed-off-by: Alexander 'z33ky' Hirsch <1ze...@gmail.com>
---
We had some discussion back in December about a patch that added
--verify-signatures to git-pull, that was declined.
I proposed making git-pull --rebase --verify-signatures illegal then,
although it still remained open whether to just warn or make it an
error.
In this patch I opted into making it an error, which breaks the
previously accepted git pull --rebase --verify-signatures of course,
albeit I'd argue that it probably didn't do what the user expected
anyways.
I don't know if there are compatibility concerns with this though.
builtin/pull.c | 2 ++
t/t5520-pull.sh | 14 ++
2 files changed, 16 insertions(+)
diff --git a/builtin/pull.c b/builtin/pull.c
index d98f481..b6e1507 100644
--- a/builtin/pull.c
+++ b/builtin/pull.c
@@ -809,6 +809,8 @@ static int run_rebase(const unsigned char *curr_head,
argv_array_push(&args, "--no-autostash");
else if (opt_autostash == 1)
argv_array_push(&args, "--autostash");
+ if (opt_verify_signatures && strcmp(opt_verify_signatures,
"--verify-signatures") == 0)
+ die(_("The --verify-signatures option does not work for
--rebase."));
argv_array_push(&args, "--onto");
argv_array_push(&args, sha1_to_hex(merge_head));
diff --git a/t/t5520-pull.sh b/t/t5520-pull.sh
index 739c089..cb8f741 100755
--- a/t/t5520-pull.sh
+++ b/t/t5520-pull.sh
@@ -341,6 +341,20 @@ test_expect_success 'branch.to-rebase.rebase should
override pull.rebase' '
test new = "$(git show HEAD:file2)"
'
+test_expect_success "pull --rebase --verify-signatures is illegal" '
+ git reset --hard before-rebase &&
+ test_must_fail git pull --rebase --verify-signatures . copy 2>err &&
+ test "$(git rev-parse HEAD)" = "$(git rev-parse before-rebase)" &&
+ test_i18ngrep "The --verify-signatures option does not work for
--rebase." err
+'
+
+test_expect_success "pull --rebase --no-verify-signatures" '
+ git reset --hard before-rebase &&
+ git pull --rebase --no-verify-signatures . copy &&
+ test "$(git rev-parse HEAD^)" = "$(git rev-parse copy)" &&
+ test new = "$(git show HEAD:file2)"
+'
+
# add a feature branch, keep-merge, that is merged into master, so the
# test can try preserving the merge commit (or not) with various
# --rebase flags/pull.rebase settings.
--
2.8.0
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] rebase: add --verify-signatures
Sorry, I didn't do a group-reply in my last mail. On Mon, Dec 21, 2015 at 03:46:54PM -0800, Junio C Hamano wrote: > Alexander 'z33ky' Hirsch <1ze...@gmail.com> writes: > > > On Thu, Dec 17, 2015 at 10:22:20AM -0800, Junio C Hamano wrote: > >> I suspect that you are missing the bigger workflow issues, if you > >> think this and merge are the same. > >> > >> git-merge will check the other history on the side branch that you > >> are merging _into_ the trunk, to give you an opportunity to reject > >> what does not pass and keep the trunk sane without doing anything > >> else. How you (or others who asked you to pull) clean up the side > >> branch is outside the scope of its verification. > >> > >> Your change to "git pull --rebase" checks the other way---the > >> history, which is already the trunk, onto which your work will be > >> rebased. There is nothing you can do without messing with the trunk > >> if the validation did not pass, be it with a rewind-and-rebuild or a > >> sealing empty commit which is pointless. > > > > It would still make sense for long-lived development branches that > > contain experimental or controversial features, or for forks/private > > copies that add a couple of commits onto a branch. Merging is certainly > > an option, but I don't see why rebasing would be a wrong alternative. > > Nobody says rebase is a wrong alternative. > > It is just the time you decide to rebase is a wrong time to check, > iow, too late, for the validation of the tip. In that case I would like to submit a patch that warns or even errors in case both --rebase and --verify-signatures is passed to git-pull. I think an error would be appropriate, but in theory this could break scripts that have done that, albeit it probably didn't do what the user expected, and I don't know git's policy about breaking something like this. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] rebase: add --verify-signatures
On Wed, Dec 16, 2015 at 10:12:12AM -0800, Junio C Hamano wrote: > I do not quite understand how that would help anything. I do not > personally believe in projects that wants to sign each and every > commit, but to them, "an empty signed commit on top" would not fix > anything once they have an unsigned commit at the tip of a public > branch. And for those that care about only the tip to be signed, > instead of adding such an empty commit, you would rebuild and sign > your work on top of that unsigned public tip and push back---at > which point the tip of the public branch would have a signature from > you. So such an empty signed commit would either not help, or not > necessary, to make the resulting history kosher again. > Checking all commits was a mistake I made because of misinterpreting the git-merge code. Only the tip should be checked for a signature. And the reason to get it signed instead of just signing the commits rebased on top is to defer to the judgement of the author of the branch you're rebasing onto instead of checking the unsigned commits for validity yourself. As I understand it, this is the same reason for the existence of --verify-signatures for git-merge. Otherwise the same argument could be made for git-merge - just do whatever cleanup you need after merging and sign it yourself. Or maybe I haven't grasped what --verify-signatures is for. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] rebase: add --verify-signatures
On Thu, Dec 10, 2015 at 11:53:45AM -0800, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Alexander 'z33ky' Hirsch <1ze...@gmail.com> writes:
> >
> >> + if test -n "$rebase_root"
> >> + then
> >> + foreign_revisions="$orig_head..$onto"
> >> + else
> >> + foreign_revisions="$orig_head..${restrict_revision-$upstream}"
> >> + fi
> >> +
> >> + for cmt in $(git rev-list --reverse "$foreign_revisions")
> >> + do
> >> + if ! git log -1 --pretty=format:'%G?%n%GS' "$cmt" |
> >
> > I do not think this matches what the corresponding option in "git
> > merge" does, where the only tips of the histories being merged are
> > checked.
Oh, indeed. I saw the loop in merge.c and by brain went there without
any further thought. This would be easy to fix though.
> Having said that, I somehow doubt that verify-signatures is a
> feature that is desirable in a workflow around "pull --rebase" in
> the larger picture. If you step back a bit, in a "merge" based
> workflow, you are the keeper of the sanity, cleanliness, and all the
> good things in the authoritative history when doing a "git pull".
> That is why you would want to validate what gets merged from another
> place and in that context having --verify-signatures may make sense
> (and it might even make more sense if the code did so for all new
> commits, not just the tip, but that is a separate topic). If the
> validation fails, you would tell the owner of that side branch you
> just attempted to pull from to get her act together before asking to
> be pulled again. There is a clear path to make further progress
> after the validation fails.
>
> In a workflow that is built around "pull --rebase", you are _given_
> the authoritative history with all the good things from another
> place and then you rebuild your own work on top of it. The sanity
> and cleanliness of what you built on top is given, and rejecting it
> at that point would not help you make further progress in any way,
> as that is a published history that is shared and more authoritative
> than what you have.
Well, the rejection would not refer to the work you put on top, but to
the commits you want to base your work on.
If validation fails, then an empty commit that is signed can be
committed on top of the previously unsigned branch if commit rewriting
is not allowed.
> Hence, while I 100% agree with Brian's "it is not there because
> nobody bothered to add the corresponding option on the rebase side",
> I do not necessarily think "nobody bothered" is the same as "they
> were too lazy"--perhaps some people thought about doing it, and then
> decided not to, because the option made no sense when they stepped
> back to look at the larger picture.
That's why I was asking in my first mail if such an addition would make
sense. I don't really have an agenda or a pressing need for this
feature, I just noticed that a `git pull --rebase --verify-signatures`
did not complain when it looked like it ought to.
If this patch gets rejected then I will propose one which makes git-pull
warn, or even error, when both --rebase and --verify-signatures is
passed.
Regards,
Alexander Hirsch
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] rebase: add --verify-signatures
This option works analogous to --verify-signatures for git-merge by
checking that the commits, that are rebased onto, have good GPG
signatures.
Additionally, git-pull now forwards --verify-signatures to rebase as
well.
Signed-off-by: Alexander 'z33ky' Hirsch <1ze...@gmail.com>
---
I'm unsure if the opt_verify_signatures check in builtin/pull.c should
be moved up to the "/* Shared options */" now.
The output strings from the GPG check are identical to the ones in
builtin/merge.c; I am unsure about the implications for l10n.
The test is mostly copied from t7612-merge-verify-signatures.sh.
Documentation/git-rebase.txt| 6
builtin/pull.c | 2 ++
git-rebase.sh | 44 +
t/t3427-rebase-verify-signatures.sh | 65 +
4 files changed, 117 insertions(+)
create mode 100755 t/t3427-rebase-verify-signatures.sh
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 6cca8bb..959b12b 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -292,6 +292,12 @@ which makes little sense.
specified, `-s recursive`. Note the reversal of 'ours' and
'theirs' as noted above for the `-m` option.
+--verify-signatures::
+--no-verify-signatures::
+ Verify that the commits in the branch the rebase is onto, but not
+ present in the working branch, have good GPG signatures and abort the
+ operation in case they do not.
+
-S[]::
--gpg-sign[=]::
GPG-sign commits. The `keyid` argument is optional and
diff --git a/builtin/pull.c b/builtin/pull.c
index bf3fd3f..37ec0f8 100644
--- a/builtin/pull.c
+++ b/builtin/pull.c
@@ -774,6 +774,8 @@ static int run_rebase(const unsigned char *curr_head,
argv_array_push(&args, "--preserve-merges");
if (opt_diffstat)
argv_array_push(&args, opt_diffstat);
+ if (opt_verify_signatures)
+ argv_array_push(&args, opt_verify_signatures);
argv_array_pushv(&args, opt_strategies.argv);
argv_array_pushv(&args, opt_strategy_opts.argv);
if (opt_gpg_sign)
diff --git a/git-rebase.sh b/git-rebase.sh
index af7ba5f..dcfbc3a 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -38,6 +38,7 @@ whitespace=! passed to 'git apply'
ignore-whitespace! passed to 'git apply'
C=!passed to 'git apply'
S,gpg-sign?GPG-sign commits
+verify-signatures verify that the commits of onto have valid GPG signatures
Actions:
continue! continue
abort! abort and check out the original branch
@@ -88,6 +89,7 @@ autosquash=
keep_empty=
test "$(git config --bool rebase.autosquash)" = "true" && autosquash=t
gpg_sign_opt=
+verify_signatures=
read_basic_state () {
test -f "$state_dir/head-name" &&
@@ -339,6 +341,12 @@ do
--gpg-sign=*)
gpg_sign_opt="-S${1#--gpg-sign=}"
;;
+ --verify-signatures)
+ verify_signatures=t
+ ;;
+ --no-verify-signatures)
+ verify_signatures=
+ ;;
--)
shift
break
@@ -594,6 +602,42 @@ then
fi
fi
+if test "$verify_signatures"
+then
+ if test -n "$rebase_root"
+ then
+ foreign_revisions="$orig_head..$onto"
+ else
+ foreign_revisions="$orig_head..${restrict_revision-$upstream}"
+ fi
+
+ for cmt in $(git rev-list --reverse "$foreign_revisions")
+ do
+ if ! git log -1 --pretty=format:'%G?%n%GS' "$cmt" |
+ (
+ read cmt_sig
+ read cmt_signer
+ case "$cmt_sig" in
+ 'G')
+ ;;
+ 'U')
+ die "$(gettext "Commit $cmt has an untrusted
GPG signature, allegedly by $cmt_signer.")"
+ ;;
+ 'B')
+ die "$(gettext "Commit $cmt has a bad GPG
signature allegedly by $cmt_signer.")"
+ ;;
+ *) #'N'
+ die "$(gettext "Commit $cmt does not have a GPG
signature.")"
+ ;;
+ esac
+ test "$verbose" && test 'G' = "$cmt_sig" && echo
"Commit $cmt has a good GPG signature by $cmt_signer."
+ )
+ then
+ exit 1
+
Re: rebase has no --verify-signatures
On Tue, Dec 08, 2015 at 01:21:25AM +, brian m. carlson wrote: > On Mon, Dec 07, 2015 at 03:00:15PM +0100, Alexander 'z33ky' Hirsch wrote: > > Is there any technical reason why rebase should not have a > > --verify-signatures flag? I have written a patch to git-rebase--am > > which enables it to do such a check. If there is no reason not to > > include it I'd add documentation and a test and submit it. > > As far as I know, there is no technical reason that it shouldn't. It's > probably that nobody has implemented it yet. I'd certainly be > interested in such a patch. > > For a thorough change, you'd probably want to make it work with > git-rebase--merge and git-rebase--interactive as well. I'm sure I'm not > the only person who frequently uses rebase -m. Ah, rebase -m. That sounds nice, I didn't know about this feature. In fact, I first tried to write the code in git-rebase--merge, thinking this is the default rebase script. git-rebase--interactive sounds a bit more difficult since you could easily modify commits, thereby removing previously GPG signed commits. Although this sounds like all the more reason why it would be useful to check for it. I'll look at the script and ponder about it. I'll post whatever I come up with on Thursday (probably) or Friday. I'll put you in the CC when I post the patch. Regards, Alexander Hirsch -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
rebase has no --verify-signatures
Hi, The git merge command has a --verify-signatures flag, which, when set, checks that the commits to be merged have trusted GPG signatures. git pull also knows this flag and forwards it to the merge command. However, doing a git pull --rebase --verify-signatures silently ignores it, since rebase has no --verify-signatures flag. Is there any technical reason why rebase should not have a --verify-signatures flag? I have written a patch to git-rebase--am which enables it to do such a check. If there is no reason not to include it I'd add documentation and a test and submit it. Otherwise I think git pull should warn, or even die with an error, if both --rebase and --verify-signatures are passed. Regards, Alexander Hirsch -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] status: allow branch info color customization
From: Alexander Hirsch <1ze...@gmail.com> git status -bs (--branch --short) does not seem to allow customization of the colors for the local and remote branch. This patch adds these via the color.status.local and color.status.remote config variables. Given the trivial nature of this patch I did not write a test for it. I did a small check that it's working so, to be on the safe side. Signed-off-by: Alexander Hirsch <1ze...@gmail.com> --- Documentation/config.txt | 7 +-- builtin/commit.c | 4 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index d4d93c9..261fc99 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -904,9 +904,12 @@ color.status.:: `added` or `updated` (files which are added but not committed), `changed` (files which are changed but not added in the index), `untracked` (files which are not tracked by Git), - `branch` (the current branch), or + `branch` (the current branch), `nobranch` (the color the 'no branch' warning is shown in, defaulting - to red). The values of these variables may be specified as in + to red), + `local` (the local branch when showing branch info), or + `remote` (the remote-tracked branch when showing branch info). + The values of these variables may be specified as in color.branch.. color.ui:: diff --git a/builtin/commit.c b/builtin/commit.c index 6ab4605..43365b4 100644 --- a/builtin/commit.c +++ b/builtin/commit.c @@ -1165,6 +1165,10 @@ static int parse_status_slot(const char *var, int offset) return WT_STATUS_HEADER; if (!strcasecmp(var+offset, "branch")) return WT_STATUS_ONBRANCH; + if (!strcasecmp(var+offset, "local")) + return WT_STATUS_LOCAL_BRANCH; + if (!strcasecmp(var+offset, "remote")) + return WT_STATUS_REMOTE_BRANCH; if (!strcasecmp(var+offset, "updated") || !strcasecmp(var+offset, "added")) return WT_STATUS_UPDATED; -- 1.8.4.1 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
