Re: RFE: support change-id generation natively

> On Wed, Oct 23, 2013 at 11:00 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> 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.
> 
> I don't have the source code.

> But the commit-msg hook document [1]
> describes roughly what you wrote below, except the tree part. And I
> suppose the hook has been working fine so far. Reading back the
> original post, James ruled out always-active hooks in general and
> wanted the control per command line. Perhaps we should add
> --no-hooks[=<name>,<name>] to "git commit"? Or maybe it's still
> inconvenient and --change-id is best.
> 
> [1] http://gerrit-documentation.googlecode.com/svn/Documentation/2.0/cmd-hook-commit-msg.html
> 
>> 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.
> -- 
> Duy
> --
> 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