martinvonz / jj

A Git-compatible VCS that is both simple and powerful
https://martinvonz.github.io/jj/
Apache License 2.0
8.56k stars 293 forks source link

FR: add "signed-off-by" line #1399

Open yshui opened 1 year ago

yshui commented 1 year ago

Description

Support adding a Signed-off-by: Name <Email> line at the end of the commit message, like git commit -s.

Maybe even make this configurable footer.

martinvonz commented 1 year ago

Out of curiosity, which project do you work on that uses such footers? I've only heard of them being used in the Git project. Oh, the Linux kernel uses them too, of course.

Maybe even make this configurable footer.

Yes, probably. My feeling is that they're too specific to a few particular projects to deserve special treatment. I'm curious what others think.

Another option is to create an alias for it. Something like this:

$ grep signoff ~/.jjconfig.toml
aliases.signoff = ["--config-toml=ui.editor='<path to $HOME>/signoff.sh'", "describe"]
$ cat ~/signoff.sh
#!/bin/bash

echo "Signed-off-by: Martin von Zweigbergk <martinvonz@google.com>" >> "$1"
joyously commented 1 year ago

Ooo, I like the alias since it's versatile. Somewhat related is a plugin that does fast-import I've seen. I don't know if the plugin put the SVN revision number into the Git description, or what, but it was very useful for back-tracking (and also for gauging where you are in the history since they are sequential in SVN). I'm saying it could be useful to be able to add to the description from a hook, such as import.

yshui commented 1 year ago

Out of curiosity, which project do you work on that uses such footers?

I do this with my own projects out of habit. It's also a good way to attribute everyone involved in a commit.

omasanori commented 1 year ago

The alias is so helpful to me, thanks a lot! I use a modified version below, as I use different user.email for different projects.

#!/bin/sh

echo "Signed-off-by: $(jj config get user.name) <$(jj config get user.email)>" >> "$1"

I've only heard of them being used in the Git project. Oh, the Linux kernel uses them too, of course.

My feeling is that they're too specific to a few particular projects to deserve special treatment. I'm curious what others think.

For reference, DCO has been adopted by Arm Trusted Firmware-A, Chef, Collabora Online, Coreboot, FreeBSD, GCC, ISC Kea, Lustre, Node.js, OpenUI5, U-boot, Xilinx Runtime, among others.

martinvonz commented 1 year ago

Thanks for the pointers. That's quite a few large projects. I still don't really like the idea of commands and flags for such specialized features. Maybe a new footer becomes more popular in a few years. Do we add another flag for that then? Or if the "Signed-off-by:" footer falls out of fashion, then we're stuck with a useless flag (depending on what our compatibility policy is then). So maybe we instead have a --add-signature/-s that adds a configurable footer instead. What do you (and others) think?

omasanori commented 1 year ago

I still don't really like the idea of commands and flags for such specialized features. Maybe a new footer becomes more popular in a few years. Do we add another flag for that then? Or if the "Signed-off-by:" footer falls out of fashion, then we're stuck with a useless flag (depending on what our compatibility policy is then).

Agreed. GitHub has a support for Co-authored-by: and Linux kernel uses Acked-by:, Co-developed-by:, Reported-by:, Tested-by:, Reviewed-by:, and Suggested-by:. Configurable footer is clearly better to me.

martinvonz commented 1 year ago

What do you think the interface for this feature should be? A new command? A flag on commit (but maybe you want to add the signature to an existing commit) or describe? If we put it on describe, then the user will probably usually also want --no-edit, but making it implied also seems surprising. I suppose we could have both a add-signature command an a describe --add-signature flag?

omasanori commented 1 year ago

How about making the commit message boilerplate configurable with a template? Adding a line afterward is implementable with an alias as you've shown.

martinvonz commented 1 year ago

That sounds like #1354. To make sure I understand correctly, what would you put in your template?

omasanori commented 1 year ago

In my case,

Signed-off-by: (the value of user.name) <(the value of user.email)>

but interpolation of configuration values is optional if a template can be set per-repo. (Inconvenient a bit, though.)

martinvonz commented 1 year ago

So it's mostly #1354 that you'd need then, right? Do you feel like working on that? We'd appreciate it :)

omasanori commented 1 year ago

Aha, yes. Not a promise but I will try. Thanks for suggestion!

avamsi commented 1 year ago

FYI: with #2062, you could add something like ui.default-description = "\n\nSigned-off-by: $name <$email>" to your config (it's just a string for now, so you'll have to repeat the values of name and email).

samhh commented 4 months ago

Chiming in to say that #2062 wouldn't satisfyingly cover my use case which is to sometimes but not always append "Co-authored-by" to commit messages for GitHub repos, typically in response to PR feedback or during pairing.

I currently (only just discovered Jujutsu) use a Git alias I wrote for this: https://github.com/samhh/dotfiles/blob/fad290da04f4d4f852ae2d85d65104809a26758d/home/vcs.nix#L61

The main part is:

git commit --amend --only -m "$(git log --format=%B -n1)" -m "$msg"

If I may dream for a moment, the prefix would be configurable for reuse:

[attributions]
co = "Co-authored-by"

And then somehow Jujutsu would figure out a neat way to let you select people like my script does, since I'm typically picking one or two of the same half a dozen people. Not sure how that interops with the signoff use case, mind.

Another way of looking at this is through pairing. It seems like we're conflating "commit author" and "machine user".

ErichDonGubler commented 2 months ago

One thing I wanted to add: If we're concerned about overly specialized CLI flags for specific trailers, we might consider a design like the -t/--trailer option in the git commit interface, which allows both (1) configuration of behavior when a "duplicate" trailer is specified and (2) avoids the question of "what if a new [better] option comes up", but only by taking on the complexity of something more flexible.