threads / rfc / 36899

RFC patchgit-am: support any number of signatures

Subject: [PATCH RFC] git-am: support any number of signatures

## tl;dr

31 messages between Jun 12, 2014 and Oct 14, 2014. Diffs are folded; open one to read it.

replies: 30people: 5as markdown or json

Michael S. Tsirkin· Jun 12, 2014, 16:12 UTC · lore

I'm using different signature tags for git am depending on the patch, project and other factors.

Sometimes I add multiple tags as well, e.g. QEMU wants both Reviewed-by and Signed-off-by tags.

This patch makes it easy to do so:
1.  new parameter am.signoff can be used any number
	of times:
[am]
	signoff = "Reviewed-by: Michael S. Tsirkin <mst@redhat.com>"
	signoff = "Signed-off-by: Michael S. Tsirkin <mst@redhat.com>"
	if set all signatures are picked up when git am -s is used.
2.  Any number of alternative signatures
[am "a"]
	signoff = "Acked-by: Michael S. Tsirkin <mst@redhat.com>"
	if set the signature type can be specified by passing
	a parameter to the -s flag:
	git am -sa

No docs or tests, sorry, so not yet ready for master, but I'm using this all the time without any issues so maybe ok for pu. Early flames/feedback/help welcome.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
 git-am.sh | 36 ++++++++++++++++++++++++++++--------
 1 file changed, 28 insertions(+), 8 deletions(-)
Show changes to git-am.sh +27 −8
diff --git a/git-am.sh b/git-am.sh
index ee61a77..e992c34 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -13,7 +13,7 @@ i,interactive   run interactively
 b,binary*       (historical option -- no-op)
 3,3way          allow fall back on 3way merging if needed
 q,quiet         be quiet
-s,signoff       add a Signed-off-by line to the commit message
+s,signoff?      add a Signed-off-by line to the commit message
 u,utf8          recode into utf8 (default)
 k,keep          pass -k flag to git-mailinfo
 keep-non-patch  pass -b flag to git-mailinfo
@@ -136,7 +136,7 @@ fall_back_3way () {
     eval "$cmd" &&
     GIT_INDEX_FILE="$dotest/patch-merge-tmp-index" \
     git write-tree >"$dotest/patch-merge-base+" ||
-    cannot_fallback "$(gettext "Repository lacks necessary blobs to fall back on 3-way merge.")"
+    cannot_fallback "$(gettext "Repository lsignoffs necessary blobs to fall back on 3-way merge.")"
 
     say "$(gettext "Using index info to reconstruct a base tree...")"
 
@@ -383,6 +383,7 @@ then
     keepcr=t
 fi
 
+signoffs=
 while test $# != 0
 do
 	case "$1" in
@@ -394,8 +395,15 @@ it will be removed. Please do not use it anymore."
 		;;
 	-3|--3way)
 		threeway=t ;;
-	-s|--signoff)
-		sign=t ;;
+	--signoff)
+		sign=t
+		s=$(git config --get-all am.signoff)
+		signoffs=("${signoffs[@]}" "${s[@]}") ;;
+	--signoff=*)
+		sign=t
+		a="${1#--signoff=}"
+		s=$(git config --get-all am."${a}".signoff)
+		signoffs=("${signoffs[@]}" "${s[@]}") ;;
 	-u|--utf8)
 		utf8=t ;; # this is now default
 	--no-utf8)
@@ -644,14 +652,25 @@ fi
 git_apply_opt=$(cat "$dotest/apply-opt")
 if test "$(cat "$dotest/sign")" = t
 then
-	SIGNOFF=$(git var GIT_COMMITTER_IDENT | sed -e '
-			s/>.*/>/
-			s/^/Signed-off-by: /'
-		)
+	for ack in "${signoffs[@]}"; do
+		if test "$SIGNOFF"
+		then
+			SIGNOFF="$SIGNOFF\n$ack"
+		else
+			SIGNOFF="$ack"
+		fi
+	done
+	if test -z "$SIGNOFF"
+	then
+		SIGNOFF=$(git var GIT_COMMITTER_IDENT | sed -e '
+				s/>.*/>/
+				s/^/Signed-off-by: /'
+			)
+	fi
 else
 	SIGNOFF=
 fi
 
 last=$(cat "$dotest/last")
 this=$(cat "$dotest/next")
 if test "$skip" = t
-- 
MST
Junio C Hamano· Jun 12, 2014, 19:07 UTC · re: Michael S. Tsirkin · lore

Re: [PATCH RFC] git-am: support any number of signatures

"Michael S. Tsirkin" <mst@redhat.com> writes:
Show 15 quoted lines
> I'm using different signature tags for git am depending on the patch,
> project and other factors.
>
> Sometimes I add multiple tags as well, e.g. QEMU
> wants both Reviewed-by and Signed-off-by tags.
>
> This patch makes it easy to do so:
> 1.  new parameter am.signoff can be used any number
> 	of times:
>
> [am]
> 	signoff = "Reviewed-by: Michael S. Tsirkin <mst@redhat.com>"
> 	signoff = "Signed-off-by: Michael S. Tsirkin <mst@redhat.com>"
>
> 	if set all signatures are picked up when git am -s is used.
How does this interact with the logic to avoid appending the same
Signed-off-by: line as the last one the incoming message already
has?
Show 13 quoted lines
> 2.  Any number of alternative signatures
>
> [am "a"]
> 	signoff = "Acked-by: Michael S. Tsirkin <mst@redhat.com>"
>
> 	if set the signature type can be specified by passing
> 	a parameter to the -s flag:
>
> 	git am -sa
>
> No docs or tests, sorry, so not yet ready for master, but I'm using this
> all the time without any issues so maybe ok for pu.
> Early flames/feedback/help welcome.

How does that "a" in [am "a"] work? If it defines some kind of scope (i.e. use am.a.* instead of am.* when I specify I am using "a" set somehow), that might be something interesting, but if it applies only to sign-off and other things, then I am not sure if I like it, as that would invite confusions from end users.

> +		signoffs=("${signoffs[@]}" "${s[@]}") ;;

Is this a shell array? It won't fly in our codebase if that is the case.

Michael S. Tsirkin· Jun 13, 2014, 08:00 UTC · re: Junio C Hamano · lore

Re: [PATCH RFC] git-am: support any number of signatures

On Thu, Jun 12, 2014 at 12:07:03PM -0700, Junio C Hamano wrote:
Show 21 quoted lines
> "Michael S. Tsirkin" <mst@redhat.com> writes:
> 
> > I'm using different signature tags for git am depending on the patch,
> > project and other factors.
> >
> > Sometimes I add multiple tags as well, e.g. QEMU
> > wants both Reviewed-by and Signed-off-by tags.
> >
> > This patch makes it easy to do so:
> > 1.  new parameter am.signoff can be used any number
> > 	of times:
> >
> > [am]
> > 	signoff = "Reviewed-by: Michael S. Tsirkin <mst@redhat.com>"
> > 	signoff = "Signed-off-by: Michael S. Tsirkin <mst@redhat.com>"
> >
> > 	if set all signatures are picked up when git am -s is used.
> 
> How does this interact with the logic to avoid appending the same
> Signed-off-by: line as the last one the incoming message already
> has?

Not handled if you have multiple signatures. That will have to be fixed. Do we only care about the last line?

Signed-off-by: A
Signed-off-by: B
do we want to add
Signed-off-by: A
or would it be better to replace with
Signed-off-by: B
Signed-off-by: A
?

Current git am will add A twice, I wonder if this is a feature or a bug.

Show 24 quoted lines
> > 2.  Any number of alternative signatures
> >
> > [am "a"]
> > 	signoff = "Acked-by: Michael S. Tsirkin <mst@redhat.com>"
> >
> > 	if set the signature type can be specified by passing
> > 	a parameter to the -s flag:
> >
> > 	git am -sa
> >
> > No docs or tests, sorry, so not yet ready for master, but I'm using this
> > all the time without any issues so maybe ok for pu.
> > Early flames/feedback/help welcome.
> 
> How does that "a" in [am "a"] work?  If it defines some kind of
> scope (i.e. use am.a.* instead of am.* when I specify I am using "a"
> set somehow), that might be something interesting, but if it applies
> only to sign-off and other things, then I am not sure if I like it,
> as that would invite confusions from end users.
> 
> > +		signoffs=("${signoffs[@]}" "${s[@]}") ;;
> 
> Is this a shell array?  It won't fly in our codebase if that is the
> case.
Junio C Hamano· Jun 13, 2014, 17:32 UTC · re: Michael S. Tsirkin · lore

