[PATCH v4 0/7] git send-email suppress-cc=self fixes

[PATCH v4 0/7] git send-email suppress-cc=self fixes

[Michael S. Tsirkin]

This includes bugfixes related to handling of --suppress-cc=self
flag. Tests are also included.

Changes from v3:
	- v3 submission was missing one patch (1/7). Re-add it.
Changes from v2:
	- add a new test, split patches differently add code comments
		 to address comments by Junio
	- rename example addresses in tests from redhat.com to example.com
Changes from v1:
        - tweak coding style in tests to address comments by Junio

Michael S. Tsirkin (7):
  t/send-email.sh: add test for suppress-cc=self
  send-email: fix suppress-cc=self on cccmd
  t/send-email: test suppress-cc=self on cccmd
  send-email: make --suppress-cc=self sanitize input
  t/send-email: add test with quoted sender
  t/send-email: test suppress-cc=self with non-ascii
  test-send-email: test for pre-sanitized self name

 git-send-email.perl   | 23 ++++++++++------
 t/t9001-send-email.sh | 75 +++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 90 insertions(+), 8 deletions(-)

-- 
MST

Re: [PATCH v4 0/7] git send-email suppress-cc=self fixes

[Junio C Hamano]

"Michael S. Tsirkin" <mst@redhat.com> writes:

> This includes bugfixes related to handling of --suppress-cc=self
> flag. Tests are also included.
>
> Changes from v3:
> 	- v3 submission was missing one patch (1/7). Re-add it.
> Changes from v2:
> 	- add a new test, split patches differently add code comments
> 		 to address comments by Junio
> 	- rename example addresses in tests from redhat.com to example.com
> Changes from v1:
>         - tweak coding style in tests to address comments by Junio

Nice.  This round cleanly applies and the interdiff since v2 looked
sensible.

Will replace and merge to 'next' shortly.

Thanks.

>
> Michael S. Tsirkin (7):
>   t/send-email.sh: add test for suppress-cc=self
>   send-email: fix suppress-cc=self on cccmd
>   t/send-email: test suppress-cc=self on cccmd
>   send-email: make --suppress-cc=self sanitize input
>   t/send-email: add test with quoted sender
>   t/send-email: test suppress-cc=self with non-ascii
>   test-send-email: test for pre-sanitized self name
>
>  git-send-email.perl   | 23 ++++++++++------
>  t/t9001-send-email.sh | 75 +++++++++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 90 insertions(+), 8 deletions(-)

Re: [PATCH v4 0/7] git send-email suppress-cc=self fixes

[Michael S. Tsirkin]

On Wed, Jun 05, 2013 at 12:28:08PM -0700, Junio C Hamano wrote:
> "Michael S. Tsirkin" <mst@redhat.com> writes:
> 
> > This includes bugfixes related to handling of --suppress-cc=self
> > flag. Tests are also included.
> >
> > Changes from v3:
> > 	- v3 submission was missing one patch (1/7). Re-add it.
> > Changes from v2:
> > 	- add a new test, split patches differently add code comments
> > 		 to address comments by Junio
> > 	- rename example addresses in tests from redhat.com to example.com
> > Changes from v1:
> >         - tweak coding style in tests to address comments by Junio
> 
> Nice.  This round cleanly applies and the interdiff since v2 looked
> sensible.
> 
> Will replace and merge to 'next' shortly.
> 
> Thanks.

Wellcome.

With respect to this, and a bit off-topic, what's
the best way to revise patch series?

