Re: RFE: support change-id generation natively

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Oct 23, 2013 at 11:00 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Duy Nguyen <pclouds@xxxxxxxxx> writes:
>
>> On Wed, Oct 23, 2013 at 2:50 AM, Junio C Hamano <gitster@xxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]