On Wed, Oct 23, 2013 at 11:00 PM, Junio C Hamano <gits...@pobox.com> wrote: > 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.
I don't have the source code. But the commit-msg hook document  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.  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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html