All of lore.kernel.org
 help / color / mirror / Atom feed
* [RFC/PATCH] rebase--interactive: Add "sign" command
@ 2016-08-03  8:47 Chris Packham
  2016-08-03 14:31 ` Johannes Schindelin
  2016-08-03 15:58 ` Junio C Hamano
  0 siblings, 2 replies; 11+ messages in thread
From: Chris Packham @ 2016-08-03  8:47 UTC (permalink / raw)
  To: git; +Cc: Chris Packham

This is similar to the existing "reword" command in that it can be used
to update the commit message the difference is that the editor presented
to the user for the commit. It provides a useful shorthand for "exec git
commit --amend --no-edit -s"

Signed-off-by: Chris Packham <judge.packham@gmail.com>
---
Hi,

At $dayjob we have a patch based work-flow where committers sign patches on the
way through. Occasionally when a larger patch series is involved it's easier
pull from the submitter's repo and use git rebase -i to add the required sign
off either by using 'reword' or 'exec git commit --amend -s'.

This is my attempt at making this a little less cumbersome by adding a
'sign' command. I decided not to add a short version of the command,
partly because 's' was taken and partly because it is a bit of a niche
use-case.

Thanks,
Chris

 git-rebase--interactive.sh    | 10 +++++++++-
 t/lib-rebase.sh               |  2 +-
 t/t3404-rebase-interactive.sh |  9 +++++++++
 3 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index ded4595..1cd8bc6 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -148,6 +148,7 @@ append_todo_help () {
 Commands:
  p, pick = use commit
  r, reword = use commit, but edit the commit message
+ sign = use commit, add sign-off to the commit message
  e, edit = use commit, but stop for amending
  s, squash = use commit, but meld into previous commit
  f, fixup = like \"squash\", but discard this commit's log message
@@ -594,6 +595,13 @@ you are able to reword the commit.")"
 		}
 		record_in_rewritten $sha1
 		;;
+	sign)
+		comment_for_reflog sign
+		mark_action_done
+		do_pick $sha1 "$rest"
+		git commit --amend -s --no-post-rewrite --no-edit ${gpg_sign_opt:+"$gpg_sign_opt"}
+		record_in_rewritten $sha1
+		;;
 	edit|e)
 		comment_for_reflog edit
 
@@ -959,7 +967,7 @@ check_bad_cmd_and_sha () {
 			# Work around CR left by "read" (e.g. with Git for
 			# Windows' Bash).
 			;;
-		pick|p|drop|d|reword|r|edit|e|squash|s|fixup|f)
+		pick|p|drop|d|reword|r|sign|edit|e|squash|s|fixup|f)
 			if ! check_commit_sha "${rest%%[ 	]*}" "$lineno" "$1"
 			then
 				retval=1
diff --git a/t/lib-rebase.sh b/t/lib-rebase.sh
index 25a77ee..5a54228 100644
--- a/t/lib-rebase.sh
+++ b/t/lib-rebase.sh
@@ -47,7 +47,7 @@ set_fake_editor () {
 	action=pick
 	for line in $FAKE_LINES; do
 		case $line in
-		squash|fixup|edit|reword|drop)
+		squash|fixup|edit|reword|sign|drop)
 			action="$line";;
 		exec*)
 			echo "$line" | sed 's/_/ /g' >> "$1";;
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index 197914b..e473ffb 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -690,6 +690,15 @@ test_expect_success 'reword' '
 	git show HEAD~2 | grep "C changed"
 '
 
+test_expect_success 'sign-off' '
+	git checkout -b sign-off-branch master &&
+	set_fake_editor &&
+	FAKE_LINES="1 2 3 sign 4" git rebase -i A &&
+	git show HEAD | grep "Signed-off-by:" &&
+	test $(git rev-parse master) != $(git rev-parse HEAD) &&
+	test $(git rev-parse master^) = $(git rev-parse HEAD^)
+'
+
 test_expect_success 'rebase -i can copy notes' '
 	git config notes.rewrite.rebase true &&
 	git config notes.rewriteRef "refs/notes/*" &&
