30

I setup some git hooks to run some gulp commands on pre-commit. I basically run jshint/plato. I basically want to bypass these for two cases:

  1. hotfix branches (master / hotfix)
  2. git merge (or find a way to do it in a way that doesn't crash on the merge commit case)

The plato gulp command runs analysis on the source and produces a /reports/ directory that tracks complexity over time. If we do this on the hotfix branch it will result in merge conflicts when merging them back into development. Enough talking here is the simple hook:

#!/bin/sh

if git diff --cached --name-only --diff-filter=ACM | grep '.js$' >/dev/null 2>&1
then
  git stash -q --keep-index
  ./node_modules/.bin/gulp jshint
  RESULT=$?
  git stash pop -q
  [ $RESULT -ne 0 ] && exit 1
  git stash -q --keep-index
  ./node_modules/.bin/gulp plato
  git add report/
  git stash pop -q
fi

exit 0

Issue right now is if i have a merge conflict on "reports" and I resolve the merge All conflicts fixed but you are still merging. and then commit it runs the analysis again and stages the commit and when it commits it throws an error:

/Users/Nix/work/project/.git/modules/somesubmodule/MERGE_HEAD' for reading: No such file or directory.

The directory does exist but there is no merge head...

Nix
  • 57,072
  • 29
  • 149
  • 198

2 Answers2

39

So I just found a command that I think i can use to detect the "merge_head"

 git rev-parse -q --verify MERGE_HEAD

If rev-parse returns a hash that means we are currently in a merge state. I can use that to bypass this logic. But will wait for some better advice from more experienced individuals.

Nix
  • 57,072
  • 29
  • 149
  • 198
  • Works for me. Thanks! – EM0 Feb 06 '18 at 09:07
  • 2
    If you are rebasing, you can do about the same with the following: `git rev-parse -q --verify REBASE_HEAD` – Daan Jan 07 '20 at 10:57
  • Sorry for the newbie question, but how could we have the exact opposite effect? i.e, if we want to error out in case we're in a merge state. – Flavio Wuensche Apr 15 '20 at 17:10
  • @FlavioWuensche For skipping on merge: `(git rev-parse -q --verify MERGE_HEAD) || (skip_this_if_merging)`. For running on merge: `(git rev-parse -q --verify MERGE_HEAD) && (only_run_this_if_merging)` – unforgiven1987 Dec 01 '20 at 06:41
  • Strange, but `git rev-parse -q --verify REBASE_HEAD` evaluates to `true` event after rebase was finished. I tried `(git rev-parse -q --verify MERGE_HEAD || git rev-parse -q --verify REBASE_HEAD) || (skip_this_if_merging_or_rebasing)` – Harry Burns Mar 17 '21 at 01:29
4

As mentioned in this related answer you could test for the existence of $GIT_DIR/MERGE_HEAD to detect a merge commit:

Here's what you do get:

  • If you're using git commit --amend to amend a merge commit, the pre-commit hook is run as usual, but it can't really detect that this is happening. The new commit will be a merge, but you can't tell.

  • If you're using regular old git commit to create a non-merge commit, the file MERGE_HEAD will not exist in the git directory, and you can tell that this is not going to create a merge commit.

  • If you're using git commit to finish off a conflicted merge, the file MERGE_HEAD will exist, and you can tell that this is going to create a merge commit.

  • If you're running git merge and it succeeds on its own, it makes a new commit without using the pre-commit hook, so you don't even get invoked here.

Hence, if you're willing to allow git commit --amend on merges to misfire, you can get close to what you want: just test for the existence of $GIT_DIR/MERGE_HEAD to see if this is a git commit that is finishing off a conflicted merge. (The use of $GIT_DIR is a trick to make this work even if the commands are run outside the git tree. Git sets $GIT_DIR so that in-hook git commands will work right.)

Andreas Fester
  • 36,091
  • 7
  • 95
  • 123
sigy
  • 2,408
  • 1
  • 24
  • 55