It is a nuisance that the emails for a patch series have to be
hand-edited after they are generated by "git format-patch". Some of the
problems with this workflow are
1. The extra information typed into the email series is not archived in
the git repository, and therefore the emails have to be kept around.
2. If it is discovered between "git format-patch" and "git send-email"
that one of the patches needs a tweak, then the email series has to be
generated anew and all of the hand-edits need to be redone.
3. If a "v2" of the patch series has to be created, all of the
hand-edits have to be done again.
4. There is no place to store the "additional information" (the part
that comes in patch emails between the "---" and the diffstat) while
working on the patch series; it all has to be remembered or noted
somewhere else until just before sending off the patch emails.
Wouldn't it be nice if more of the information needed by "git
format-patch" could be extracted from the git repository? For example:
* The subject and body of the cover letter could be written to the log
message of an annotated tag at the tip of the patch series. "git
format-patch" could retrieve it if the "--cover-letter" option is used.
* The CC and ACK lists could be written as specially-formatted lines in
the annotated tag's log message, or perhaps in a git note.
* The "additional information" could be written to git notes.
I don't know whether git notes are the right vessel for such
information. For example, are they carried along when a commit is rebased?
I don't have time to implement any of this, but perhaps somebody thinks
this is a good idea and is inspired to work on it.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
Michael Haggerty [off-list ref] writes:
1. The extra information typed into the email series is not archived in
the git repository, and therefore the emails have to be kept around.
The convention is to have information that is not meant to be kept around
after '---', so...
2. If it is discovered between "git format-patch" and "git send-email"
that one of the patches needs a tweak, then the email series has to be
generated anew and all of the hand-edits need to be redone.
I actually often work this backwards. Tweak the patch files, apply them to
commit that they are meant to be applied, retest and then finally send.
There is no "generating anew" involved.
4. There is no place to store the "additional information" (the part
that comes in patch emails between the "---" and the diffstat) while
working on the patch series;...
I thought there was a RFC floating around to do this using notes and also
teach it to "commit -e" a few months ago? I vaguelly recall that Peff and
one of the J's were involved, so I am CC'ing them.
Junio C Hamano venit, vidit, dixit 27.08.2011 20:46:
Michael Haggerty [off-list ref] writes:
quoted
1. The extra information typed into the email series is not archived in
the git repository, and therefore the emails have to be kept around.
The convention is to have information that is not meant to be kept around
after '---', so...
quoted
2. If it is discovered between "git format-patch" and "git send-email"
that one of the patches needs a tweak, then the email series has to be
generated anew and all of the hand-edits need to be redone.
I actually often work this backwards. Tweak the patch files, apply them to
commit that they are meant to be applied, retest and then finally send.
There is no "generating anew" involved.
quoted
4. There is no place to store the "additional information" (the part
that comes in patch emails between the "---" and the diffstat) while
working on the patch series;...
I thought there was a RFC floating around to do this using notes and also
teach it to "commit -e" a few months ago? I vaguelly recall that Peff and
one of the J's were involved, so I am CC'ing them.
Don't forget the MJ ;)
My current setup is:
A. I put the additional per commit info in notes. "git format-patch
--notes" takes it from there and adds it where it belongs.
B. I put series title and cover letter text into a ref note. "git branch
--notes" displays them as a branch note, and "git format-patch --cover
--notes" fills in the cover letter for me.
A patch for A has been on the list, but Junio didn't like the additional
"---" which I had for technical reasons, and I haven't had time to
revisit that patch yet. (The code would have to store a flag about notes
having been inserted or not.) Nobody has complained about the patches
I've created with that form, though ;)
The stuff for B is part of my "ref notes" stuff which I haven't
submitted so far. I've been using it for quite a while now, but am still
unsure about some design aspects.
A is simply my branch "format-patch-notes".
B uses these:
vob/virtual-objects
vob/refrev-hash
vob/branch-notes
vob/format-patch-branch-note
(Merge in this order. Last one is the most immature.)
Note that I rebase frequently these days because of overlapping work in
these areas.
I think Jeff had an interesting patch allowing to edit the note along
side (OK: at the bottom of) the commit message.
Cheers,
Michael
Oh, repo, yes... Any of these:
git://github.com/gitigit/git.git
git://gitorious.org/~mjg/git/mjg.git
git://repo.or.cz/git/mjg.git
On 08/27/2011 10:35 PM, Michael J Gruber wrote:
My current setup is:
A. I put the additional per commit info in notes. "git format-patch
--notes" takes it from there and adds it where it belongs.
B. I put series title and cover letter text into a ref note. "git branch
--notes" displays them as a branch note, and "git format-patch --cover
--notes" fills in the cover letter for me.
Very cool. I will check this out.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/