-- 
2.9.2.518.ged577c6.dirty


^ permalink raw reply related	[flat|nested] 11+ messages in thread

* Re: [RFC/PATCH] rebase--interactive: Add "sign" command
  2016-08-03  8:47 [RFC/PATCH] rebase--interactive: Add "sign" command Chris Packham
@ 2016-08-03 14:31 ` Johannes Schindelin
  2016-08-03 15:19   ` Johannes Schindelin
                     ` (2 more replies)
  2016-08-03 15:58 ` Junio C Hamano
  1 sibling, 3 replies; 11+ messages in thread
From: Johannes Schindelin @ 2016-08-03 14:31 UTC (permalink / raw)
  To: Chris Packham; +Cc: git

Hi Chris,

On Wed, 3 Aug 2016, Chris Packham wrote:

> This is similar to the existing "reword" command in that it can be used
> to update the commit message the difference is that the editor presented
> to the user for the commit. It provides a useful shorthand for "exec git
> commit --amend --no-edit -s"

I can understand how this "sign" command helps you. I myself wished for
new commands when working on my Git garden shears [*1*] (essentially, what
git rebase --interactive --preserve-merges *should* have been).

My solution was to introduce a new fake editor that calls the real editor
and afterwards converts the "new" commands into exec lines.

Having said that, this patch clashes seriously with my current effort to
move a lot of the interactive rebase from shell into plain C. It is
actually ready, but getting this into the code base is really slow-going,
unfortunately.

Now, after looking at your patch it looks to me as if this would be easily
ported, so there is not a big deal here.

However, I could imagine that we actually want this to be more extensible.
After all, all you are doing is to introduce a new rebase -i command that
does nothing else than shelling out to a command. Why not introduce a much
more flexible feature, where you add something like "rebase -i aliases"?

Maybe something like this:

[rebase "command"]
	sign = git commit --amend -s --no-post-rewrite --no-edit -S

I have not completely thought this through, but maybe this direction would
make the interactive rebase even more powerful?

Ciao,
Johannes

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [RFC/PATCH] rebase--interactive: Add "sign" command
  2016-08-03 14:31 ` Johannes Schindelin
@ 2016-08-03 15:19   ` Johannes Schindelin
  2016-08-03 16:08   ` Junio C Hamano
  2016-08-04  0:41   ` Chris Packham
  2 siblings, 0 replies; 11+ messages in thread
From: Johannes Schindelin @ 2016-08-03 15:19 UTC (permalink / raw)
  To: Chris Packham; +Cc: git

Hi Chris,

On Wed, 3 Aug 2016, Johannes Schindelin wrote:

> I can understand how this "sign" command helps you. I myself wished for
> new commands when working on my Git garden shears [*1*] (essentially, what
> git rebase --interactive --preserve-merges *should* have been).

And of course I forgot to provide the footnote. Sigh. So here they are,
the Git garden shears, intended to rebase a thicket of branches:

https://github.com/git-for-windows/build-extra/blob/master/shears.sh

The edit script will look somewhat like this:

	mark onto

	# branch "something"
	bud
	pick abcdef first commit
	pick abcde0 second commit
	mark something

	# branch "another-one"
	bud
	pick cafebabe yep, that's a different branch
	mark another-one

	bud
	merge -C 0123456 something
	merge -C 6543210 another-one

	cleanup something another-one

So you see, I needed to introduce new commands: bud, mark, merge and
cleanup (I actually also added a "reset" one).

The fake editor I talked about is really the script itself, which detects
that it was run as the fake editor, and which converts all those commands
into the form "exec git .r <command> <parameters>...". The alias..r
setting also points to the same script, so that I really only need one
script. It's one big hack, but it works.

Needless to say, my idea to support new rebase -i commands via config
settings would be something I would use myself in the Git garden shears.

Ciao,
Johannes

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [RFC/PATCH] rebase--interactive: Add "sign" command
  2016-08-03  8:47 [RFC/PATCH] rebase--interactive: Add "sign" command Chris Packham
  2016-08-03 14:31 ` Johannes Schindelin
@ 2016-08-03 15:58 ` Junio C Hamano
  1 sibling, 0 replies; 11+ messages in thread