Re: [PATCH RFC] git-am: support any number of signatures

"Michael S. Tsirkin" <mst@redhat.com> writes:
Show 35 quoted lines
> On Thu, Jun 12, 2014 at 12:07:03PM -0700, Junio C Hamano wrote:
>> "Michael S. Tsirkin" <mst@redhat.com> writes:
>> ...
>> > 1.  new parameter am.signoff can be used any number
>> > 	of times:
>> >
>> > [am]
>> > 	signoff = "Reviewed-by: Michael S. Tsirkin <mst@redhat.com>"
>> > 	signoff = "Signed-off-by: Michael S. Tsirkin <mst@redhat.com>"
>> >
>> > 	if set all signatures are picked up when git am -s is used.
>> 
>> How does this interact with the logic to avoid appending the same
>> Signed-off-by: line as the last one the incoming message already
>> has?
>
> Not handled if you have multiple signatures.
> That will have to be fixed.
> Do we only care about the last line?
>
> Signed-off-by: A
> Signed-off-by: B
>
> do we want to add
>
> Signed-off-by: A
>
> or would it be better to replace with
> Signed-off-by: B
> Signed-off-by: A
>
> ?
>
> Current git am will add A twice, I wonder if this is
> a feature or a bug.
This is very much deliberate.

Appending A after existing A and B is meant to record that the patch originated from A, passed thru B possibly with changes by B, came back to A who wants to assert that the result is still under DCO.

The only case we can safely omit appending A's sign-off is when the last one in the chain is by A. Imagine that you had a patch signed off by B, which A may have tweaked and forwarded under DCO with A's sign-off. Such a patch would have sign-off chain B-A.

Now A makes further changes to the patch and says "the further change is also something I am authorized to release as open source" with the "-s" option or some other way. It would not change that A can contribute under DCO if we did not add an extra A after existing B-A sign-off chain in that case.

Michael S. Tsirkin· Jun 15, 2014, 10:27 UTC · re: Junio C Hamano · lore

Re: [PATCH RFC] git-am: support any number of signatures

On Fri, Jun 13, 2014 at 10:32:09AM -0700, Junio C Hamano wrote:
Show 54 quoted lines
> "Michael S. Tsirkin" <mst@redhat.com> writes:
> 
> > On Thu, Jun 12, 2014 at 12:07:03PM -0700, Junio C Hamano wrote:
> >> "Michael S. Tsirkin" <mst@redhat.com> writes:
> >> ...
> >> > 1.  new parameter am.signoff can be used any number
> >> > 	of times:
> >> >
> >> > [am]
> >> > 	signoff = "Reviewed-by: Michael S. Tsirkin <mst@redhat.com>"
> >> > 	signoff = "Signed-off-by: Michael S. Tsirkin <mst@redhat.com>"
> >> >
> >> > 	if set all signatures are picked up when git am -s is used.
> >> 
> >> How does this interact with the logic to avoid appending the same
> >> Signed-off-by: line as the last one the incoming message already
> >> has?
> >
> > Not handled if you have multiple signatures.
> > That will have to be fixed.
> > Do we only care about the last line?
> >
> > Signed-off-by: A
> > Signed-off-by: B
> >
> > do we want to add
> >
> > Signed-off-by: A
> >
> > or would it be better to replace with
> > Signed-off-by: B
> > Signed-off-by: A
> >
> > ?
> >
> > Current git am will add A twice, I wonder if this is
> > a feature or a bug.
> 
> This is very much deliberate.
> 
> Appending A after existing A and B is meant to record that the patch
> originated from A, passed thru B possibly with changes by B, came
> back to A who wants to assert that the result is still under DCO.
> 
> The only case we can safely omit appending A's sign-off is when the
> last one in the chain is by A.  Imagine that you had a patch signed
> off by B, which A may have tweaked and forwarded under DCO with A's
> sign-off.  Such a patch would have sign-off chain B-A.
> 
> Now A makes further changes to the patch and says "the further
> change is also something I am authorized to release as open source"
> with the "-s" option or some other way.  It would not change that A
> can contribute under DCO if we did not add an extra A after existing
> B-A sign-off chain in that case.

OK imagine we have signatures: A B

Now A wants to sign this patch.
I think there are two reasonable ways to behave:
1. What you describe above:
A
B
A
2. For things like Tested-by: tags, removing tag from
where it was and adding it at the bottom:

B A

This probably calls for a separate feature: maybe adding "acks" along with "signoffs"? acks would be unique, re-adding ack removes it from the message and adds at the bottom.

-- 
MST
Junio C Hamano· Jun 16, 2014, 18:06 UTC · re: Michael S. Tsirkin · lore

Re: [PATCH RFC] git-am: support any number of signatures

"Michael S. Tsirkin" <mst@redhat.com> writes:
Show 7 quoted lines
> Now A wants to sign this patch.
>
> I think there are two reasonable ways to behave:
> 1. What you describe above:
> A
> B
> A
That is the only sensible thing to do for Signed-off-by footers.
Show 5 quoted lines
> 2. For things like Tested-by: tags, removing tag from
> where it was and adding it at the bottom:
>
> B
> A

You can make it arbitrarily more complex. A sends with sign-off, B tweaks and tests *that* version and forwards with sign-off, A further tweaks, which may invalidate the earlier tests, so A asks B to retest and then forward it to Linus when everything checks out.

What should the end result look like?
	SoB: A
	SoB: B
        Tested-by: B
        SoB: A
        Tested-by: B
	SoB: B
perhaps?
> This probably calls for a separate feature:
> maybe adding "acks" along with "signoffs"?
> acks would be unique, re-adding ack removes it from
> the message and adds at the bottom.

This kind of complication is mostly up to the policies of the projects that are users of Git, and not something we as the Git project want to set in stone inside "git am" implementation.

Perhaps consult what has been discussed on Christian's "trailer" series in the list archive and then think about how to integrate / make use of it inside "am"?

Michael S. Tsirkin· Jun 18, 2014, 03:09 UTC · re: Junio C Hamano · lore

Re: [PATCH RFC] git-am: support any number of signatures

On Mon, Jun 16, 2014 at 11:06:20AM -0700, Junio C Hamano wrote:
Show 11 quoted lines
> "Michael S. Tsirkin" <mst@redhat.com> writes:
> 
> > Now A wants to sign this patch.
> >
> > I think there are two reasonable ways to behave:
> > 1. What you describe above:
> > A
> > B
> > A
> 
> That is the only sensible thing to do for Signed-off-by footers.

OK, after looking into this for a while, I realize this is a special property of the Signed-off-by footer. For now I think it's reasonable to just avoid de-duplicating other footers if any. Agree?

To have it apply to other footers, will have to implement ^[A-Z]*-by: logic that I have implemented for sendemail, in am as well. I'll get back to that, but I think it's separate from this feature.

-- 
MST
Junio C Hamano· Jun 18, 2014, 06:49 UTC · re: Michael S. Tsirkin · lore

Re: [PATCH RFC] git-am: support any number of signatures

On Tue, Jun 17, 2014 at 8:09 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
Show 5 quoted lines
>
> OK, after looking into this for a while, I realize
> this is a special property of the Signed-off-by footer.
> For now I think it's reasonable to just avoid de-duplicating
> other footers if any. Agree?

Not really. I'd rather see "git am" hardcode as little such policy as possible. We do need to support S-o-b footer and the policy we defined for it long time ago, if only for backward compatiblity, but for any other footers, policy decision such as "dedup by default" isn't something "am" should know about.

Michael S. Tsirkin· Jun 18, 2014, 07:33 UTC · re: Junio C Hamano · lore

Re: [PATCH RFC] git-am: support any number of signatures

On Tue, Jun 17, 2014 at 11:49:11PM -0700, Junio C Hamano wrote:
Show 12 quoted lines
> On Tue, Jun 17, 2014 at 8:09 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> > OK, after looking into this for a while, I realize
> > this is a special property of the Signed-off-by footer.
> > For now I think it's reasonable to just avoid de-duplicating
> > other footers if any. Agree?
> 
> Not really. I'd rather see "git am" hardcode as little such policy as possible.
> We do need to support S-o-b footer and the policy we defined for it long time
> ago, if only for backward compatiblity, but for any other footers,
> policy decision
> such as "dedup by default" isn't something "am" should know about.

