When playing with moving (cherry picking) commits from master to one of the release branches (REL1_19) I noticed that "git cherry-pick" and "git merge" do not invoke "commit-msg" hook and therefore don't add Change-Id to the commits. This is normally not a problem for people who are allowed changes without "Change-Id" to the repository (i.e. trunk gatekeepers), but this may add some problems for committers at large. 1) you can't push result of such merge or cherry-pick for review 2) you can't directly cherry-pick a commit imported from SVN into git master (those have no change-ID's) to one of the branches. 3) merge commits done by gatekeepers are not visible to gerrit (you can't find them for example when searching by ID). Therefore we loose ability to comment on them if necessary. Here is an example how it failed on me today: https://www.mediawiki.org/w/index.php?title=Git/Workflow&diff=prev&… Sometimes a "git commit -c <original commit>" or "git commit --amend" are able to fix the issue, because "git commit" DOES invoke the hook. This will be especially important for developers wanting to propose their changes into release branches or deployment branches. This may also bite you if you are using some private branches, all commits there have Commit-IDs but merges will not have and you may have hard time push it all together for review. It is also interesting to see how Change-IDs represent multiple review items (I52150208654fa14e02b6d80fb2cff4108089ef6c is https://gerrit.wikimedia.org/r/3713 and https://gerrit.wikimedia.org/r/3714). I think the right workaround right now is to make sure all commits (even merges or things going directly into git master for some reason) have their gerrit "Change-ID". With cherry pick it can be done by doing it in two stages: git cherry-pick -n <revision> git commit -c <revision> (but you might want to improve the commit message). Something similar can be done for merges probably (there is --no-commit option to git merge). There are probably some other git commands causing automatic commit that may have this problem. Fast forwards are fine, as they don't produce commits. I did some of the testing today: https://gerrit.wikimedia.org/r/#q,project:test/mediawiki/core+owner:saper%2… //Saper