What I did, given series in patchvN-1/:

	rm -fr patchvN #blow away old directory if there
			# otherwise I get two copies of patches if I renamed any
	git branch|fgrep '*'
	# Figure out on which branch I am, manually specify the correct upstream I'm tracking,
	# otherwise I get a ton of unrelated patches.
	git format-patch --cover --subject-prefix='PATCH vN' -o patchvN origin/master..

	vi patchvN/0000* patchvN-1/0000*

	#manually copy subject, Cc list and text from vN-1 to vN cover letter,
	#leave stats intact.

	git log origin/master.. |grep -e Cc: -e Reviewed -e Acked
	# manually Look who reviewed/acked all patches in previous versions -
	# if so copy them on cover letter too.

	git send-email --cc=junio patchvN/*

lots of manual steps here.
Any ways to automate?


> >
> > Michael S. Tsirkin (7):
> >   t/send-email.sh: add test for suppress-cc=self
> >   send-email: fix suppress-cc=self on cccmd
> >   t/send-email: test suppress-cc=self on cccmd
> >   send-email: make --suppress-cc=self sanitize input
> >   t/send-email: add test with quoted sender
> >   t/send-email: test suppress-cc=self with non-ascii
> >   test-send-email: test for pre-sanitized self name
> >
> >  git-send-email.perl   | 23 ++++++++++------
> >  t/t9001-send-email.sh | 75 +++++++++++++++++++++++++++++++++++++++++++++++++++
> >  2 files changed, 90 insertions(+), 8 deletions(-)

Re: [PATCH v4 0/7] git send-email suppress-cc=self fixes

[Junio C Hamano]

"Michael S. Tsirkin" <mst@redhat.com> writes:

> With respect to this, and a bit off-topic, what's
> the best way to revise patch series?
>
> What I did, given series in patchvN-1/:
>
> 	rm -fr patchvN #blow away old directory if there
> 			# otherwise I get two copies of patches if I renamed any

Not needed with recent "git format-patch -v4" option.

> 	git branch|fgrep '*'
> 	# Figure out on which branch I am, manually specify the correct upstream I'm tracking,
> 	# otherwise I get a ton of unrelated patches.

git-prompt with PS1 you do not need this either.

> 	git format-patch --cover --subject-prefix='PATCH vN' -o patchvN origin/master..

Again, "git format-patch -v4 -o mt-send-email" will deposit the new
ones alongside the older round.

> 	vi patchvN/0000* patchvN-1/0000*

Same (i.e. "vi mt-send-email/v*-0000-*.txt).

Re: [PATCH v4 0/7] git send-email suppress-cc=self fixes

[Michael S. Tsirkin]

On Sun, Jun 09, 2013 at 04:25:11PM -0700, Junio C Hamano wrote:
> "Michael S. Tsirkin" <mst@redhat.com> writes:
> 
> > With respect to this, and a bit off-topic, what's
> > the best way to revise patch series?
> >
> > What I did, given series in patchvN-1/:
> >
> > 	rm -fr patchvN #blow away old directory if there
> > 			# otherwise I get two copies of patches if I renamed any
> 
> Not needed with recent "git format-patch -v4" option.

Unless I rerun with same vX :(
Would it make sense for it to check for vX existance and fail?
Same without -vX, when 000X exists ...
Could be an option.

> > 	git branch|fgrep '*'
> > 	# Figure out on which branch I am, manually specify the correct upstream I'm tracking,
> > 	# otherwise I get a ton of unrelated patches.
> 
> git-prompt with PS1 you do not need this either.

grep serves just as well but
I still need to copy it to the next line manually...

I vaguely remember there was some way to say
"head of the remote I am tracking" - but I could not find it.
Where are all the tricks like foo^{} documented?
I tried fgrep '{}' Documentation/*txt and it only returned
git-show-ref.txt which isn't really informative ...

Additionally, or alternatively, would it make sense for git format-patch
to format the diff against the tracking branch by default?

> > 	git format-patch --cover --subject-prefix='PATCH vN' -o patchvN origin/master..
> 
> Again, "git format-patch -v4 -o mt-send-email" will deposit the new
> ones alongside the older round.
> 
> > 	vi patchvN/0000* patchvN-1/0000*
> 
> Same (i.e. "vi mt-send-email/v*-0000-*.txt).

I still need to copy subject, Cc list and blurb to the next line manually.
Now that there's a concept of revisions,
maybe git format-patch -v4 could copy the text
and subject from v3?

-- 
MST

Re: [PATCH v4 0/7] git send-email suppress-cc=self fixes

[John Keeping]

On Mon, Jun 10, 2013 at 09:53:24AM +0300, Michael S. Tsirkin wrote:
> I vaguely remember there was some way to say
> "head of the remote I am tracking" - but I could not find it.
> Where are all the tricks like foo^{} documented?

gitrevisions(7) is what you're looking for here.

In this case I think you want '@{upstream}' or its short form '@{u}'.

> I tried fgrep '{}' Documentation/*txt and it only returned
> git-show-ref.txt which isn't really informative ...

'{' and '}' need to be escaped in AsciiDoc so you have to grep for
'\\{\\}'.

Re: [PATCH v4 0/7] git send-email suppress-cc=self fixes

[Michael S. Tsirkin]

On Mon, Jun 10, 2013 at 08:29:31AM +0100, John Keeping wrote:
> On Mon, Jun 10, 2013 at 09:53:24AM +0300, Michael S. Tsirkin wrote:
> > I vaguely remember there was some way to say
> > "head of the remote I am tracking" - but I could not find it.
> > Where are all the tricks like foo^{} documented?
> 
> gitrevisions(7) is what you're looking for here.

I see. And git(1) actually points to it.
Thanks!

> In this case I think you want '@{upstream}' or its short form '@{u}'.
> 
> > I tried fgrep '{}' Documentation/*txt and it only returned
> > git-show-ref.txt which isn't really informative ...
> 
> '{' and '}' need to be escaped in AsciiDoc so you have to grep for
> '\\{\\}'.

Re: [PATCH v4 0/7] git send-email suppress-cc=self fixes

[Junio C Hamano]

"Michael S. Tsirkin" <mst@redhat.com> writes:

>> Not needed with recent "git format-patch -v4" option.
>
> Unless I rerun with same vX :(
> Would it make sense for it to check for vX existance and fail?
> Same without -vX, when 000X exists ...
> Could be an option.

Oh, instead of exact -v$N, trigger it with "-v auto" or something?
Sounds like a good addition.

And instead of ***BLURBHERE*** placeholder, text from old round
could be copied as a new placeholder.  I do not offhand think that
needs much thought about compatibility but maybe there are people
who trained their editors or scripts to find the known placeholder
string and edit it?  I dunno.  It certainly sounds like a sensible
thing to do to carry as much information forward from the older
round if/when we know which one corresponds to which.

Discussions and patches welcome.

>> > 	git branch|fgrep '*'
>> > 	# Figure out on which branch I am, manually specify the correct upstream I'm tracking,
>> > 	# otherwise I get a ton of unrelated patches.
>> 
>> git-prompt with PS1 you do not need this either.
>
> grep serves just as well but
> I still need to copy it to the next line manually...
>
> I vaguely remember there was some way to say
> "head of the remote I am tracking" - but I could not find it.

Do you mean @{upstream}?

> Where are all the tricks like foo^{} documented?

Documentation/revisions.txt?

> Additionally, or alternatively, would it make sense for git format-patch
> to format the diff against the tracking branch by default?

Meaning "git format-patch @{u}" without saying anything about @{u}?
I am not sure if we want to go that far, but it certainly is worth a
thought.