2

I have master branch and other branches from my team members. master is sync with the product. I want to have another additional commit that upgrading version (change a file content say 'release.md') when an MR is merged into master from other branches, no matter what changes have been made.

This is for a gitlab v11.10.4, running on ubuntu 16.04 system. At the beginning, I want to set a git hook (update hook) on gitlab server-side. In the script, I need to do: 1) check if target merge branch is master 2) if it does, check the commit's message is not like "upgrading version" 3) if not then add an additional commit before merge. 

touch release.md
git commit -a -m "upgrade version"

I know that in an update hook I could get args which are "refname", "oldrev" and "newrev", theoretically I could parse info from this to finish step 1) and step 2). but I have no idea how to add additional commit to this branch.

It is easy to have it in local hook (git add . blahblah), but in that way every developer in my team gonna need to maintain a hook file in .git of any repo. Which is error prune. Any idea and suggestions?

milanow
  • 159
  • 1
  • 13

2 Answers2

1

An update hook cannot add new commits.1 The function of an update hook is to either accept or reject a name-change.2 To accept the name-change, exit zero. To reject the name-change, exit nonzero.

What you should do for this case is verify that the user making a change to refs/heads/master is making a correct change. If not, reject the change-request. The user doing the git push must make the correct annotation. You simply verify that the annotation exists and is correct. If it does not, produce an error message: this error will be displayed to the user running git push, prefixed by the word remote:.

In other words, if you do:

echo "ERROR"
echo "ERROR: you must supply a commit with a correct message"
echo "ERROR: ... describe enough to tell the user what that is ..."
echo "ERROR"
exit 1

the user will see the ERROR messages prefixed by remote:, as in:

remote: ERROR
remote: ERROR: you must supply a commit with a correct message
remote: ...

1Technically, it is possible to do sneaky things in Git hooks. However, branch name changes require locking. The lock is already in place for the proposed update at this point, so the update hook can't add new commits to the proposed-update branch name, as that requires locking the lock that's already locked, which means waiting for the user that has the lock, which is yourself, to finish verifying the operation. This is a classic deadlock. You could in theory update some other branch, since you are then not waiting for yourself. But it's a bad idea in general.

2The "change" is one of: create a reference (e.g., new branch), delete a reference (e.g., delete a branch), or update in place (e.g., add new commits to a branch, or remove commits from a branch due to a force-push operation). You tell which kind of change by inspecting the old and new hash IDs, and using git rev-list if/as needed.

torek
  • 448,244
  • 59
  • 642
  • 775
  • Thanks for your detailed explanation and general usage about update hook. I thought I could do some sneaky things in on server side because I have all the objects stored on the server. But you are right this is not actually how hook should be used. – milanow Jul 20 '19 at 02:01
0

If you don't want to enforce that policy on the developer side, and still insists on adding that "upgrading version" metadata ("meta" as "it is not a "data", which is "source code"), then you might consider git notes.

git notes adds, removes, or reads notes attached to objects, without touching the objects themselves.

That means your update, or even post-receive hook can check:

  • the new commit was done on master
  • the new commit was a merge commit (two parent)

In that case, it can add a note to that commit, specifying it is an "upgrade version" kind. Without having to mess with the history of commits.

Taylor D. Edmiston
  • 12,088
  • 6
  • 56
  • 76
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • I am not sure if this could solve my issue. Back to the usage point, the major benefit to have like "Upgrade Version to XXX" commit is that if my product had bugs need to be fixed (tests passed but potential issues not detected). I could roll back to specific version by checking my commit message. Because my commit history could be like "abacadaeaf......" where 'a' represents my upgrade-commit. Another benefit is that developer could get the "correct version" to develop – milanow Jul 20 '19 at 04:13
  • @milanow Yes, of course you can rollback to the right commit with git notes: your note will include the commit SHA1 (as seen in https://stackoverflow.com/a/52204890/6309). Both of your usage points are addressed. Using notes. – VonC Jul 20 '19 at 04:46