Duy Nguyen <pclo...@gmail.com> writes:

> On Wed, Oct 23, 2013 at 2:50 AM, Junio C Hamano <gits...@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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to