Feature request: --signoff

[emilazy]

git-rebase(1) has this:

--signoff

Add a Signed-off-by: trailer to all the rebased commits. Note that if --interactive is given then only commits marked to be picked, edited or reworded will have the trailer added.

[mystor]

I'm not sure what the behaviour of this flag should be when not running with --interactive. Given a commit stack like:

(HEAD) A
B
C
D

Would you expect git revise --signoff C to add the Signed-off-by: trailer to C, or both A and B? I'm leaning towards the A and B interpretation, but I'm not sure.

[alerque]

I would lean towards A, B, and C.

[mystor]

That would be different behaviour than git rebase --signoff, or git revise --interactive --signoff, though. As it would also change the boundary commit. I think that would be a bit surprising

[alerque]

Git's rebase takes an argument of the new base commit, it doesn't do anything to the base commit — only the commits ot top of that one. Git revise acts directly on the commit you specify: git revise -r HEAD^ rewords HEAD~1 not HEAD~2. On the other hand if I wanted to reword a commit with rebase it would have to be git rebase -i HEAD^^, which would allow me do change the todo item for HEAD^.

[emilazy]

I feel like there's a conflict between how the rebase and revise UI work here; I sort of expect git revise --signoff X to only add a Signed-off-by line to X itself, but in practice I suspect the most useful thing would usually be to use it to sign off multiple commits as a batch operation.

For instance, I have a work-in-progress batch commit-signing script that does git rebase --force-rebase --gpg-sign <base-rev>, and I can imagine wanting to incorporate signoffs into it; a lot of the complexity is in just automatically picking a good base commit. Being able to use git-revise's smarts for this would be great (though would require #46), but it's inconsistent with how it usually acts when you don't specify --interactive. So I'm not sure what the best interface would be; it's the usual git tension between treating commits as linked snapshots vs. as standalone patches...

[mystor]

git revise effectively runs in one of two modes, sort-of like git rebase: either "interactive" mode or "non-interactive" mode. In the "interactive" mode, the parameter is used as the base commit, and changes are performed on commits following it, and in "non-interactive" mode, only the named commit is updated.

Currently revise runs in "interactive" mode if either the --autosquash or --interactive flags are passed, and otherwise runs in "non-interactive" mode.

I think this question comes down to whether or not --signoff should implicitly put git revise into "interactive" mode, like --autosquash does. If we don't switch into "interactive" mode, I would expect only the passed commit to be updated, while if we do, I would expect everything after the passed commit to be updated.

(On a side note, I should probably document this better, and come up with better names for the modes. Perhaps "batch" mode and "target" mode?)