From: Junio C Hamano @ 2016-08-03 15:58 UTC (permalink / raw)
  To: Chris Packham; +Cc: git

Chris Packham <judge.packham@gmail.com> writes:

> This is similar to the existing "reword" command in that it can be used
> to update the commit message the difference is that the editor presented
> to the user for the commit. It provides a useful shorthand for "exec git
> commit --amend --no-edit -s"

Hmm, what should those who want to amend and sign do, though?

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [RFC/PATCH] rebase--interactive: Add "sign" command
  2016-08-03 14:31 ` Johannes Schindelin
  2016-08-03 15:19   ` Johannes Schindelin
@ 2016-08-03 16:08   ` Junio C Hamano
  2016-08-03 16:15     ` Johannes Schindelin
  2016-08-03 18:08     ` Jeff King
  2016-08-04  0:41   ` Chris Packham
  2 siblings, 2 replies; 11+ messages in thread
From: Junio C Hamano @ 2016-08-03 16:08 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Chris Packham, git

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> ... my Git garden shears [*1*] (essentially, what
> git rebase --interactive --preserve-merges *should* have been).

Any plan to fold it into "git rebase -i" as a new (improved) mode of
operation, by the way?

> However, I could imagine that we actually want this to be more extensible.
> After all, all you are doing is to introduce a new rebase -i command that
> does nothing else than shelling out to a command.

Yup, I tend to agree.

Adding "sign" feature (i.e. make it pass -S to "commit [--amend]")
may be a good thing, but adding "sign" command to do so is not a
great design.

There is no inherent reason why "sign" feature implies "--no-edit",
and adding a "sign" command like this patch means that the next
command somebody else proposes will be "sign-and-reword".

We should be able to treat Signing and Rewording as two orthogonal
features, one that passes -S, and the other that refrains from
passing --no-edit.  Otherwise as the number of features grow, the
number of commands will see combinatorial growth.

Thanks.



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [RFC/PATCH] rebase--interactive: Add "sign" command
  2016-08-03 16:08   ` Junio C Hamano
@ 2016-08-03 16:15     ` Johannes Schindelin
  2016-08-03 18:08     ` Jeff King
  1 sibling, 0 replies; 11+ messages in thread
From: Johannes Schindelin @ 2016-08-03 16:15 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Chris Packham, git

Hi Junio,

On Wed, 3 Aug 2016, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > ... my Git garden shears [*1*] (essentially, what
> > git rebase --interactive --preserve-merges *should* have been).
> 
> Any plan to fold it into "git rebase -i" as a new (improved) mode of
> operation, by the way?

It was my plan to integrate it into the sequencer, once the rebase--helper
landed in `master`. Little did I know how long it would take to get this
done...

My loose idea was to deprecate --preserve-merges after introducing a
--recreate-branches, or some such. But enough of that. The rebase--helper
needs to get here first.

> > However, I could imagine that we actually want this to be more extensible.
> > After all, all you are doing is to introduce a new rebase -i command that
> > does nothing else than shelling out to a command.
> 
> Yup, I tend to agree.

Awesome!

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [RFC/PATCH] rebase--interactive: Add "sign" command
  2016-08-03 16:08   ` Junio C Hamano
  2016-08-03 16:15     ` Johannes Schindelin
@ 2016-08-03 18:08     ` Jeff King
  2016-08-04  0:53       ` Chris Packham
                         ` (2 more replies)
  1 sibling, 3 replies; 11+ messages in thread
From: Jeff King @ 2016-08-03 18:08 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Michael Haggerty, Johannes Schindelin, Chris Packham, git

On Wed, Aug 03, 2016 at 09:08:48AM -0700, Junio C Hamano wrote:

> > However, I could imagine that we actually want this to be more extensible.
> > After all, all you are doing is to introduce a new rebase -i command that
> > does nothing else than shelling out to a command.
> 
> Yup, I tend to agree.
> 
> Adding "sign" feature (i.e. make it pass -S to "commit [--amend]")
> may be a good thing, but adding "sign" command to do so is not a
> great design.

