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. 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html