OK happily that's exactly what v2 that I just posted does. Default S-o-b footer gets the existing policy. Any other footers are added on top without any tricky deduplication.

-- 
MST
Junio C Hamano· Jun 18, 2014, 17:51 UTC · re: Junio C Hamano · lore

Re: [PATCH RFC] git-am: support any number of signatures

Junio C Hamano <gitster@pobox.com> writes:
Show 12 quoted lines
> On Tue, Jun 17, 2014 at 8:09 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
>>
>> OK, after looking into this for a while, I realize
>> this is a special property of the Signed-off-by footer.
>> For now I think it's reasonable to just avoid de-duplicating
>> other footers if any. Agree?
>
> Not really. I'd rather see "git am" hardcode as little such policy as possible.
> We do need to support S-o-b footer and the policy we defined for it long time
> ago, if only for backward compatiblity, but for any other footers,
> policy decision
> such as "dedup by default" isn't something "am" should know about.

By the way, "append without looking for dups" is a policy decision that is as bad to have as "append with dedup".

I'd rather not to see "am.signoff", or any name that implies what the "-s" option to the command is about for that matter, to be used in futzing with the trailers other than S-o-b in any way. As I understand it, our longer term goal is to defer that task, including the user-programmable policy decisions, to something like the 'trailer' Christian started.

I suspect that it may add unnecessary work later if we overloaded "signoff" with a similar feature with the change under discussion. I would feel safer to see it outlined how we envision to transition to a more generic 'trailer' solution later if we were to enhance "am" with "am.signoff" now.

Thanks.
Michael S. Tsirkin· Jun 18, 2014, 18:23 UTC · re: Junio C Hamano · lore

Re: [PATCH RFC] git-am: support any number of signatures

On Wed, Jun 18, 2014 at 10:51:04AM -0700, Junio C Hamano wrote:
Show 32 quoted lines
> Junio C Hamano <gitster@pobox.com> writes:
> 
> > On Tue, Jun 17, 2014 at 8:09 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> >>
> >> OK, after looking into this for a while, I realize
> >> this is a special property of the Signed-off-by footer.
> >> For now I think it's reasonable to just avoid de-duplicating
> >> other footers if any. Agree?
> >
> > Not really. I'd rather see "git am" hardcode as little such policy as possible.
> > We do need to support S-o-b footer and the policy we defined for it long time
> > ago, if only for backward compatiblity, but for any other footers,
> > policy decision
> > such as "dedup by default" isn't something "am" should know about.
> 
> By the way, "append without looking for dups" is a policy decision
> that is as bad to have as "append with dedup".
> 
> I'd rather not to see "am.signoff", or any name that implies what
> the "-s" option to the command is about for that matter, to be used
> in futzing with the trailers other than S-o-b in any way.  As I
> understand it, our longer term goal is to defer that task, including
> the user-programmable policy decisions, to something like the
> 'trailer' Christian started.
> 
> I suspect that it may add unnecessary work later if we overloaded
> "signoff" with a similar feature with the change under discussion.
> I would feel safer to see it outlined how we envision to transition
> to a more generic 'trailer' solution later if we were to enhance
> "am" with "am.signoff" now.
> 
> Thanks.

I'll need to look at trailers, if indeed they are a superset of this functionality, I will transition to trailers when they land on master. In this case seems easier for me to keep this out tree patch for now, Good thing I didn't spend time writing docs and tests :)

-- 
MST
Michael S. Tsirkin· Sep 22, 2014, 14:01 UTC · re: Junio C Hamano · lore

Re: [PATCH RFC] git-am: support any number of signatures

On Wed, Jun 18, 2014 at 10:51:04AM -0700, Junio C Hamano wrote:
Show 32 quoted lines
> Junio C Hamano <gitster@pobox.com> writes:
> 
> > On Tue, Jun 17, 2014 at 8:09 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> >>
> >> OK, after looking into this for a while, I realize
> >> this is a special property of the Signed-off-by footer.
> >> For now I think it's reasonable to just avoid de-duplicating
> >> other footers if any. Agree?
> >
> > Not really. I'd rather see "git am" hardcode as little such policy as possible.
> > We do need to support S-o-b footer and the policy we defined for it long time
> > ago, if only for backward compatiblity, but for any other footers,
> > policy decision
> > such as "dedup by default" isn't something "am" should know about.
> 
> By the way, "append without looking for dups" is a policy decision
> that is as bad to have as "append with dedup".
> 
> I'd rather not to see "am.signoff", or any name that implies what
> the "-s" option to the command is about for that matter, to be used
> in futzing with the trailers other than S-o-b in any way.  As I
> understand it, our longer term goal is to defer that task, including
> the user-programmable policy decisions, to something like the
> 'trailer' Christian started.
> 
> I suspect that it may add unnecessary work later if we overloaded
> "signoff" with a similar feature with the change under discussion.
> I would feel safer to see it outlined how we envision to transition
> to a more generic 'trailer' solution later if we were to enhance
> "am" with "am.signoff" now.
> 
> Thanks.

Hi Junio, Christian, it's been a while. I see that the work on trailers is going on. I tried going over the documentation but I could not figure out how would one implement multiple signatures using the trailers mechanism.

As a reminder, this old patchset (that I replied to) enhanced git am -s
with an option to add different signatures depending on
the option passed to the -s flag.
E.g. I have
[am "a"]
        signoff = "Acked-by: Michael S. Tsirkin <mst@redhat.com>"
[am "r"]
        signoff = "Reviewed-by: Michael S. Tsirkin <mst@redhat.com>"
[am "t"]
        signoff = "Tested-by: Michael S. Tsirkin <mst@redhat.com>"
and now:
	git am -s art
adds all 3 signatures when applying the patch.
Any help will be appreciated.
-- 
MST
Junio C Hamano· Sep 22, 2014, 17:58 UTC · re: Michael S. Tsirkin · lore

Re: [PATCH RFC] git-am: support any number of signatures

"Michael S. Tsirkin" <mst@redhat.com> writes:
Show 6 quoted lines
> Hi Junio, Christian,
> it's been a while.
> I see that the work on trailers is going on.
> I tried going over the documentation but I could not figure
> out how would one implement multiple signatures using the
> trailers mechanism.

Good. Christian has been rerolling the series numerous times but he has been working without getting much input from people who would envision using the mechanism themselves (and my comments on the series do not count because I am not as one of them).

Please bombard us with questions and usability improvement suggestions ;-)

Christian Couder· Sep 23, 2014, 07:45 UTC · re: Michael S. Tsirkin · lore

Re: [PATCH RFC] git-am: support any number of signatures

Hi Michael,
On Mon, Sep 22, 2014 at 4:01 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
Show 24 quoted lines
>
> Hi Junio, Christian,
> it's been a while.
> I see that the work on trailers is going on.
> I tried going over the documentation but I could not figure
> out how would one implement multiple signatures using the
> trailers mechanism.
>
> As a reminder, this old patchset (that I replied to) enhanced git am -s
> with an option to add different signatures depending on
> the option passed to the -s flag.
> E.g. I have
> [am "a"]
>         signoff = "Acked-by: Michael S. Tsirkin <mst@redhat.com>"
>
> [am "r"]
>         signoff = "Reviewed-by: Michael S. Tsirkin <mst@redhat.com>"
>
> [am "t"]
>         signoff = "Tested-by: Michael S. Tsirkin <mst@redhat.com>"
>
> and now:
>         git am -s art
> adds all 3 signatures when applying the patch.

This is probably not as simple as you would like but it works with something like:

$ git interpret-trailers --trailer "Acked-by: Michael S. Tsirkin <mst@redhat.com>" --trailer "Reviewed-by: Michael S. Tsirkin <mst@redhat.com>" --trailer "Tested-by: Michael S. Tsirkin <mst@redhat.com>" 0001-foo.patch >to_apply/0001-foo.patch