I'm not sure what you mean by "feature" here, but it reminded me of
Michael's proposal to allow options to todo lines:

  http://public-inbox.org/git/530DA00E.4090402@alum.mit.edu/

which would allow:

  pick -S 1234abcd

If that's what you meant, I think it is a good idea. :)

-Peff

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [RFC/PATCH] rebase--interactive: Add "sign" command
  2016-08-03 14:31 ` Johannes Schindelin
  2016-08-03 15:19   ` Johannes Schindelin
  2016-08-03 16:08   ` Junio C Hamano
@ 2016-08-04  0:41   ` Chris Packham
  2 siblings, 0 replies; 11+ messages in thread
From: Chris Packham @ 2016-08-04  0:41 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: GIT

On Thu, Aug 4, 2016 at 2:31 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi Chris,
>
> On Wed, 3 Aug 2016, Chris Packham wrote:
>
>> This is similar to the existing "reword" command in that it can be used
>> to update the commit message the difference is that the editor presented
>> to the user for the commit. It provides a useful shorthand for "exec git
>> commit --amend --no-edit -s"

<snip>

> Having said that, this patch clashes seriously with my current effort to
> move a lot of the interactive rebase from shell into plain C. It is
> actually ready, but getting this into the code base is really slow-going,
> unfortunately.
>
> Now, after looking at your patch it looks to me as if this would be easily
> ported, so there is not a big deal here.

Yeah sorry. I knew there was something in flight but ended up doing a
quick hack on top of master.

> However, I could imagine that we actually want this to be more extensible.
> After all, all you are doing is to introduce a new rebase -i command that
> does nothing else than shelling out to a command. Why not introduce a much
> more flexible feature, where you add something like "rebase -i aliases"?
>
> Maybe something like this:
>
> [rebase "command"]
>         sign = git commit --amend -s --no-post-rewrite --no-edit -S

I did briefly consider that. I ended up taking the shortcut because I
had a patch series I needed to sign.

Elsewhere in this thread the idea of pick -S or reword -S was raised.
I'd actually prefer that because there seems little between 'git
config rebase.command.sign blah' and 'exec ~/sign.sh'

> I have not completely thought this through, but maybe this direction would
> make the interactive rebase even more powerful?

The uses I can think of are adding sign-off and running "make check".
For me rebase -i doesn't need to be much more powerful than that.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [RFC/PATCH] rebase--interactive: Add "sign" command
  2016-08-03 18:08     ` Jeff King
@ 2016-08-04  0:53       ` Chris Packham
  2016-08-04 16:05       ` Junio C Hamano
  2016-08-05 16:04       ` Johannes Schindelin
  2 siblings, 0 replies; 11+ messages in thread
From: Chris Packham @ 2016-08-04  0:53 UTC (permalink / raw)
  To: Jeff King; +Cc: Junio C Hamano, Michael Haggerty, Johannes Schindelin, GIT

On Thu, Aug 4, 2016 at 6:08 AM, Jeff King <peff@peff.net> wrote:
> On Wed, Aug 03, 2016 at 09:08:48AM -0700, Junio C Hamano wrote:
>
>> > However, I could imagine that we actually want this to be more extensible.
>> > After all, all you are doing is to introduce a new rebase -i command that
>> > does nothing else than shelling out to a command.
>>
>> Yup, I tend to agree.
>>
>> Adding "sign" feature (i.e. make it pass -S to "commit [--amend]")
>> may be a good thing, but adding "sign" command to do so is not a
>> great design.
>
> I'm not sure what you mean by "feature" here, but it reminded me of
> Michael's proposal to allow options to todo lines:
>
>   http://public-inbox.org/git/530DA00E.4090402@alum.mit.edu/
>
> which would allow:
>
>   pick -S 1234abcd
>
> If that's what you meant, I think it is a good idea. :)

That would definitely suit me. I see there was some discussion of
which options were sensible to support. --signoff and --reset-author
would be a good start from my point of view. Maybe that's something
that could be build on top of Johannes work.

