Junio!
Thank you for your response :)

On Sat, Mar 22, 2008 at 12:51:34PM -0700, Junio C Hamano wrote:
quoted text
> 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 :)

quoted text
> 
> 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...

quoted text
> 
> 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.

quoted text
> 
> 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@sw.ru
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html