Junio! Thank you for your response :) On Sat, Mar 22, 2008 at 12:51:34PM -0700, Junio C Hamano wrote: > This is a mixed bag. > > Your changes to mailinfo is fine, and I think it may make even more sense > to also parse out In-Reply-To: and References: to capture the message > context better. I've found that all I need could be parsed by less changes in mailinfo. By adding header fields I need to 'header' array :) > > On the other hand, I'd NAK changes to pretty.c and commit-tree.c; it is > wrong to place that information in new commit object header. The commit > object header is a place to store information common to all commit objects > (authorship and committer) and the structural information that is required > to correctly handle the commit objects (pointers to trees and commits, and > encoding that tells what the message part is in if it is not in UTF-8). I see... > > Just like workflows inspired by the kernel project use Signed-off-by: and > Acked-by: information in the commit message part to keep track of the flow > of patches, and some distro folks say "Closes #nnn" in their messages to > close their issue tracking system entries, your "message" is information > only useful to a particular workflow and convention, and belongs to the > commit log message body, not in the object header. Ok. > > Wouldn't it work equally well to use applypatch-msg hook? Use your > updated mailinfo to parse necessary information out of the incoming > message, and add Message-ID: to the commit log messsage, perhaps at the > end, in that hook? applypatch-msg hook executed on message applying, after that there could be useful to test applied patch, so it is not the place for notification sending. -- Best regards, anton mailto:agladkov@xxxxx -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html