>
> -Peff

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [RFC/PATCH] rebase--interactive: Add "sign" command
  2016-08-03 18:08     ` Jeff King
  2016-08-04  0:53       ` Chris Packham
@ 2016-08-04 16:05       ` Junio C Hamano
  2016-08-05 16:04       ` Johannes Schindelin
  2 siblings, 0 replies; 11+ messages in thread
From: Junio C Hamano @ 2016-08-04 16:05 UTC (permalink / raw)
  To: Jeff King; +Cc: Michael Haggerty, Johannes Schindelin, Chris Packham, git

Jeff King <peff@peff.net> writes:

> On Wed, Aug 03, 2016 at 09:08:48AM -0700, Junio C Hamano wrote:
>
>> > However, I could imagine that we actually want this to be more extensible.
>> > After all, all you are doing is to introduce a new rebase -i command that
>> > does nothing else than shelling out to a command.
>> 
>> Yup, I tend to agree.
>> 
>> Adding "sign" feature (i.e. make it pass -S to "commit [--amend]")
>> may be a good thing, but adding "sign" command to do so is not a
>> great design.
>
> I'm not sure what you mean by "feature" here, but it reminded me of
> Michael's proposal to allow options to todo lines:
>
>   http://public-inbox.org/git/530DA00E.4090402@alum.mit.edu/
>
> which would allow:
>
>   pick -S 1234abcd
>
> If that's what you meant, I think it is a good idea. :)

Yes, by "feature" I meant "giving the ability to decide if the
resulting commit gets signature", which can and should be orthogonal
to the choice of using editor to reword the message when the commit
is created or "--no-edit" is passed and the original message is used
verbatim.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [RFC/PATCH] rebase--interactive: Add "sign" command
  2016-08-03 18:08     ` Jeff King
  2016-08-04  0:53       ` Chris Packham
  2016-08-04 16:05       ` Junio C Hamano
@ 2016-08-05 16:04       ` Johannes Schindelin
  2 siblings, 0 replies; 11+ messages in thread
From: Johannes Schindelin @ 2016-08-05 16:04 UTC (permalink / raw)
  To: Jeff King; +Cc: Junio C Hamano, Michael Haggerty, Chris Packham, git

Hi Peff,

On Wed, 3 Aug 2016, Jeff King wrote:

> On Wed, Aug 03, 2016 at 09:08:48AM -0700, Junio C Hamano wrote:
> 
> > > However, I could imagine that we actually want this to be more
> > > extensible.  After all, all you are doing is to introduce a new
> > > rebase -i command that does nothing else than shelling out to a
> > > command.
> > 
> > Yup, I tend to agree.
> > 
> > Adding "sign" feature (i.e. make it pass -S to "commit [--amend]") may
> > be a good thing, but adding "sign" command to do so is not a great
> > design.
> 
> I'm not sure what you mean by "feature" here, but it reminded me of
> Michael's proposal to allow options to todo lines:
> 
>   http://public-inbox.org/git/530DA00E.4090402@alum.mit.edu/
> 
> which would allow:
> 
>   pick -S 1234abcd
> 
> If that's what you meant, I think it is a good idea. :)

I looked at the code in git-rebase--interactive.sh again and stumbled over
something important: if you "pick" a commit, it *already* uses the
information provided to the rebase command via the -S option, *unless* the
pick fast-forwards.

That is, I came to believe that the "sign" command is unnecessary, and
that the --force-rebase option in conjunction with the -S option is what
should be used.

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2016-08-05 16:05 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-08-03  8:47 [RFC/PATCH] rebase--interactive: Add "sign" command Chris Packham
2016-08-03 14:31 ` Johannes Schindelin
2016-08-03 15:19   ` Johannes Schindelin
2016-08-03 16:08   ` Junio C Hamano
2016-08-03 16:15     ` Johannes Schindelin
2016-08-03 18:08     ` Jeff King
2016-08-04  0:53       ` Chris Packham
2016-08-04 16:05       ` Junio C Hamano
2016-08-05 16:04       ` Johannes Schindelin
2016-08-04  0:41   ` Chris Packham
2016-08-03 15:58 ` Junio C Hamano

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.