Re: RFE: support change-id generation natively

> Duy Nguyen <pclouds@gmail.com> writes:
>
>> On Wed, Oct 23, 2013 at 2:50 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>> It would be just the matter of updating commit_tree_extended() in
>>> commit.c to:
>>>
>>>  - detect the need to add a new Change-Id: trailer;
>>>
>>>  - call hash_sha1_file() on the commit object buffer (assuming that
>>>    a commit object that you can actually "git cat-file commit" using
>>>    the change Id does not have to exist anywhere for Gerrit to
>>>    work---otherwise you would need to call write_sha1_file()
>>>    instead) before adding Change-Id: trailer;
>>>
>>>  - add Change-Id: trailer to the buffer; and then finally
>>>
>>>  - let the existing write_sha1_file() to write it out.
>>
>> I'm not objecting special support for Gerrit, but if the change is
>> just commit_tree_extended() why don't we just ship the commit hook in
>> a new "Gerrit" template?
>
> It is not clear to me how you envision to make it work.

> Naïvely thinking, an obvious place to do this kind of thing may be
> the "commit-msg" hook, where the hook reads what the user prepared,
> finds that there is no existing "Change-Id:" trailer, and decides to
> add one.
>
> But what value would it add on that line as the Id?
>
> It wants to use the name of the commit object that would result if
> it were to return without further editing the given message, but we
> do not give such a commit object name to the hook, so the hook needs
> to duplicate the logic to come up with one.  It may be doable (after
> all, builtin/commit.c is open source), but we do not give the hook
> the commit object header (i.e. it does not know what the tree,
> parent(s), author, committer lines would say, nor it does not know
> if we are going to add an encoding line), so the hook needs to guess
> what we will put there, too.