and then:
$ git am to_apply/*.patch
Also by using something like:

$ git config trailer.a.key Acked-by $ git config trailer.r.key Reviewed-by $ git config trailer.t.key Tested-by

the first command could be simplified to:

$ git interpret-trailers --trailer "a: Michael S. Tsirkin <mst@redhat.com>" --trailer "r: Michael S. Tsirkin <mst@redhat.com>" --trailer "t: Michael S. Tsirkin <mst@redhat.com>" 0001-foo.patch

>to_apply/0001-foo.patch
And if you use an env variable:

$ ME="Michael S. Tsirkin <mst@redhat.com>" $ git interpret-trailers --trailer "a: $ME" --trailer "r: $ME" --trailer "t: $ME" 0001-foo.patch >to_apply/0001-foo.patch

Maybe later we will integrate git interpret-trailers with git commit, git am and other commands, so that you can do directly:

git am --trailer "a: $ME" --trailer "r: $ME"  --trailer "t: $ME" 0001-foo.patch

Maybe we wil also assign a one letter shortcut to --trailer, for example "z", so that could be:

git am -z "a: $ME" -z "r: $ME"  -z "t: $ME" 0001-foo.patch

We could also allow many separators in the same -z argument as long as they are separated by say "~", so you could have:

git am -z "a: $ME~r: $ME~t: $ME" 0001-foo.patch

And then we could also allow people to define default values for trailers with something like:

$ git config trailer.a.defaultvalue "Michael S. Tsirkin <mst@redhat.com>" $ git config trailer.r.defaultvalue "Michael S. Tsirkin <mst@redhat.com>" $ git config trailer.t.defaultvalue "Michael S. Tsirkin <mst@redhat.com>"

So that in the end you could have:
git am -z a~r~t 0001-foo.patch
which is very close to "git am -s art".

Best, Christian.

Michael S. Tsirkin· Sep 23, 2014, 08:07 UTC · re: Christian Couder · lore

Re: [PATCH RFC] git-am: support any number of signatures

On Tue, Sep 23, 2014 at 09:45:50AM +0200, Christian Couder wrote:
Show 45 quoted lines
> Hi Michael,
> 
> On Mon, Sep 22, 2014 at 4:01 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> > Hi Junio, Christian,
> > it's been a while.
> > I see that the work on trailers is going on.
> > I tried going over the documentation but I could not figure
> > out how would one implement multiple signatures using the
> > trailers mechanism.
> >
> > As a reminder, this old patchset (that I replied to) enhanced git am -s
> > with an option to add different signatures depending on
> > the option passed to the -s flag.
> > E.g. I have
> > [am "a"]
> >         signoff = "Acked-by: Michael S. Tsirkin <mst@redhat.com>"
> >
> > [am "r"]
> >         signoff = "Reviewed-by: Michael S. Tsirkin <mst@redhat.com>"
> >
> > [am "t"]
> >         signoff = "Tested-by: Michael S. Tsirkin <mst@redhat.com>"
> >
> > and now:
> >         git am -s art
> > adds all 3 signatures when applying the patch.
> 
> This is probably not as simple as you would like but it works with
> something like:
> 
> $ git interpret-trailers --trailer "Acked-by: Michael S. Tsirkin
> <mst@redhat.com>" --trailer "Reviewed-by: Michael S. Tsirkin
> <mst@redhat.com>"  --trailer "Tested-by: Michael S. Tsirkin
> <mst@redhat.com>" 0001-foo.patch >to_apply/0001-foo.patch
> 
> and then:
> 
> $ git am to_apply/*.patch
> 
> Also by using something like:
> 
> $ git config trailer.a.key Acked-by
> $ git config trailer.r.key Reviewed-by
> $ git config trailer.t.key Tested-by

I would like multiple keys to match a specific letter, e.g. as a maintainer I need both reviewed by and signed off by when I apply a patch, I like applying them with a single "-s m".

Show 22 quoted lines
> the first command could be simplified to:
> 
> $ git interpret-trailers --trailer "a: Michael S. Tsirkin
> <mst@redhat.com>" --trailer "r: Michael S. Tsirkin <mst@redhat.com>"
> --trailer "t: Michael S. Tsirkin <mst@redhat.com>" 0001-foo.patch
> >to_apply/0001-foo.patch
> 
> And if you use an env variable:
> 
> $ ME="Michael S. Tsirkin <mst@redhat.com>"
> $ git interpret-trailers --trailer "a: $ME" --trailer "r: $ME"
> --trailer "t: $ME" 0001-foo.patch >to_apply/0001-foo.patch
> 
> Maybe later we will integrate git interpret-trailers with git commit,
> git am and other commands, so that you can do directly:
> 
> git am --trailer "a: $ME" --trailer "r: $ME"  --trailer "t: $ME" 0001-foo.patch
> 
> Maybe we wil also assign a one letter shortcut to --trailer, for
> example "z", so that could be:
> 
> git am -z "a: $ME" -z "r: $ME"  -z "t: $ME" 0001-foo.patch

-s could apply here, right? It doesn't have a parameter at the moment.

> We could also allow many separators in the same -z argument as long as
> they are separated by say "~",
I think -z a -z r -z t is enough.
Show 10 quoted lines
> so you could have:
> 
> git am -z "a: $ME~r: $ME~t: $ME" 0001-foo.patch
> 
> And then we could also allow people to define default values for
> trailers with something like:
> 
> $ git config trailer.a.defaultvalue "Michael S. Tsirkin <mst@redhat.com>"
> $ git config trailer.r.defaultvalue "Michael S. Tsirkin <mst@redhat.com>"
> $ git config trailer.t.defaultvalue "Michael S. Tsirkin <mst@redhat.com>"

I'm kind of confused by the key/value concept. Can't I define the whole 'Acked-by: Michael S. Tsirkin <mst@redhat.com>' string as the key?

Show 8 quoted lines
> So that in the end you could have:
> 
> git am -z a~r~t 0001-foo.patch
> 
> which is very close to "git am -s art".
> 
> Best,
> Christian.

If I figure out the defaultvalue thing, I might find the time to work on git am integration.

Christian Couder· Sep 24, 2014, 10:00 UTC · re: Michael S. Tsirkin · lore

Re: [PATCH RFC] git-am: support any number of signatures

On Tue, Sep 23, 2014 at 10:07 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
Show 24 quoted lines
> On Tue, Sep 23, 2014 at 09:45:50AM +0200, Christian Couder wrote:
>> This is probably not as simple as you would like but it works with
>> something like:
>>
>> $ git interpret-trailers --trailer "Acked-by: Michael S. Tsirkin
>> <mst@redhat.com>" --trailer "Reviewed-by: Michael S. Tsirkin
>> <mst@redhat.com>"  --trailer "Tested-by: Michael S. Tsirkin
>> <mst@redhat.com>" 0001-foo.patch >to_apply/0001-foo.patch
>>
>> and then:
>>
>> $ git am to_apply/*.patch
>>
>> Also by using something like:
>>
>> $ git config trailer.a.key Acked-by
>> $ git config trailer.r.key Reviewed-by
>> $ git config trailer.t.key Tested-by
>
> I would like multiple keys to match a specific
> letter, e.g. as a maintainer I need
> both reviewed by and signed off by when I
> apply a patch, I like applying them with
> a single "-s m".

That's different from what you implemented in your patch. And franckly I think that for this kind of specific use cases, you could create your own aliases, either Git aliases or just shell aliases.

For example if we implement default values and make git am call git interpret-trailers, a shell alias could simply be:

alias gamsm='git am --trailer r --trailer s'

I use "git log --oneline --decorate --graph" very often, so I made my own alias for it, and I suppose a lot of other people have done so.

The number of people who will use trailers will probably be much smaller than the number of people using git log, so if we don't make shortcuts for "git log --oneline --decorate --graph", I see no ground to ask for a specific shortcut that adds both a reviewed by and a signed off by.

Show 24 quoted lines
>> the first command could be simplified to:
>>
>> $ git interpret-trailers --trailer "a: Michael S. Tsirkin
>> <mst@redhat.com>" --trailer "r: Michael S. Tsirkin <mst@redhat.com>"
>> --trailer "t: Michael S. Tsirkin <mst@redhat.com>" 0001-foo.patch
>> >to_apply/0001-foo.patch
>>
>> And if you use an env variable:
>>
>> $ ME="Michael S. Tsirkin <mst@redhat.com>"
>> $ git interpret-trailers --trailer "a: $ME" --trailer "r: $ME"
>> --trailer "t: $ME" 0001-foo.patch >to_apply/0001-foo.patch
>>
>> Maybe later we will integrate git interpret-trailers with git commit,
>> git am and other commands, so that you can do directly:
>>
>> git am --trailer "a: $ME" --trailer "r: $ME"  --trailer "t: $ME" 0001-foo.patch
>>
>> Maybe we wil also assign a one letter shortcut to --trailer, for
>> example "z", so that could be:
>>
>> git am -z "a: $ME" -z "r: $ME"  -z "t: $ME" 0001-foo.patch
>
> -s could apply here, right?
I don't know what we will do with -s. Maybe if we use -z, we don't need -s.
> It doesn't have a parameter at the moment.

We will have to discuss that kind of thing when we make it possible for git commit, git am and maybe other commands to accept trailers arguments and pass them to git interpret-trailers.

In his email Junio seems to say that we don't need a shortcut like -z, we could only have --trailer. And I think that it is indeed sound to at least wait a little before using up one shortcut like -z in many commands.

>> We could also allow many separators in the same -z argument as long as
>> they are separated by say "~",
>
> I think -z a -z r -z t is enough.

Great! I think you will likely have at least "--trailer a --trailer r --trailer t", but I don't think it is too bad as you can use aliases to make it shorter to type.

Show 12 quoted lines
>> so you could have:
>>
>> git am -z "a: $ME~r: $ME~t: $ME" 0001-foo.patch
>>
>> And then we could also allow people to define default values for
>> trailers with something like:
>>
>> $ git config trailer.a.defaultvalue "Michael S. Tsirkin <mst@redhat.com>"
>> $ git config trailer.r.defaultvalue "Michael S. Tsirkin <mst@redhat.com>"
>> $ git config trailer.t.defaultvalue "Michael S. Tsirkin <mst@redhat.com>"
>
> I'm kind of confused by the key/value concept.

A "defaultvalue" would be the value used when no value is passed. The "key" is just what we will use in the first part of the trailer (the part before the separator).

For example with the above "defaultvalue" and "key", "--trailer a: Junio <gitster@pobox.com>" would add:

Acked-by: Junio <gitster@pobox.com>
while "--trailer a" would add:
Acked-by: Michael S. Tsirkin <mst@redhat.com>
> Can't I define the whole 'Acked-by: Michael S. Tsirkin <mst@redhat.com>'
> string as the key?

The whole 'Acked-by: Michael S. Tsirkin <mst@redhat.com>' is a full trailer, not a "key".

And it is not possible right now to define a full trailer. Maybe we could find a way to make it possible, but a default value and a way to have a small nickname for the token (like "a" for "Acked-by") should get people quite far. And then for very specific use cases, it may be better to use aliases anyway.

Show 8 quoted lines
>> So that in the end you could have:
>>
>> git am -z a~r~t 0001-foo.patch
>>
>> which is very close to "git am -s art".
>
> If I figure out the defaultvalue thing, I might
> find the time to work on git am integration.
That would be great!

Thanks, Christian.

Michael S. Tsirkin· Oct 7, 2014, 21:33 UTC · re: Christian Couder · lore

Re: [PATCH RFC] git-am: support any number of signatures

On Wed, Sep 24, 2014 at 12:00:40PM +0200, Christian Couder wrote:
Show 44 quoted lines
> On Tue, Sep 23, 2014 at 10:07 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> > On Tue, Sep 23, 2014 at 09:45:50AM +0200, Christian Couder wrote:
> >> This is probably not as simple as you would like but it works with
> >> something like:
> >>
> >> $ git interpret-trailers --trailer "Acked-by: Michael S. Tsirkin
> >> <mst@redhat.com>" --trailer "Reviewed-by: Michael S. Tsirkin
> >> <mst@redhat.com>"  --trailer "Tested-by: Michael S. Tsirkin
> >> <mst@redhat.com>" 0001-foo.patch >to_apply/0001-foo.patch
> >>
> >> and then:
> >>
> >> $ git am to_apply/*.patch
> >>
> >> Also by using something like:
> >>
> >> $ git config trailer.a.key Acked-by
> >> $ git config trailer.r.key Reviewed-by
> >> $ git config trailer.t.key Tested-by
> >
> > I would like multiple keys to match a specific
> > letter, e.g. as a maintainer I need
> > both reviewed by and signed off by when I
> > apply a patch, I like applying them with
> > a single "-s m".
> 
> That's different from what you implemented in your patch.
> And franckly I think that for this kind of specific use cases, you
> could create your own aliases, either Git aliases or just shell
> aliases.
> 
> For example if we implement default values and make git am call git
> interpret-trailers, a shell alias could simply be:
> 
> alias gamsm='git am --trailer r --trailer s'
> 
> I use "git log --oneline --decorate --graph" very often, so I made my
> own alias for it, and I suppose a lot of other people have done so.
> 
> The number of people who will use trailers will probably be much
> smaller than the number of people using git log, so if we don't make
> shortcuts for "git log --oneline --decorate --graph", I see no ground
> to ask for a specific shortcut that adds both a reviewed by and a
> signed off by.

I've been thinking: how about a generic ability to add option shortcuts for commands in .config? For example:

[am "-z"]
	command = "--trailer foobar"
would replace any -z in git am command line with --trailer foobar.
Does this sound useful?
Show 98 quoted lines
> >> the first command could be simplified to:
> >>
> >> $ git interpret-trailers --trailer "a: Michael S. Tsirkin
> >> <mst@redhat.com>" --trailer "r: Michael S. Tsirkin <mst@redhat.com>"
> >> --trailer "t: Michael S. Tsirkin <mst@redhat.com>" 0001-foo.patch
> >> >to_apply/0001-foo.patch
> >>
> >> And if you use an env variable:
> >>
> >> $ ME="Michael S. Tsirkin <mst@redhat.com>"
> >> $ git interpret-trailers --trailer "a: $ME" --trailer "r: $ME"
> >> --trailer "t: $ME" 0001-foo.patch >to_apply/0001-foo.patch
> >>
> >> Maybe later we will integrate git interpret-trailers with git commit,
> >> git am and other commands, so that you can do directly:
> >>
> >> git am --trailer "a: $ME" --trailer "r: $ME"  --trailer "t: $ME" 0001-foo.patch
> >>
> >> Maybe we wil also assign a one letter shortcut to --trailer, for
> >> example "z", so that could be:
> >>
> >> git am -z "a: $ME" -z "r: $ME"  -z "t: $ME" 0001-foo.patch
> >
> > -s could apply here, right?
> 
> I don't know what we will do with -s. Maybe if we use -z, we don't need -s.
> 
> > It doesn't have a parameter at the moment.
> 
> We will have to discuss that kind of thing when we make it possible
> for git commit, git am and maybe other commands to accept trailers
> arguments and pass them to git interpret-trailers.
> 
> In his email Junio seems to say that we don't need a shortcut like -z,
> we could only have --trailer.
> And I think that it is indeed sound to at least wait a little before
> using up one shortcut like -z in many commands.
> 
> >> We could also allow many separators in the same -z argument as long as
> >> they are separated by say "~",
> >
> > I think -z a -z r -z t is enough.
> 
> Great! I think you will likely have at least "--trailer a --trailer r
> --trailer t", but I don't think it is too bad as you can use aliases
> to make it shorter to type.
> 
> >> so you could have:
> >>
> >> git am -z "a: $ME~r: $ME~t: $ME" 0001-foo.patch
> >>
> >> And then we could also allow people to define default values for
> >> trailers with something like:
> >>
> >> $ git config trailer.a.defaultvalue "Michael S. Tsirkin <mst@redhat.com>"
> >> $ git config trailer.r.defaultvalue "Michael S. Tsirkin <mst@redhat.com>"
> >> $ git config trailer.t.defaultvalue "Michael S. Tsirkin <mst@redhat.com>"
> >
> > I'm kind of confused by the key/value concept.
> 
> A "defaultvalue" would be the value used when no value is passed.
> The "key" is just what we will use in the first part of the trailer
> (the part before the separator).
> 
> For example with the above "defaultvalue" and "key", "--trailer a:
> Junio <gitster@pobox.com>" would add:
> 
> Acked-by: Junio <gitster@pobox.com>
> 
> while "--trailer a" would add:
> 
> Acked-by: Michael S. Tsirkin <mst@redhat.com>
> 
> > Can't I define the whole 'Acked-by: Michael S. Tsirkin <mst@redhat.com>'
> > string as the key?
> 
> The whole 'Acked-by: Michael S. Tsirkin <mst@redhat.com>' is a full
> trailer, not a "key".
> 
> And it is not possible right now to define a full trailer. Maybe we
> could find a way to make it possible, but a default value and a way to
> have a small nickname for the token (like "a" for "Acked-by") should
> get people quite far. And then for very specific use cases, it may be
> better to use aliases anyway.
> 
> >> So that in the end you could have:
> >>
> >> git am -z a~r~t 0001-foo.patch
> >>
> >> which is very close to "git am -s art".
> >
> > If I figure out the defaultvalue thing, I might
> > find the time to work on git am integration.
> 
> That would be great!
> 
> Thanks,
> Christian.
Junio C Hamano· Sep 23, 2014, 17:15 UTC · re: Christian Couder · lore

Re: [PATCH RFC] git-am: support any number of signatures

Christian Couder <christian.couder@gmail.com> writes:
Show 30 quoted lines
> On Mon, Sep 22, 2014 at 4:01 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
>> ...
>> As a reminder, this old patchset (that I replied to) enhanced git am -s
>> with an option to add different signatures depending on
>> the option passed to the -s flag.
>> E.g. I have
>> [am "a"]
>>         signoff = "Acked-by: Michael S. Tsirkin <mst@redhat.com>"
>>
>> [am "r"]
>>         signoff = "Reviewed-by: Michael S. Tsirkin <mst@redhat.com>"
>>
>> [am "t"]
>>         signoff = "Tested-by: Michael S. Tsirkin <mst@redhat.com>"
>>
>> and now:
>>         git am -s art
>> adds all 3 signatures when applying the patch.
>
> This is probably not as simple as you would like but it works with
> something like:
>
> $ git interpret-trailers --trailer "Acked-by: Michael S. Tsirkin
> <mst@redhat.com>" --trailer "Reviewed-by: Michael S. Tsirkin
> <mst@redhat.com>"  --trailer "Tested-by: Michael S. Tsirkin
> <mst@redhat.com>" 0001-foo.patch >to_apply/0001-foo.patch
>
> and then:
>
> $ git am to_apply/*.patch

If I understand it correctly, Michael is envisioning to implement his "git am -s art" (I would recommend against reusing -s for this, though. "git am --trailer art" is fine) and doing so by using interpret-trailers as an internal implementation detail, so I would say the above is a perfectly fine way to do so. An equivalent of that command line is synthesized and run internally in his version of "git am" when his "git am" sees "--trailer art" option using those am.{"a","r","t"}.trailer configuration variables.

Show 7 quoted lines
> Also by using something like:
>
> $ git config trailer.a.key Acked-by
> $ git config trailer.r.key Reviewed-by
> $ git config trailer.t.key Tested-by
>
> the first command could be simplified to:

So I think this mechanism buys Michael's use case very little, if any. It might be useful in other contexts, though.

What would be more interesting is if the primitives you have,
e.g. "replace", "append", etc. are sufficient to express his use
case and similar ones.  For example, when working on multiple
trailers (e.g. "am --trailer art" would muck with three kinds), how
should "do this if exists at the end and do that otherwise" work?
To an existing message ends with Michael's Signed-off-by:, if his
"git am --trailer arts" is called to add these three and then a
Signed-off-by: from him, should it add an extra S-o-b (because his
existing S-o-b will no longer be the last one after adding Acked and
others), or should it refrain from doing so?  Can you express both
preferences?

Another thing that got me wondered this morning while I was thinking about this topic was if "replace" is flexible enough. We may want to have "if an entry exists (not necessarily at the end), remove it and then append a new one with this value at the end" to implement "Last-tested-by: me@my.domain", for example.

Junio C Hamano· Sep 25, 2014, 05:04 UTC · re: Junio C Hamano · lore

Re: [PATCH RFC] git-am: support any number of signatures

Junio C Hamano <gitster@pobox.com> writes:
Show 11 quoted lines
> What would be more interesting is if the primitives you have,
> e.g. "replace", "append", etc. are sufficient to express his use
> case and similar ones.  For example, when working on multiple
> trailers (e.g. "am --trailer art" would muck with three kinds), how
> should "do this if exists at the end and do that otherwise" work?
> To an existing message ends with Michael's Signed-off-by:, if his
> "git am --trailer arts" is called to add these three and then a
> Signed-off-by: from him, should it add an extra S-o-b (because his
> existing S-o-b will no longer be the last one after adding Acked and
> others), or should it refrain from doing so?  Can you express both
> preferences?

By the way, the answer to this can be "no, but it does not matter.", of course. If you can only express the latter (i.e. the addition of multiple trailers is done as an atomic event, what was the last before addition of them will be treated during the whole time of addition of all of them), that may be perfectly fine because the former (i.e. the addition is done one by one) can easily be emulated by calling the program multiple times, feeding the trailers one by one.

Show 5 quoted lines
> Another thing that got me wondered this morning while I was thinking
> about this topic was if "replace" is flexible enough.  We may want
> to have "if an entry exists (not necessarily at the end), remove it
> and then append a new one with this value at the end" to implement
> "Last-tested-by: me@my.domain", for example.
Christian Couder· Sep 25, 2014, 10:04 UTC · re: Junio C Hamano · lore

Re: [PATCH RFC] git-am: support any number of signatures

On Tue, Sep 23, 2014 at 7:15 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 23 quoted lines
> Christian Couder <christian.couder@gmail.com> writes:
>
>>
>> This is probably not as simple as you would like but it works with
>> something like:
>>
>> $ git interpret-trailers --trailer "Acked-by: Michael S. Tsirkin
>> <mst@redhat.com>" --trailer "Reviewed-by: Michael S. Tsirkin
>> <mst@redhat.com>"  --trailer "Tested-by: Michael S. Tsirkin
>> <mst@redhat.com>" 0001-foo.patch >to_apply/0001-foo.patch
>>
>> and then:
>>
>> $ git am to_apply/*.patch
>
> If I understand it correctly, Michael is envisioning to implement
> his "git am -s art" (I would recommend against reusing -s for this,
> though.  "git am --trailer art" is fine) and doing so by using
> interpret-trailers as an internal implementation detail, so I would
> say the above is a perfectly fine way to do so.  An equivalent of
> that command line is synthesized and run internally in his version
> of "git am" when his "git am" sees "--trailer art" option using
> those am.{"a","r","t"}.trailer configuration variables.

Yeah, that's the idea, except that I think "--trailer art" should mean a trailer like:

art: <default value>
(if there is no trailer.art.key config variable defined).

Having am.{"a","r","t"}.trailer configuration variables to define full trailers seems too specific and quite confusing regarding how git interpret-trailers work without those variables.

Show 16 quoted lines
>> Also by using something like:
>>
>> $ git config trailer.a.key Acked-by
>> $ git config trailer.r.key Reviewed-by
>> $ git config trailer.t.key Tested-by
>>
>> the first command could be simplified to:
>
> So I think this mechanism buys Michael's use case very little, if
> any.  It might be useful in other contexts, though.
>
> What would be more interesting is if the primitives you have,
> e.g. "replace", "append", etc. are sufficient to express his use
> case and similar ones.  For example, when working on multiple
> trailers (e.g. "am --trailer art" would muck with three kinds), how
> should "do this if exists at the end and do that otherwise" work?
The way the "trailer.<foo>.ifexists" and "trailer.<foo>.where" work is
quite orthogonal to the way we decide what the content of the trailer
is.
If we make "--trailer art" mean "--trailer Acked-by: Michael --trailer
Reviewed-by: Michael --trailer Tested-by: Michael", then it should
work as if we had passed the latter to the command line.
Show 6 quoted lines
> To an existing message ends with Michael's Signed-off-by:, if his
> "git am --trailer arts" is called to add these three and then a
> Signed-off-by: from him, should it add an extra S-o-b (because his
> existing S-o-b will no longer be the last one after adding Acked and
> others), or should it refrain from doing so?  Can you express both
> preferences?

The default for "trailer.where" is "end", and for "trailer.ifexists" it is "addIfDifferentNeighbor". That means that by default it will add the four new trailers at the end.

If either "trailer.ifexists" or "trailer.S-o-b.ifexists" is set to "addIfDifferent", then only the first 3 new trailers will be added at the end. So yes you can express both preferences.

Show 5 quoted lines
> Another thing that got me wondered this morning while I was thinking
> about this topic was if "replace" is flexible enough.  We may want
> to have "if an entry exists (not necessarily at the end), remove it
> and then append a new one with this value at the end" to implement
> "Last-tested-by: me@my.domain", for example.

That's what "replace" does already. That's why I changed the previous name for this option from "overwrite" to "replace". You have an "overwrite behavior" with where = after and ifexist = replace, and you have a "remove old one and append new one behavior" with where = end and ifexist = replace.

Thanks, Christian.

Junio C Hamano· Sep 25, 2014, 16:20 UTC · re: Christian Couder · lore

Re: [PATCH RFC] git-am: support any number of signatures

On Thu, Sep 25, 2014 at 3:04 AM, Christian Couder <christian.couder@gmail.com> wrote:

Show 14 quoted lines
>> To an existing message ends with Michael's Signed-off-by:, if his
>> "git am --trailer arts" is called to add these three and then a
>> Signed-off-by: from him, should it add an extra S-o-b (because his
>> existing S-o-b will no longer be the last one after adding Acked and
>> others), or should it refrain from doing so?  Can you express both
>> preferences?
>
> The default for "trailer.where" is "end", and for "trailer.ifexists"
> it is "addIfDifferentNeighbor".
> That means that by default it will add the four new trailers at the end.
>
> If either "trailer.ifexists" or "trailer.S-o-b.ifexists" is set to
> "addIfDifferent", then only the first 3 new trailers will be added at
> the end. So yes you can express both preferences.

Suppose that the original ends with Sob, and Michael's "am" invokes interpret-trailers with Acked/Reviewed/Tested/Sob in this order. The first three are set to addifDifferent and Sob is set to addIfDifferentNeighbor, which would be the traditional and sensible default.

Now, how is addIfDifferentNeighbor interpreted? Adding the new Sob with this single request to add these four is done on a message that has the same Sob at the end (i.e. Neighbor). Does _you_ adding of Acked/Reviewed/Tested invalidate the Neighbor-ness and you add the Sob anew?

If that is what happens, it is not a workable workaround to set Sob to addIfDifferent only for this invocation.

Alternatively, if Neighbor-ness is evaluated first before you add A/R/T in response to this request, then you'd refrain from adding a duplicate Sob. It wasn't quite clear from your description what your design was, and your explanation above is not still clear, at least to me.

Christian Couder· Sep 28, 2014, 11:36 UTC · re: Junio C Hamano · lore

Re: [PATCH RFC] git-am: support any number of signatures

From: Junio C Hamano <gitster@pobox.com>
Show 27 quoted lines
> On Thu, Sep 25, 2014 at 3:04 AM, Christian Couder
> <christian.couder@gmail.com> wrote:
>>> To an existing message ends with Michael's Signed-off-by:, if his
>>> "git am --trailer arts" is called to add these three and then a
>>> Signed-off-by: from him, should it add an extra S-o-b (because his
>>> existing S-o-b will no longer be the last one after adding Acked and
>>> others), or should it refrain from doing so?  Can you express both
>>> preferences?
>>
>> The default for "trailer.where" is "end", and for "trailer.ifexists"
>> it is "addIfDifferentNeighbor".
>> That means that by default it will add the four new trailers at the end.
>>
>> If either "trailer.ifexists" or "trailer.S-o-b.ifexists" is set to
>> "addIfDifferent", then only the first 3 new trailers will be added at
>> the end. So yes you can express both preferences.
> 
> Suppose that the original ends with Sob, and Michael's "am" invokes
> interpret-trailers with Acked/Reviewed/Tested/Sob in this order. The first
> three are set to addifDifferent and Sob is set to addIfDifferentNeighbor,
> which would be the traditional and sensible default.
> 
> Now, how is addIfDifferentNeighbor interpreted? Adding the new Sob
> with this single request to add these four is done on a message that
> has the same Sob at the end (i.e. Neighbor). Does _you_ adding of
> Acked/Reviewed/Tested invalidate the Neighbor-ness and you add the
> Sob anew?

The trailers are processed in the order they appear on the command line. And when a trailer is processed, the input message it "sees" is the result from the processing of all the previous trailers on the command line. It is not any more the original input message.

So after Acked/Reviewed/Tested have been added, when the S-o-b at the end of the command line is processed, it "sees" an input message that has the Tested trailer at the end. That's why with addIfDifferentNeighbor the S-o-b will still be added at the end.

> If that is what happens, it is not a workable workaround to set Sob to
> addIfDifferent only for this invocation.

Setting S-o-b to addIfDifferent for this invocation would not add the S-o-b at the end, because another S-o-b still exists in the input message "seen" when the last S-o-b is processed.

> Alternatively, if Neighbor-ness is evaluated first before you add A/R/T
> in response to this request, then you'd refrain from adding a duplicate
> Sob. It wasn't quite clear from your description what your design was,
> and your explanation above is not still clear, at least to me.

I hope it is clearer now. Maybe I should add something in the doc to better explain how it works.

Thanks, Christian.

Michael S. Tsirkin· Oct 7, 2014, 21:29 UTC · re: Junio C Hamano · lore

Re: [PATCH RFC] git-am: support any number of signatures

On Tue, Sep 23, 2014 at 10:15:47AM -0700, Junio C Hamano wrote:
Show 41 quoted lines
> Christian Couder <christian.couder@gmail.com> writes:
> 
> > On Mon, Sep 22, 2014 at 4:01 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> >> ...
> >> As a reminder, this old patchset (that I replied to) enhanced git am -s
> >> with an option to add different signatures depending on
> >> the option passed to the -s flag.
> >> E.g. I have
> >> [am "a"]
> >>         signoff = "Acked-by: Michael S. Tsirkin <mst@redhat.com>"
> >>
> >> [am "r"]
> >>         signoff = "Reviewed-by: Michael S. Tsirkin <mst@redhat.com>"
> >>
> >> [am "t"]
> >>         signoff = "Tested-by: Michael S. Tsirkin <mst@redhat.com>"
> >>
> >> and now:
> >>         git am -s art
> >> adds all 3 signatures when applying the patch.
> >
> > This is probably not as simple as you would like but it works with
> > something like:
> >
> > $ git interpret-trailers --trailer "Acked-by: Michael S. Tsirkin
> > <mst@redhat.com>" --trailer "Reviewed-by: Michael S. Tsirkin
> > <mst@redhat.com>"  --trailer "Tested-by: Michael S. Tsirkin
> > <mst@redhat.com>" 0001-foo.patch >to_apply/0001-foo.patch
> >
> > and then:
> >
> > $ git am to_apply/*.patch
> 
> If I understand it correctly, Michael is envisioning to implement
> his "git am -s art" (I would recommend against reusing -s for this,
> though.  "git am --trailer art" is fine) and doing so by using
> interpret-trailers as an internal implementation detail, so I would
> say the above is a perfectly fine way to do so.  An equivalent of
> that command line is synthesized and run internally in his version
> of "git am" when his "git am" sees "--trailer art" option using
> those am.{"a","r","t"}.trailer configuration variables.

Hmm I wonder why do you dislike reusing -s with a parameter for this. To me, this looks like a superset of the default -s functionality: -s adds the default signature, -s "x" adds signature "x" ... Users don't really care that one is implemented as a trailer and another isn't. In fact, default -s can be implemented as a trailer too, right?

Could you clarify please?
-- 
MST
Jeff King· Oct 7, 2014, 21:39 UTC · re: Michael S. Tsirkin · lore

Re: [PATCH RFC] git-am: support any number of signatures

On Wed, Oct 08, 2014 at 12:29:37AM +0300, Michael S. Tsirkin wrote:
Show 16 quoted lines
> > If I understand it correctly, Michael is envisioning to implement
> > his "git am -s art" (I would recommend against reusing -s for this,
> > though.  "git am --trailer art" is fine) and doing so by using
> > interpret-trailers as an internal implementation detail, so I would
> > say the above is a perfectly fine way to do so.  An equivalent of
> > that command line is synthesized and run internally in his version
> > of "git am" when his "git am" sees "--trailer art" option using
> > those am.{"a","r","t"}.trailer configuration variables.
> 
> Hmm I wonder why do you dislike reusing -s with a parameter for this.
> To me, this looks like a superset of the default -s functionality: -s
> adds the default signature, -s "x" adds signature "x" ...  Users don't
> really care that one is implemented as a trailer and another isn't.  In
> fact, default -s can be implemented as a trailer too, right?
> 
> Could you clarify please?

Optional parameters for arguments make backwards-compatibility tricky. In this case, the command:

  git am -s mbox1 mbox2

means "apply the patches from mbox1 and mbox2, and signoff the patches". Under your scheme, it now means "apply from mbox2, and use the trailer mbox1".

I think it would make more sense for "-s" to use a trailer called "signoff" if it is configured (and if not, have a baked-in "signoff" trailer config that behaves like "-s" does now). So "-s" (and "--signoff") become "sign off in the way I usually do for my project", not just "add a signed-off-by line". If you want to something more fancy, you have to use "--trailer=...".

Just my two cents, as one who has not been closely following this discussion. Apologies if this idea was already presented and shot down. :)

-Peff
Junio C Hamano· Oct 7, 2014, 21:41 UTC · re: Jeff King · lore

Re: [PATCH RFC] git-am: support any number of signatures

Jeff King <peff@peff.net> writes:
Show 8 quoted lines
> Optional parameters for arguments make backwards-compatibility tricky.
> In this case, the command:
>
>   git am -s mbox1 mbox2
>
> means "apply the patches from mbox1 and mbox2, and signoff the patches".
> Under your scheme, it now means "apply from mbox2, and use the trailer
> mbox1".
Thanks for saving me from typing ;-)
René Scharfe· Jun 12, 2014, 19:25 UTC · re: Michael S. Tsirkin · lore

Re: [PATCH RFC] git-am: support any number of signatures

Am 12.06.2014 18:12, schrieb Michael S. Tsirkin:
Show 6 quoted lines
> @@ -136,7 +136,7 @@ fall_back_3way () {
>       eval "$cmd" &&
>       GIT_INDEX_FILE="$dotest/patch-merge-tmp-index" \
>       git write-tree >"$dotest/patch-merge-base+" ||
> -    cannot_fallback "$(gettext "Repository lacks necessary blobs to fall back on 3-way merge.")"
> +    cannot_fallback "$(gettext "Repository lsignoffs necessary blobs to fall back on 3-way merge.")"
lsignoffs?
Michael S. Tsirkin· Jun 13, 2014, 08:01 UTC · re: René Scharfe · lore

Re: [PATCH RFC] git-am: support any number of signatures

On Thu, Jun 12, 2014 at 09:25:54PM +0200, René Scharfe wrote:
Show 9 quoted lines
> Am 12.06.2014 18:12, schrieb Michael S. Tsirkin:
> >@@ -136,7 +136,7 @@ fall_back_3way () {
> >      eval "$cmd" &&
> >      GIT_INDEX_FILE="$dotest/patch-merge-tmp-index" \
> >      git write-tree >"$dotest/patch-merge-base+" ||
> >-    cannot_fallback "$(gettext "Repository lacks necessary blobs to fall back on 3-way merge.")"
> >+    cannot_fallback "$(gettext "Repository lsignoffs necessary blobs to fall back on 3-way merge.")"
> 
> lsignoffs?

Heh good catch, I'll fix this up. Thanks!

Christian Couder· Oct 12, 2014, 09:36 UTC · lore

Re: [PATCH RFC] git-am: support any number of signatures

On Sun, Sep 28, 2014 at 9:32 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 12 quoted lines
> Christian Couder <chriscool@tuxfamily.org> writes:
>
>> From: Junio C Hamano <gitster@pobox.com>
>>
>>> If that is what happens, it is not a workable workaround to set Sob to
>>> addIfDifferent only for this invocation.
>>
>> Setting S-o-b to addIfDifferent for this invocation would not add the
>> S-o-b at the end, because another S-o-b still exists in the input
>> message "seen" when the last S-o-b is processed.
>
> So there is no workaround whatsoever, which is worse X-<.
I think there might be a misunderstanding.

With v16 you can easily choose if you want to have the S-o-b in the output or not, when there is already one, see:

$ cat test.txt
Signed-off-by: <Michael>

$ cat test.txt | git interpret-trailers --trailer 'Acked-by: <Michael>' --trailer 'Reviewed-by: <Michael>' --trailer 'Tested-by: <Michael>' --trailer 'Signed-off-by: <Michael>'

Signed-off-by: <Michael>
Acked-by: <Michael>
Reviewed-by: <Michael>
Tested-by: <Michael>
Signed-off-by: <Michael>

$ cat test.txt | git -c 'trailer.ifexists=addIfDifferent' interpret-trailers --trailer 'Acked-by: <Michael>' --trailer 'Reviewed-by: <Michael>' --trailer 'Tested-by: <Michael>' --trailer 'Signed-off-by: <Michael>'

Signed-off-by: <Michael>
Acked-by: <Michael>
Reviewed-by: <Michael>
Tested-by: <Michael>
Or:

$ cat test.txt | git -c 'trailer.Signed-off-by.ifexists=addIfDifferent' interpret-trailers --trailer 'Acked-by: <Michael>' --trailer 'Reviewed-by: <Michael>' --trailer 'Tested-by: <Michael>' --trailer 'Signed-off-by: <Michael>'

Signed-off-by: <Michael>
Acked-by: <Michael>
Reviewed-by: <Michael>
Tested-by: <Michael>
(There was a small bug in v15 with the last command above.)
Show 15 quoted lines
>>> Alternatively, if Neighbor-ness is evaluated first before you add A/R/T
>>> in response to this request, then you'd refrain from adding a duplicate
>>> Sob. It wasn't quite clear from your description what your design was,
>>> and your explanation above is not still clear, at least to me.
>>
>> I hope it is clearer now. Maybe I should add something in the doc to
>> better explain how it works.
>
> I doubt that it would help the users materially to document that we
> chose to implement a less useful way when there are multiple ways in
> which a feature can work, though.
>
> Unless I am mis-reading you and you are actually saying that the
> users can emulate the "atomic" variant without much hassle by doing
> X and Y, that is.  If so, it would help readers to document them.

If you would like me to document the 3 above commands in an example, I am ok to do that.

Thanks, Christian.

Christian Couder· Oct 13, 2014, 05:09 UTC · re: Christian Couder · lore

Re: [PATCH RFC] git-am: support any number of signatures

On Sun, Oct 12, 2014 at 11:36 AM, Christian Couder <christian.couder@gmail.com> wrote:

>
> With v16 you can easily choose if you want to have the S-o-b in the
> output or not, when there is already one, ...

By the way, I sent v16 just before the above email, but the series still hasn't hit the mailing list. Did some of you guys in cc receive something?

Junio C Hamano· Oct 13, 2014, 22:05 UTC · re: Christian Couder · lore

Re: [PATCH RFC] git-am: support any number of signatures

Christian Couder <christian.couder@gmail.com> writes:
Show 9 quoted lines
> On Sun, Oct 12, 2014 at 11:36 AM, Christian Couder
> <christian.couder@gmail.com> wrote:
>>
>> With v16 you can easily choose if you want to have the S-o-b in the
>> output or not, when there is already one, ...
>
> By the way, I sent v16 just before the above email, but the series
> still hasn't hit the mailing list.
> Did some of you guys in cc receive something?
I see them and picked them up to replace.
Are these now ready for 'next'?
Christian Couder· Oct 14, 2014, 05:29 UTC · re: Junio C Hamano · lore

Re: [PATCH RFC] git-am: support any number of signatures

From: Junio C Hamano <gitster@pobox.com>
Show 14 quoted lines
>
> Christian Couder <christian.couder@gmail.com> writes:
> 
>> On Sun, Oct 12, 2014 at 11:36 AM, Christian Couder
>> <christian.couder@gmail.com> wrote:
>>>
>>> With v16 you can easily choose if you want to have the S-o-b in the
>>> output or not, when there is already one, ...
>>
>> By the way, I sent v16 just before the above email, but the series
>> still hasn't hit the mailing list.
>> Did some of you guys in cc receive something?
> 
> I see them and picked them up to replace.
Thanks!
 
> Are these now ready for 'next'?
Yeah, I think so.

Thanks, Christian.

← back to recent threads