Martin Fick <mfick@xxxxxxxxxxxxxx> writes: > As a Gerrit maintainer, I would suspect that we would > welcome a way to track "changes" natively in git. I would suspect that we would not mind "git commit --change-id" (and probably "git commit-tree --change-id") option that can be used to tell the command to add a new Change-Id: trailer at the end, if and only if there is none in the log message to be recorded (this needs to happen after the user possibly edits). We may even want to introduce commit.changeId boolean configuration variable if we did so. "git commit --amend", "git rebase", etc. can be left oblivious to the "Change-Id:" trailer, as the default mode of operation you guys want is to leave the existing one as-is, unless the end user really wants to change it, I think. 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 would think. You might have a funny chicken-and-egg problem with the signed commit, though. I didn't think that part through. -- 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