{"thread":{"id":"35173","subject":"RFE: support change-id generation natively","startedAt":"2013-10-21T14:48:00Z","lastAt":"2013-10-25T06:37:28Z","messageCount":24,"participants":["james.moger@gitblit.com","Jeremy Rosen","Shawn Pearce","Ondřej Bílka","Thomas Koch","Martin Fick","Junio C Hamano","Pyeron, Jason J CTR (US)","Duy Nguyen","Nasser Grainawi","Johannes Sixt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"229246","messageId":"1382366880.8925.36578285.27469B22@webmail.messagingengine.com","threadId":"35173","inReplyTo":null,"subject":"RFE: support change-id generation natively","fromName":"","fromEmail":"james.moger@gitblit.com","sentAt":"2013-10-21T14:48:00Z","receivedAt":"2013-10-21T14:48:00Z","isPatch":false,"sender":{"key":"james.moger@gitblit.com","avatar":"https://gravatar.com/avatar/b01fc0c23e209d5d05b95a628673d55fdc2d22b79fac5e517ecc32ef8771dcdd?d=mp&s=160"},"body":"Hello Git Community,\n\nTL;DR:\nIt would be a really nice enhancement if the commit command natively\nsupported _optionally_ injecting a \"Change-Id: I000...\" footer in the\nlast paragraph of the commit message template and then substituting the\n\"I000...\" value, on commit, with a generated value _without_ having to\nrely on a per-repository, native hook or a global hook that affects\nevery local repository.\n\nFull Request:\nGerrit has established the change-id footer as a prominent and\nwide-spread collaboration identifier. For those contributing new\npatches to a Gerrit server, it is required to either use EGit/JGit\n(Eclipse) to generate commits [1] OR to use a commit hook script with\nnative git to insert a change-id footer during the commit process [2]. \nThis per-repository hook script requirement is an obstacle. These\ncommunities would be better served and it would lower the contribution\nbarrier for many open source projects if native git supported change-id\ngeneration & injection.\n\nI acknowledge that not everyone uses nor wants to use Gerrit and the\nchange-id footer. That is fine, but it would be a _tremendous_\nusability improvement for those contributing to open source projects\n(myself included) if something like a \"--change-id\" flag was\nimplemented and maybe even a config setting to always generate a\nchange-id on commit (EGit currently supports this as\n\"gerrit.createchangeid=true\").\n\nSadly, my C skills are lacking as I live mostly in the world of managed\ncode, but I'd be very happy to cheer for a change-id champion; I suspect\nthere are some out there who might rally to this cause.\n\nThanks for your consideration.\nJames Moger\ngitblit.com\n\n[1]\nhttps://git.eclipse.org/c/jgit/jgit.git/tree/org.eclipse.jgit/src/org/eclipse/jgit/api/CommitCommand.java?h=stable-3.1#n288\n[2]\nhttp://gerrit-documentation.googlecode.com/svn/Documentation/2.0/cmd-hook-commit-msg.html\n"},{"id":"229247","messageId":"2127507934.9293293.1382367063640.JavaMail.root@openwide.fr","threadId":"35173","inReplyTo":"1382366880.8925.36578285.27469B22@webmail.messagingengine.com","subject":"Re: RFE: support change-id generation natively","fromName":"Jeremy Rosen","fromEmail":"jeremy.rosen@openwide.fr","sentAt":"2013-10-21T14:51:03Z","receivedAt":"2013-10-21T14:51:03Z","isPatch":false,"sender":{"key":"jeremy.rosen@openwide.fr","avatar":null},"body":"for those of us that are not using gerrit...\n\nwhat is a change-id (semantically, I got from your mail that it is some sort\nof unit id set at commit time) and in what way is it different from the \ncommit-id ?\n\nCordialement \n\nJérémy Rosen \n+33 (0)1 42 68 28 04\n\nfight key loggers : write some perl using vim \n\n\nOpen Wide Ingenierie\n\n23, rue Daviel\n75012 Paris - France\nwww.openwide.fr\n\n\n\n\n\n----- Mail original -----\n> Hello Git Community,\n> \n> TL;DR:\n> It would be a really nice enhancement if the commit command natively\n> supported _optionally_ injecting a \"Change-Id: I000...\" footer in the\n> last paragraph of the commit message template and then substituting\n> the\n> \"I000...\" value, on commit, with a generated value _without_ having\n> to\n> rely on a per-repository, native hook or a global hook that affects\n> every local repository.\n> \n> Full Request:\n> Gerrit has established the change-id footer as a prominent and\n> wide-spread collaboration identifier. For those contributing new\n> patches to a Gerrit server, it is required to either use EGit/JGit\n> (Eclipse) to generate commits [1] OR to use a commit hook script with\n> native git to insert a change-id footer during the commit process\n> [2].\n> This per-repository hook script requirement is an obstacle. These\n> communities would be better served and it would lower the\n> contribution\n> barrier for many open source projects if native git supported\n> change-id\n> generation & injection.\n> \n> I acknowledge that not everyone uses nor wants to use Gerrit and the\n> change-id footer. That is fine, but it would be a _tremendous_\n> usability improvement for those contributing to open source projects\n> (myself included) if something like a \"--change-id\" flag was\n> implemented and maybe even a config setting to always generate a\n> change-id on commit (EGit currently supports this as\n> \"gerrit.createchangeid=true\").\n> \n> Sadly, my C skills are lacking as I live mostly in the world of\n> managed\n> code, but I'd be very happy to cheer for a change-id champion; I\n> suspect\n> there are some out there who might rally to this cause.\n> \n> Thanks for your consideration.\n> James Moger\n> gitblit.com\n> \n> [1]\n> https://git.eclipse.org/c/jgit/jgit.git/tree/org.eclipse.jgit/src/org/eclipse/jgit/api/CommitCommand.java?h=stable-3.1#n288\n> [2]\n> http://gerrit-documentation.googlecode.com/svn/Documentation/2.0/cmd-hook-commit-msg.html\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n> \n"},{"id":"229248","messageId":"1382370119.28365.36627953.50C0496E@webmail.messagingengine.com","threadId":"35173","inReplyTo":"2127507934.9293293.1382367063640.JavaMail.root@openwide.fr","subject":"Re: RFE: support change-id generation natively","fromName":"","fromEmail":"james.moger@gitblit.com","sentAt":"2013-10-21T15:41:59Z","receivedAt":"2013-10-21T15:41:59Z","isPatch":false,"sender":{"key":"james.moger@gitblit.com","avatar":"https://gravatar.com/avatar/b01fc0c23e209d5d05b95a628673d55fdc2d22b79fac5e517ecc32ef8771dcdd?d=mp&s=160"},"body":"The change-id is exactly like a commit-id, it is an SHA-1 value, but it\nis a constant embedded in the commit message.\n\nWhy does Gerrit need this value?\nGerrit is based on the concept of revising/polishing a commit or a\nseries of commits.\n\nFor clarity, consider the case of revising a proposed bug fix.\n\nYou checkout the current revision of a proposed bug fix commit that has\na change-id value in it's message. You revise and _amend_ this commit,\npreserving the change-id in the commit message. Now your commit-id has\nchanged, but your change-id is still the same. You then upload your\namended commit to Gerrit which links the amended commit with the\ndiscussion/review.\n\nCommit-ids change all the time because of amend; change-ids are constant\nand they are the key that links commit revisions to a discussion.\n\nWhat I am requesting is a feature that generates and injects the\nChange-Id value for the very first commit revision. This commit is\nspecial because it will create the discussion in Gerrit for the commit. \nGerrit relies on client-side change-id generation for this initial\ncommit. This allows contributors to propose new ideas by implementing\nthat idea and pushing the proposed implementation to Gerrit. Gerrit\nintercepts this and automatically creates a discussion/review keyed by\nthe specified Change-Id value. And now through the --amend process,\nthis commit can be revised and polished until it is blessed by a\nreviewer for merging to some integration branch.\n\n-J\n\n\n\nOn Mon, Oct 21, 2013, at 10:51 AM, Jeremy Rosen wrote:\n> for those of us that are not using gerrit...\n> \n> what is a change-id (semantically, I got from your mail that it is some\n> sort\n> of unit id set at commit time) and in what way is it different from the \n> commit-id ?\n> \n> Cordialement \n> \n> Jérémy Rosen \n> +33 (0)1 42 68 28 04\n> \n> fight key loggers : write some perl using vim \n> \n> \n> Open Wide Ingenierie\n> \n> 23, rue Daviel\n> 75012 Paris - France\n> www.openwide.fr\n> \n> \n> \n> \n> \n> ----- Mail original -----\n> > Hello Git Community,\n> > \n> > TL;DR:\n> > It would be a really nice enhancement if the commit command natively\n> > supported _optionally_ injecting a \"Change-Id: I000...\" footer in the\n> > last paragraph of the commit message template and then substituting\n> > the\n> > \"I000...\" value, on commit, with a generated value _without_ having\n> > to\n> > rely on a per-repository, native hook or a global hook that affects\n> > every local repository.\n> > \n> > Full Request:\n> > Gerrit has established the change-id footer as a prominent and\n> > wide-spread collaboration identifier. For those contributing new\n> > patches to a Gerrit server, it is required to either use EGit/JGit\n> > (Eclipse) to generate commits [1] OR to use a commit hook script with\n> > native git to insert a change-id footer during the commit process\n> > [2].\n> > This per-repository hook script requirement is an obstacle. These\n> > communities would be better served and it would lower the\n> > contribution\n> > barrier for many open source projects if native git supported\n> > change-id\n> > generation & injection.\n> > \n> > I acknowledge that not everyone uses nor wants to use Gerrit and the\n> > change-id footer. That is fine, but it would be a _tremendous_\n> > usability improvement for those contributing to open source projects\n> > (myself included) if something like a \"--change-id\" flag was\n> > implemented and maybe even a config setting to always generate a\n> > change-id on commit (EGit currently supports this as\n> > \"gerrit.createchangeid=true\").\n> > \n> > Sadly, my C skills are lacking as I live mostly in the world of\n> > managed\n> > code, but I'd be very happy to cheer for a change-id champion; I\n> > suspect\n> > there are some out there who might rally to this cause.\n> > \n> > Thanks for your consideration.\n> > James Moger\n> > gitblit.com\n> > \n> > [1]\n> > https://git.eclipse.org/c/jgit/jgit.git/tree/org.eclipse.jgit/src/org/eclipse/jgit/api/CommitCommand.java?h=stable-3.1#n288\n> > [2]\n> > http://gerrit-documentation.googlecode.com/svn/Documentation/2.0/cmd-hook-commit-msg.html\n> > --\n> > To unsubscribe from this list: send the line \"unsubscribe git\" in\n> > the body of a message to majordomo@vger.kernel.org\n> > More majordomo info at http://vger.kernel.org/majordomo-info.html\n> > \n"},{"id":"229249","messageId":"CAJo=hJtbciJ3Qg8jo4U5fZ9onf2R2XOospYKGS-jCYz4p-nwRw@mail.gmail.com","threadId":"35173","inReplyTo":"1382370119.28365.36627953.50C0496E@webmail.messagingengine.com","subject":"Re: RFE: support change-id generation natively","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2013-10-21T16:35:07Z","receivedAt":"2013-10-21T16:35:07Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"On Mon, Oct 21, 2013 at 8:41 AM, wrote:\n> The change-id is exactly like a commit-id, it is an SHA-1 value, but it\n> is a constant embedded in the commit message.\n\nhttps://gerrit-review.googlesource.com/Documentation/user-changeid.html\ngoes into more detail about these.\n\n> Commit-ids change all the time because of amend; change-ids are constant\n> and they are the key that links commit revisions to a discussion.\n\nIn a mailing list based workflow, when an author revises a patch\nseries and resends the new patches aren't linked to the old patches in\na MUA, because the Message-Ids of the original versions were not\npreserved. Imagine if Git saved that original Message-Id somewhere and\ncould properly write In-Reply-To headers so that attempt #2 for each\npatch replies to the end of the thread discussing attempt #1 of the\nsame patch. In a 30 patch series. Gerrit does this with Change-Id.\n\n\nWe briefly considered putting the Change-Id into the commit headers\n(e.g. below the optional encoding) but could not because `git commit`\ndoesn't support this. So it went into the footer along with\nSigned-off-by provenance data, which is also not expressible in\nheaders.\n"},{"id":"229250","messageId":"20131021163812.GA27125@domone.podge","threadId":"35173","inReplyTo":"CAJo=hJtbciJ3Qg8jo4U5fZ9onf2R2XOospYKGS-jCYz4p-nwRw@mail.gmail.com","subject":"Re: RFE: support change-id generation natively","fromName":"Ondřej Bílka","fromEmail":"neleai@seznam.cz","sentAt":"2013-10-21T16:38:12Z","receivedAt":"2013-10-21T16:38:12Z","isPatch":false,"sender":{"key":"neleai@seznam.cz","avatar":"https://avatars.githubusercontent.com/u/48067?v=4"},"body":"On Mon, Oct 21, 2013 at 09:35:07AM -0700, Shawn Pearce wrote:\n> On Mon, Oct 21, 2013 at 8:41 AM, wrote:\n> > The change-id is exactly like a commit-id, it is an SHA-1 value, but it\n> > is a constant embedded in the commit message.\n> \n> https://gerrit-review.googlesource.com/Documentation/user-changeid.html\n> goes into more detail about these.\n> \n> > Commit-ids change all the time because of amend; change-ids are constant\n> > and they are the key that links commit revisions to a discussion.\n> \n> In a mailing list based workflow, when an author revises a patch\n> series and resends the new patches aren't linked to the old patches in\n> a MUA, because the Message-Ids of the original versions were not\n> preserved. Imagine if Git saved that original Message-Id somewhere and\n> could properly write In-Reply-To headers so that attempt #2 for each\n> patch replies to the end of the thread discussing attempt #1 of the\n> same patch. In a 30 patch series. Gerrit does this with Change-Id.\n> \n> \n> We briefly considered putting the Change-Id into the commit headers\n> (e.g. below the optional encoding) but could not because `git commit`\n> doesn't support this. So it went into the footer along with\n> Signed-off-by provenance data, which is also not expressible in\n> headers.\n\nWhat about adding that as Note?\n"},{"id":"229254","messageId":"201310212029.01589.thomas@koch.ro","threadId":"35173","inReplyTo":"1382370119.28365.36627953.50C0496E@webmail.messagingengine.com","subject":"Re: RFE: support change-id generation natively","fromName":"Thomas Koch","fromEmail":"thomas@koch.ro","sentAt":"2013-10-21T18:29:00Z","receivedAt":"2013-10-21T18:29:00Z","isPatch":false,"sender":{"key":"thomas@koch.ro","avatar":null},"body":"On Monday, October 21, 2013 05:41:59 PM james.moger@gitblit.com wrote:\n> The change-id is exactly like a commit-id, it is an SHA-1 value, but it\n> is a constant embedded in the commit message.\n\nAs I understand, a UUID could also be used for the same purbose as the change-\nid. How is the change-id generated by the way? Would it be a good english name \nto call it enduring commit identifier?\n\nI had an usage example for such identifiers last week while helping to rebase \nand merge a few too long standing feature branches. After a while we noticed, \nthat a few commits where already cherry-picked in a slightly different form and \nwith different commit message to the integration branch. If those commit had \nenduring identifiers, it would have been easier to spot this.\n\nGit already has functionality to identify commits that have already been \ncherry-picked or merged in a branch and thus skips them in a rebase. Could \nthis functionality benefit from an enduring commit identifier?\n\nBest regards, Thomas Koch\n"},{"id":"229256","messageId":"1382380858.25852.36711509.53CF173C@webmail.messagingengine.com","threadId":"35173","inReplyTo":"201310212029.01589.thomas@koch.ro","subject":"Re: RFE: support change-id generation natively","fromName":"","fromEmail":"james.moger@gitblit.com","sentAt":"2013-10-21T18:40:58Z","receivedAt":"2013-10-21T18:40:58Z","isPatch":false,"sender":{"key":"james.moger@gitblit.com","avatar":"https://gravatar.com/avatar/b01fc0c23e209d5d05b95a628673d55fdc2d22b79fac5e517ecc32ef8771dcdd?d=mp&s=160"},"body":"\nOn Mon, Oct 21, 2013, at 02:29 PM, Thomas Koch wrote:\n> As I understand, a UUID could also be used for the same purbose as the\n> change-\n> id. How is the change-id generated by the way? Would it be a good english\n> name \n> to call it enduring commit identifier?\n\nHere is the algorithm:\nhttps://git.eclipse.org/c/jgit/jgit.git/tree/org.eclipse.jgit/src/org/eclipse/jgit/util/ChangeIdUtil.java#n78\n\nI think \"enduring commit id\" is a fair interpretation of it's purpose. \nI don't speak for the Gerrit developers so I can not say if they are\ninterested in alternative id generation. I come to the list as a\nchange-id user/consumer.\n\n-J\n"},{"id":"229258","messageId":"201310211249.49568.mfick@codeaurora.org","threadId":"35173","inReplyTo":"1382380858.25852.36711509.53CF173C@webmail.messagingengine.com","subject":"Re: RFE: support change-id generation natively","fromName":"Martin Fick","fromEmail":"mfick@codeaurora.org","sentAt":"2013-10-21T18:49:49Z","receivedAt":"2013-10-21T18:49:49Z","isPatch":false,"sender":{"key":"mfick@codeaurora.org","avatar":null},"body":"On Monday, October 21, 2013 12:40:58 pm \njames.moger@gitblit.com wrote:\n> On Mon, Oct 21, 2013, at 02:29 PM, Thomas Koch wrote:\n> > As I understand, a UUID could also be used for the same\n> > purbose as the change-\n> > id. How is the change-id generated by the way? Would it\n> > be a good english name\n> > to call it enduring commit identifier?\n> \n> Here is the algorithm:\n> https://git.eclipse.org/c/jgit/jgit.git/tree/org.eclipse.\n> jgit/src/org/eclipse/jgit/util/ChangeIdUtil.java#n78\n> \n> I think \"enduring commit id\" is a fair interpretation of\n> it's purpose. I don't speak for the Gerrit developers so\n> I can not say if they are interested in alternative id\n> generation. I come to the list as a change-id\n> user/consumer.\n\nAs a Gerrit maintainer, I would suspect that we would \nwelcome a way to track \"changes\" natively in git. Despite \nany compatibility issues with the current Gerrit \nimplementation, I suspect we would be open to new forms if \nthe git community has a better proposal than the current \nChange-Id. Especially if it does reduce the significant \nuser pain point of installing a hook!\n\n\n-Martin\n\n\n-- \nThe Qualcomm Innovation Center, Inc. is a member of Code \nAurora Forum, hosted by The Linux Foundation\n \n"},{"id":"229266","messageId":"CAJo=hJudnWqCTG=j_hQjZMzYarDTH5THZOEbftLjpwKUNusrEQ@mail.gmail.com","threadId":"35173","inReplyTo":"20131021163812.GA27125@domone.podge","subject":"Re: RFE: support change-id generation natively","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2013-10-21T23:07:30Z","receivedAt":"2013-10-21T23:07:30Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"On Mon, Oct 21, 2013 at 9:38 AM, Ondřej Bílka wrote:\n> On Mon, Oct 21, 2013 at 09:35:07AM -0700, Shawn Pearce wrote:\n>> On Mon, Oct 21, 2013 at 8:41 AM, wrote:\n>> > The change-id is exactly like a commit-id, it is an SHA-1 value, but it\n>> > is a constant embedded in the commit message.\n>>\n>> https://gerrit-review.googlesource.com/Documentation/user-changeid.html\n>> goes into more detail about these.\n>>\n>> > Commit-ids change all the time because of amend; change-ids are constant\n>> > and they are the key that links commit revisions to a discussion.\n>>\n>> In a mailing list based workflow, when an author revises a patch\n>> series and resends the new patches aren't linked to the old patches in\n>> a MUA, because the Message-Ids of the original versions were not\n>> preserved. Imagine if Git saved that original Message-Id somewhere and\n>> could properly write In-Reply-To headers so that attempt #2 for each\n>> patch replies to the end of the thread discussing attempt #1 of the\n>> same patch. In a 30 patch series. Gerrit does this with Change-Id.\n>>\n>>\n>> We briefly considered putting the Change-Id into the commit headers\n>> (e.g. below the optional encoding) but could not because `git commit`\n>> doesn't support this. So it went into the footer along with\n>> Signed-off-by provenance data, which is also not expressible in\n>> headers.\n>\n> What about adding that as Note?\n\nIf it was a note, the note would need to be updated every time the\nuser updated their commit locally. So `git commit --amend` and `git\nrebase` (all forms) would be required to update the note with the new\ncommit SHA-1 so the value isn't lost.\n\nIf it was a note, the author would also have to push their notes\nbranch to the Gerrit server when they push their commits. This is\nlikely to be forgotten, since its a different branch than the branch\nthe user is working on. The server only needs notes for the new\nincoming commits, but the notes branch will probably bring all\nactivity the author has been doing. So maybe the author should have\none notes branch per topic branch. And clean up the notes branches\nafter they delete their local topic branches. Etc.\n\nnotes are great, but they get messy. And back when Gerrit introduced\nsupport for Change-Id (more than 4 years ago) I don't think note\nsupport even existed. Or if it did, it was no where near as complete\nas it is today.\n"},{"id":"229267","messageId":"CAJo=hJsEHO7ZL6UBbBBijRNHqk=ttA07cFJ7KBW381jTEpvOQw@mail.gmail.com","threadId":"35173","inReplyTo":"1382380858.25852.36711509.53CF173C@webmail.messagingengine.com","subject":"Re: RFE: support change-id generation natively","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2013-10-21T23:10:18Z","receivedAt":"2013-10-21T23:10:18Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"On Mon, Oct 21, 2013 at 11:40 AM, wrote:\n>\n> On Mon, Oct 21, 2013, at 02:29 PM, Thomas Koch wrote:\n>> As I understand, a UUID could also be used for the same purbose as the\n>> change-\n>> id. How is the change-id generated by the way? Would it be a good english\n>> name\n>> to call it enduring commit identifier?\n>\n> Here is the algorithm:\n> https://git.eclipse.org/c/jgit/jgit.git/tree/org.eclipse.jgit/src/org/eclipse/jgit/util/ChangeIdUtil.java#n78\n\nFor the hyperlink and Java challenged, the Change-Id is essentially\nthe commit SHA-1 had the Change-Id not been included. The shell script\nhook Gerrit recommends for use with `git commit` uses `git\ncommit-tree` to compute the hash. Which of course later differs after\nthe Change-Id is inserted.\n\n> I think \"enduring commit id\" is a fair interpretation of it's purpose.\n> I don't speak for the Gerrit developers so I can not say if they are\n> interested in alternative id generation. I come to the list as a\n> change-id user/consumer.\n\nAs Martin Fick said, we would be open to an alternative if a better\none is presented, especially if it is supported by git commit.\n"},{"id":"229301","messageId":"xmqqy55lrsoo.fsf@gitster.dls.corp.google.com","threadId":"35173","inReplyTo":"201310211249.49568.mfick@codeaurora.org","subject":"Re: RFE: support change-id generation natively","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-10-22T19:50:31Z","receivedAt":"2013-10-22T19:50:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Martin Fick writes:\n\n> As a Gerrit maintainer, I would suspect that we would \n> welcome a way to track \"changes\" natively in git.\n\nI would suspect that we would not mind \"git commit --change-id\" (and\nprobably \"git commit-tree --change-id\") option that can be used to\ntell the command to add a new Change-Id: trailer at the end, if and\nonly if there is none in the log message to be recorded (this needs\nto happen after the user possibly edits). We may even want to\nintroduce commit.changeId boolean configuration variable if we did\nso.\n\n\"git commit --amend\", \"git rebase\", etc. can be left oblivious to\nthe \"Change-Id:\" trailer, as the default mode of operation you guys\nwant is to leave the existing one as-is, unless the end user really\nwants to change it, I think.\n\nIt would be just the matter of updating commit_tree_extended() in\ncommit.c to:\n\n - detect the need to add a new Change-Id: trailer;\n\n - call hash_sha1_file() on the commit object buffer (assuming that\n a commit object that you can actually \"git cat-file commit\" using\n the change Id does not have to exist anywhere for Gerrit to\n work---otherwise you would need to call write_sha1_file()\n instead) before adding Change-Id: trailer;\n\n - add Change-Id: trailer to the buffer; and then finally\n\n - let the existing write_sha1_file() to write it out.\n\nI would think. You might have a funny chicken-and-egg problem with\nthe signed commit, though. I didn't think that part through.\n"},{"id":"229302","messageId":"871B6C10EBEFE342A772D1159D1320855772CBAD@umechphj.easf.csd.disa.mil","threadId":"35173","inReplyTo":"xmqqy55lrsoo.fsf@gitster.dls.corp.google.com","subject":"RE: RFE: support change-id generation natively","fromName":"Pyeron, Jason J CTR (US)","fromEmail":"jason.j.pyeron.ctr@mail.mil","sentAt":"2013-10-22T20:06:05Z","receivedAt":"2013-10-22T20:06:05Z","isPatch":false,"sender":{"key":"jason.j.pyeron.ctr@mail.mil","avatar":null},"body":"> -----Original Message-----\n> From: Junio C Hamano\n> Sent: Tuesday, October 22, 2013 3:51 PM\n> \n\n\n\n\n> I would think. You might have a funny chicken-and-egg problem with\n> the signed commit, though. I didn't think that part through.\n\nRespectfully, I do not think there is a chicken and egg situation here. Either the user has included a generated id field and value in the portion covered by the signature, or the mutation of the portion covered by the signature has been modified, hence has an invalid signature.\n\nAny user signing their commit, should ensure it is the last operation, or be prepared to resign it later.\n\nJason Pyeron \n\n"},{"id":"229305","messageId":"xmqqppqxrq8q.fsf@gitster.dls.corp.google.com","threadId":"35173","inReplyTo":"871B6C10EBEFE342A772D1159D1320855772CBAD@umechphj.easf.csd.disa.mil","subject":"Re: RFE: support change-id generation natively","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-10-22T20:43:17Z","receivedAt":"2013-10-22T20:43:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Pyeron, Jason J CTR (US)\" writes:\n\n>> -----Original Message-----\n>> From: Junio C Hamano\n>> Sent: Tuesday, October 22, 2013 3:51 PM\n>> \n>\n>\n> \n>\n>> I would think. You might have a funny chicken-and-egg problem with\n>> the signed commit, though. I didn't think that part through.\n>\n> Respectfully, I do not think there is a chicken and egg situation\n> here. Either the user has included a generated id field and value\n> in the portion covered by the signature, or the mutation of the\n> portion covered by the signature has been modified, hence has an\n> invalid signature.\n>\n> Any user signing their commit, should ensure it is the last\n> operation, or be prepared to resign it later.\n\nThanks, I think I got what you are saying.\n\nI was coming from the existing code, assuming that you have a single\ncommit without Change Id but has already called do_sign_commit().\nThat is what the users today will get out of \"commit -S\". But using\nthe object name of such a commit as the Change Id, and then creating\na new commit by appending a new Change Id trailer will not work, as\nthat will break the existing signature.\n\nBut you can begin from a single commit without Change Id and without\nsignature---its object name would be the Change Id. You can add a\nnew Change Id trailer to record that and sign it while creating a\ncommit. It conceptually may be a three-step process, but still can be\ndone inside a single invocation of \"git commit --change-id -S\".\n\nSo a rough outline of the patch to implement it may look like below.\nThe parsing and passing down of the \"--change-id\" option is left as\nan exercise to interested readers. A real patch may have to add an\nextra blank line before the strbuf_addf() if buffer.buf does not end\nwith a trailer to separate the \"Change Id\" line from the end of the\nexisting message body.\n\n commit.c | 14 +++++++++++++-\n 1 file changed, 13 insertions(+), 1 deletion(-)\n\ndiff --git a/commit.c b/commit.c\nindex de16a3c..664ef5d 100644\n--- a/commit.c\n+++ b/commit.c\n@@ -1481,17 +1481,22 @@ static const char commit_utf8_warn[] =\n int commit_tree_extended(const struct strbuf *msg, unsigned char *tree,\n \t\t\t struct commit_list *parents, unsigned char *ret,\n \t\t\t const char *author, const char *sign_commit,\n-\t\t\t struct commit_extra_header *extra)\n+\t\t\t struct commit_extra_header *extra,\n+\t\t\t unsigned int flags)\n {\n \tint result;\n \tint encoding_is_utf8;\n \tstruct strbuf buffer;\n+\tint add_change_id = !!(flags & COMMIT_ADD_CHANGE_ID);\n \n \tassert_sha1_type(tree, OBJ_TREE);\n \n \tif (memchr(msg->buf, '\\0', msg->len))\n \t\treturn error(\"a NUL byte in commit log message not allowed.\");\n \n+\tif (add_change_id && strstr(msg->buf, \"\\nChange-Id: \"))\n+\t\tadd_change_id = 0; /* already has one */\n+\n \t/* Not having i18n.commitencoding is the same as having utf-8 */\n \tencoding_is_utf8 = is_encoding_utf8(git_commit_encoding);\n \n@@ -1534,6 +1539,13 @@ int commit_tree_extended(const struct strbuf *msg, unsigned char *tree,\n \tif (encoding_is_utf8 && !verify_utf8(&buffer))\n \t\tfprintf(stderr, commit_utf8_warn);\n \n+\tif (add_change_id) {\n+\t\tunsigned char change_id[20];\n+\t\tif (hash_sha1_file(buffer.buf, buffer.len, commit_type, change_id))\n+\t\t\treturn -1;\n+\t\tstrbuf_addf(&buffer, \"Change-Id: %s\\n\", sha1_to_hex(change_id));\n+\t}\n+\n \tif (sign_commit && do_sign_commit(&buffer, sign_commit))\n \t\treturn -1;\n \n"},{"id":"229314","messageId":"CACsJy8A7r-gsbru0eLxtJbFk2vgqvBH9akHn6e53k=UJbZ1K7Q@mail.gmail.com","threadId":"35173","inReplyTo":"xmqqy55lrsoo.fsf@gitster.dls.corp.google.com","subject":"Re: RFE: support change-id generation natively","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-10-23T06:36:01Z","receivedAt":"2013-10-23T06:36:01Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Wed, Oct 23, 2013 at 2:50 AM, Junio C Hamano wrote:\n> It would be just the matter of updating commit_tree_extended() in\n> commit.c to:\n>\n> - detect the need to add a new Change-Id: trailer;\n>\n> - call hash_sha1_file() on the commit object buffer (assuming that\n> a commit object that you can actually \"git cat-file commit\" using\n> the change Id does not have to exist anywhere for Gerrit to\n> work---otherwise you would need to call write_sha1_file()\n> instead) before adding Change-Id: trailer;\n>\n> - add Change-Id: trailer to the buffer; and then finally\n>\n> - let the existing write_sha1_file() to write it out.\n\nI'm not objecting special support for Gerrit, but if the change is\njust commit_tree_extended() why don't we just ship the commit hook in\na new \"Gerrit\" template? It's just a matter of \"git init\n--template=gerrit\" (or something) to create a new repo, or reinit the\ncurrent repo and you're set. Of it per-repo is bad, perhaps we could\nintroduce global hooks (if we haven't had them yet)?\n-- \nDuy\n"},{"id":"229346","messageId":"xmqqzjq0q8nl.fsf@gitster.dls.corp.google.com","threadId":"35173","inReplyTo":"CACsJy8A7r-gsbru0eLxtJbFk2vgqvBH9akHn6e53k=UJbZ1K7Q@mail.gmail.com","subject":"Re: RFE: support change-id generation natively","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-10-23T16:00:46Z","receivedAt":"2013-10-23T16:00:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Duy Nguyen writes:\n\n> On Wed, Oct 23, 2013 at 2:50 AM, Junio C Hamano wrote:\n>> It would be just the matter of updating commit_tree_extended() in\n>> commit.c to:\n>>\n>> - detect the need to add a new Change-Id: trailer;\n>>\n>> - call hash_sha1_file() on the commit object buffer (assuming that\n>> a commit object that you can actually \"git cat-file commit\" using\n>> the change Id does not have to exist anywhere for Gerrit to\n>> work---otherwise you would need to call write_sha1_file()\n>> instead) before adding Change-Id: trailer;\n>>\n>> - add Change-Id: trailer to the buffer; and then finally\n>>\n>> - let the existing write_sha1_file() to write it out.\n>\n> I'm not objecting special support for Gerrit, but if the change is\n> just commit_tree_extended() why don't we just ship the commit hook in\n> a new \"Gerrit\" template?\n\nIt is not clear to me how you envision to make it work.\n\nNaïvely thinking, an obvious place to do this kind of thing may be\nthe \"commit-msg\" hook, where the hook reads what the user prepared,\nfinds that there is no existing \"Change-Id:\" trailer, and decides to\nadd one.\n\nBut what value would it add on that line as the Id?\n\nIt wants to use the name of the commit object that would result if\nit were to return without further editing the given message, but we\ndo not give such a commit object name to the hook, so the hook needs\nto duplicate the logic to come up with one. It may be doable (after\nall, builtin/commit.c is open source), but we do not give the hook\nthe commit object header (i.e. it does not know what the tree,\nparent(s), author, committer lines would say, nor it does not know\nif we are going to add an encoding line), so the hook needs to guess\nwhat we will put there, too.\n"},{"id":"229375","messageId":"CACsJy8CuEvdTu+P-P-kYC0dKQKnjh5sRoevd_hsbqF0796i0xw@mail.gmail.com","threadId":"35173","inReplyTo":"xmqqzjq0q8nl.fsf@gitster.dls.corp.google.com","subject":"Re: RFE: support change-id generation natively","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-10-24T02:07:41Z","receivedAt":"2013-10-24T02:07:41Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Wed, Oct 23, 2013 at 11:00 PM, Junio C Hamano wrote:\n> Duy Nguyen writes:\n>\n>> On Wed, Oct 23, 2013 at 2:50 AM, Junio C Hamano wrote:\n>>> It would be just the matter of updating commit_tree_extended() in\n>>> commit.c to:\n>>>\n>>> - detect the need to add a new Change-Id: trailer;\n>>>\n>>> - call hash_sha1_file() on the commit object buffer (assuming that\n>>> a commit object that you can actually \"git cat-file commit\" using\n>>> the change Id does not have to exist anywhere for Gerrit to\n>>> work---otherwise you would need to call write_sha1_file()\n>>> instead) before adding Change-Id: trailer;\n>>>\n>>> - add Change-Id: trailer to the buffer; and then finally\n>>>\n>>> - let the existing write_sha1_file() to write it out.\n>>\n>> I'm not objecting special support for Gerrit, but if the change is\n>> just commit_tree_extended() why don't we just ship the commit hook in\n>> a new \"Gerrit\" template?\n>\n> It is not clear to me how you envision to make it work.\n\nI don't have the source code. But the commit-msg hook document [1]\ndescribes roughly what you wrote below, except the tree part. And I\nsuppose the hook has been working fine so far. Reading back the\noriginal post, James ruled out always-active hooks in general and\nwanted the control per command line. Perhaps we should add\n--no-hooks[=,] to \"git commit\"? Or maybe it's still\ninconvenient and --change-id is best.\n\n[1] http://gerrit-documentation.googlecode.com/svn/Documentation/2.0/cmd-hook-commit-msg.html\n\n> Naïvely thinking, an obvious place to do this kind of thing may be\n> the \"commit-msg\" hook, where the hook reads what the user prepared,\n> finds that there is no existing \"Change-Id:\" trailer, and decides to\n> add one.\n>\n> But what value would it add on that line as the Id?\n>\n> It wants to use the name of the commit object that would result if\n> it were to return without further editing the given message, but we\n> do not give such a commit object name to the hook, so the hook needs\n> to duplicate the logic to come up with one. It may be doable (after\n> all, builtin/commit.c is open source), but we do not give the hook\n> the commit object header (i.e. it does not know what the tree,\n> parent(s), author, committer lines would say, nor it does not know\n> if we are going to add an encoding line), so the hook needs to guess\n> what we will put there, too.\n-- \nDuy\n"},{"id":"229378","messageId":"8D1AF6D7-F7AA-4E64-B6B3-3C8C931312C3@codeaurora.org","threadId":"35173","inReplyTo":"CACsJy8CuEvdTu+P-P-kYC0dKQKnjh5sRoevd_hsbqF0796i0xw@mail.gmail.com","subject":"Re: RFE: support change-id generation natively","fromName":"Nasser Grainawi","fromEmail":"nasser@codeaurora.org","sentAt":"2013-10-24T04:11:53Z","receivedAt":"2013-10-24T04:11:53Z","isPatch":false,"sender":{"key":"nasser@codeaurora.org","avatar":"https://avatars.githubusercontent.com/u/757421?v=4"},"body":"\nOn Oct 23, 2013, at 8:07 PM, Duy Nguyen wrote:\n\n> On Wed, Oct 23, 2013 at 11:00 PM, Junio C Hamano wrote:\n>> Duy Nguyen writes:\n>> \n>>> On Wed, Oct 23, 2013 at 2:50 AM, Junio C Hamano wrote:\n>>>> It would be just the matter of updating commit_tree_extended() in\n>>>> commit.c to:\n>>>> \n>>>> - detect the need to add a new Change-Id: trailer;\n>>>> \n>>>> - call hash_sha1_file() on the commit object buffer (assuming that\n>>>> a commit object that you can actually \"git cat-file commit\" using\n>>>> the change Id does not have to exist anywhere for Gerrit to\n>>>> work---otherwise you would need to call write_sha1_file()\n>>>> instead) before adding Change-Id: trailer;\n>>>> \n>>>> - add Change-Id: trailer to the buffer; and then finally\n>>>> \n>>>> - let the existing write_sha1_file() to write it out.\n>>> \n>>> I'm not objecting special support for Gerrit, but if the change is\n>>> just commit_tree_extended() why don't we just ship the commit hook in\n>>> a new \"Gerrit\" template?\n>> \n>> It is not clear to me how you envision to make it work.\n> \n> I don't have the source code.\n\nNow you do: https://gerrit.googlesource.com/gerrit/+/master/gerrit-server/src/main/resources/com/google/gerrit/server/tools/root/hooks/commit-msg\n\n> But the commit-msg hook document [1]\n> describes roughly what you wrote below, except the tree part. And I\n> suppose the hook has been working fine so far. Reading back the\n> original post, James ruled out always-active hooks in general and\n> wanted the control per command line. Perhaps we should add\n> --no-hooks[=,] to \"git commit\"? Or maybe it's still\n> inconvenient and --change-id is best.\n> \n> [1] http://gerrit-documentation.googlecode.com/svn/Documentation/2.0/cmd-hook-commit-msg.html\n> \n>> Naïvely thinking, an obvious place to do this kind of thing may be\n>> the \"commit-msg\" hook, where the hook reads what the user prepared,\n>> finds that there is no existing \"Change-Id:\" trailer, and decides to\n>> add one.\n>> \n>> But what value would it add on that line as the Id?\n>> \n>> It wants to use the name of the commit object that would result if\n>> it were to return without further editing the given message, but we\n>> do not give such a commit object name to the hook, so the hook needs\n>> to duplicate the logic to come up with one. It may be doable (after\n>> all, builtin/commit.c is open source), but we do not give the hook\n>> the commit object header (i.e. it does not know what the tree,\n>> parent(s), author, committer lines would say, nor it does not know\n>> if we are going to add an encoding line), so the hook needs to guess\n>> what we will put there, too.\n> -- \n> Duy\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n\n--\nThe Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,\nhosted by The Linux Foundation\n"},{"id":"229379","messageId":"CACsJy8BoqWMqGPM8JDny6mxkxZzhWrQ6RYZiNK=vzdwXL4a=vQ@mail.gmail.com","threadId":"35173","inReplyTo":"8D1AF6D7-F7AA-4E64-B6B3-3C8C931312C3@codeaurora.org","subject":"Re: RFE: support change-id generation natively","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-10-24T05:25:45Z","receivedAt":"2013-10-24T05:25:45Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, Oct 24, 2013 at 11:11 AM, Nasser Grainawi wrote:\n>>> It is not clear to me how you envision to make it work.\n>>\n>> I don't have the source code.\n>\n> Now you do: https://gerrit.googlesource.com/gerrit/+/master/gerrit-server/src/main/resources/com/google/gerrit/server/tools/root/hooks/commit-msg\n\nThanks. So you do have tree sha-1 by running \"git write-tree\". But at\nthat point I'm not sure if cache-tree is written down to disk yet, so\nwrite-tree could be more expensive than necessary (one good point for\nbuilding --change-id in).\n-- \nDuy\n"},{"id":"229380","messageId":"5268B7D6.5050106@viscovery.net","threadId":"35173","inReplyTo":"CACsJy8BoqWMqGPM8JDny6mxkxZzhWrQ6RYZiNK=vzdwXL4a=vQ@mail.gmail.com","subject":"Re: RFE: support change-id generation natively","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2013-10-24T06:01:58Z","receivedAt":"2013-10-24T06:01:58Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 10/24/2013 7:25, schrieb Duy Nguyen:\n> On Thu, Oct 24, 2013 at 11:11 AM, Nasser Grainawi wrote:\n>>>> It is not clear to me how you envision to make it work.\n>>>\n>>> I don't have the source code.\n>>\n>> Now you do: https://gerrit.googlesource.com/gerrit/+/master/gerrit-server/src/main/resources/com/google/gerrit/server/tools/root/hooks/commit-msg\n> \n> Thanks. So you do have tree sha-1 by running \"git write-tree\". But at\n> that point I'm not sure if cache-tree is written down to disk yet, so\n> write-tree could be more expensive than necessary (one good point for\n> building --change-id in).\n\nConsider that I make a commit with a change-id. Then I rewrite the commit,\nbut keep the change-id. Then I push the rewritten commit to Gerrit. Gerrit\ndoes not have the objects that the change-id is based on; the change-id is\njust a random number and has no other significance. Right?\n\nWhy do you go all the length in computing a change-id instead of just\npulling 20 bytes from /dev/random?\n\nThat said, I don't think that --change-id option that the user must not\nforget to use is any better than a hook that the user must not forget to\ninstall.\n\n-- Hannes\n"},{"id":"229396","messageId":"1382616665.23343.37953397.70FB76CB@webmail.messagingengine.com","threadId":"35173","inReplyTo":"5268B7D6.5050106@viscovery.net","subject":"Re: RFE: support change-id generation natively","fromName":"","fromEmail":"james.moger@gitblit.com","sentAt":"2013-10-24T12:11:05Z","receivedAt":"2013-10-24T12:11:05Z","isPatch":false,"sender":{"key":"james.moger@gitblit.com","avatar":"https://gravatar.com/avatar/b01fc0c23e209d5d05b95a628673d55fdc2d22b79fac5e517ecc32ef8771dcdd?d=mp&s=160"},"body":"> That said, I don't think that --change-id option that the user must not\n> forget to use is any better than a hook that the user must not forget to\n> install.\n\nHaving a --change-id option, to my mind, simplifies use of the patch\nworkflow as it does not require downloading, copying and setting\nexecutable a hook script per-repository or globally. I agree that\nforgetting to add it on the command-line is a potential problem. This\ncould be improved by honoring the \"gerrit.createchangeid\" value (or\nwhatever setting name is appropriate). Of course that still requires\nconfiguring the repo after clone, but it's clean and straight-forward\nsince it is all plain \"git config\".\n\n-J\n"},{"id":"229398","messageId":"201310241451.48788.thomas@koch.ro","threadId":"35173","inReplyTo":"1382616665.23343.37953397.70FB76CB@webmail.messagingengine.com","subject":"Re: RFE: support change-id generation natively","fromName":"Thomas Koch","fromEmail":"thomas@koch.ro","sentAt":"2013-10-24T12:51:48Z","receivedAt":"2013-10-24T12:51:48Z","isPatch":false,"sender":{"key":"thomas@koch.ro","avatar":null},"body":"On Thursday, October 24, 2013 02:11:05 PM james.moger@gitblit.com wrote:\n> > That said, I don't think that --change-id option that the user must not\n> > forget to use is any better than a hook that the user must not forget to\n> > install.\n\nI'm a bit paranoid. (e.g. I do all my development in a virtual machine and my \nhost machine only runs binaries from debian stable.)\n\nA command line option is a big improvement over having to download a random \nscript from some potentially untrusted place and executing it probably even \nwith the same user that also has access to my GPG key that signs my code and \nmy SSH key that has access to the repository.\n\nRegards, Thomas Koch\n"},{"id":"229399","messageId":"CACsJy8DA7_vGpeJw8QurmJsy9k1am4CWN2pT_RTpD+vcpQc+8g@mail.gmail.com","threadId":"35173","inReplyTo":"1382616665.23343.37953397.70FB76CB@webmail.messagingengine.com","subject":"Re: RFE: support change-id generation natively","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-10-24T13:31:26Z","receivedAt":"2013-10-24T13:31:26Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, Oct 24, 2013 at 7:11 PM, wrote:\n>> That said, I don't think that --change-id option that the user must not\n>> forget to use is any better than a hook that the user must not forget to\n>> install.\n>\n> Having a --change-id option, to my mind, simplifies use of the patch\n> workflow as it does not require downloading, copying and setting\n> executable a hook script per-repository or globally.\n\nThis could be solved by shipping the hook with git. So all you need to\ndo is \"git init --template=gerrit\". --template requires full path, but\nI think we can change it to accept a name and look for $datadir/$name.\nA more interesting case is removing the hook. I admit I haven't found\nany neat way to do it without messing in $GIT_DIR/hooks manually.\n\n> I agree that\n> forgetting to add it on the command-line is a potential problem. This\n> could be improved by honoring the \"gerrit.createchangeid\" value (or\n> whatever setting name is appropriate). Of course that still requires\n> configuring the repo after clone, but it's clean and straight-forward\n> since it is all plain \"git config\".\n>\n> -J\n\n\n\n-- \nDuy\n"},{"id":"229429","messageId":"xmqqzjpymo4y.fsf@gitster.dls.corp.google.com","threadId":"35173","inReplyTo":"5268B7D6.5050106@viscovery.net","subject":"Re: RFE: support change-id generation natively","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-10-24T20:04:29Z","receivedAt":"2013-10-24T20:04:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt writes:\n\n> Am 10/24/2013 7:25, schrieb Duy Nguyen:\n>> On Thu, Oct 24, 2013 at 11:11 AM, Nasser Grainawi wrote:\n>>>>> It is not clear to me how you envision to make it work.\n>>>>\n>>>> I don't have the source code.\n>>>\n>>> Now you do: https://gerrit.googlesource.com/gerrit/+/master/gerrit-server/src/main/resources/com/google/gerrit/server/tools/root/hooks/commit-msg\n>> \n>> Thanks. So you do have tree sha-1 by running \"git write-tree\". But at\n>> that point I'm not sure if cache-tree is written down to disk yet, so\n>> write-tree could be more expensive than necessary (one good point for\n>> building --change-id in).\n>\n> Consider that I make a commit with a change-id. Then I rewrite the commit,\n> but keep the change-id. Then I push the rewritten commit to Gerrit. Gerrit\n> does not have the objects that the change-id is based on; the change-id is\n> just a random number and has no other significance. Right?\n>\n> Why do you go all the length in computing a change-id instead of just\n> pulling 20 bytes from /dev/random?\n\nVery good point.\n\nThe quoted script does not necessarily give the right commit object\nname at least under three scenarios:\n\n - when we would need to add encoding header, etc.;\n\n - when we are recording merges (perhaps merges will not get rebased\n in Gerrit workflow and it does not matter what random garbage\n this script added to them).\n\n - when we record the commit after 1-sec boundary since _gen_ChangeIdInput\n in the script was called.\n\nI wouldn't call the script \"buggy\", but I tend to agree with you\nthat it is an unnecessarily more complex way to spell \"grab 20\nrandom bytes\" ;-)\n\n> That said, I don't think that --change-id option that the user must not\n> forget to use is any better than a hook that the user must not forget to\n> install.\n\nThat is why I said this in my first response to this thread:\n\n>> ... We may even want to\n>> introduce commit.changeId boolean configuration variable if we did\n>> so.\n"},{"id":"229497","messageId":"526A11A8.90200@viscovery.net","threadId":"35173","inReplyTo":"xmqqzjpymo4y.fsf@gitster.dls.corp.google.com","subject":"Re: RFE: support change-id generation natively","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2013-10-25T06:37:28Z","receivedAt":"2013-10-25T06:37:28Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 10/24/2013 22:04, schrieb Junio C Hamano:\n> Johannes Sixt writes:\n>> That said, I don't think that --change-id option that the user must not\n>> forget to use is any better than a hook that the user must not forget to\n>> install.\n> \n> That is why I said this in my first response to this thread:\n> \n>>> ... We may even want to\n>>> introduce commit.changeId boolean configuration variable if we did\n>>> so.\n\nThat's only slightly different and still \"must not forget to set\".\n\nBut I am more concerned that a non-volatile change-id is totally outside\nthe Git data model. After we have git commit --change-id, what will be the\nnext requests for enhancement? 'git merge' and 'git cherry-pick' take a\nchange-id? Where will it end?\n\nWe could ship a git-gerrit-commit wrapper script in contrib that adds the\nchange-id and that people can alias their 'git ci' to globally or on a\nper-repo basis.\n\n-- Hannes\n"}]}