Subject: Re: recommendation for patch maintenance

From: Manlio Perillo <[email-masked]>
Date: Fri, 21 Dec 2012 22:30:57 +0100

Il 21/12/2012 19:17, Junio C Hamano ha scritto:
> [...]
> Of course you can plan ahead (this is what I usually do when working
> on a series that is not "how about this" throw-away patch I send to
> this list all the time) and name the topic "topic-v1", fork the new
> round "topic-v2", "topic-v3", etc. and do things like
> 
>     $ sh -c 'git diff topic-v2~$1 topic-v3~$1' - 4
> 
> (the point being that then you do ^P or whatever shell command
> history mechanism to recall that line, edit "4" to "3" and rerun the
> comparison for other corresponding ones).
> 

Thanks, this seems fine.
Maybe topic-v2 --> topic/v2 (it looks better to me).

> On a related but different front, I've been thinking about improving
> the "format-patch --subject-prefix" mechanism to make it even easier
> to use.
>
> [...]
>
> What if we added another option, say --reroll $n (or -v$n), to let
> you write:
> 
>     $ git format-patch --cover-letter -v4 -o ./+mp master
> 
> that produces output files named like:
> 
>     ./+mp/v4-0000-cover-letter.txt
>     ./+mp/v4-0001-git-completion.bash.add-support-for-pa.txt
> 
> with the subject '[PATCH v4]' prefix?
> 

I think it is a good idea to reduce the things one have to do by hand.
I, too, was thinking something similar, with a -v$n option.

And, from these few days I have started to follow the mailing list, it
seems that '[PATCH v$n'] is the standard practice.

By the way, I would also like to be able to set the default value for
the --output option in config file; something like:

  [format]
  output = +mp/$(git symbolic-ref --short HEAD)

where the string will be processed by the shell:

   sh -c 'printf "+mp/$(git symbolic-ref --short HEAD)'"

Note that printf is POSIX, and the standard suggests to use it instead
of echo:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/echo.html

I have read the affected source code, and it should not be too hard.
What do you think?

I should be able to hack the patch in the weekend, but I'm not sure it
will be accepted.

> Then you can transplant the cover letter material from the cover
> letter from the older iteration to the new cover letter in your
> editor, and sending them out will become
> 
>     $ git send-email ... ./+mp/v4-*.txt
> 
> Hmm?

Seems good.

Regards   Manlio