I am writing a script that requires checking whether a particular commit is a Merge/Revert commit or not, and I am wondering if there is a git trick for that.
What I came up with so far (and I definitely don't want to depend on the commit message here) is to check HASH^2 and see if I don't get an error, is there a better way?
Figuring out if something is a merge is easy. That's all commits with more than one parent. To check for that, you can do, for example
$ git cat-file -p $commit_id
If there's more than one `parent' line in the output, you found a merge.
For reverts it's not as easy. Generally reverts are just normal commits that happen to apply the diff of a previous commit in reverse, effectively removing the changes that commit introduced. They're not special otherwise.
If a revert was created with git revert $commit, then git usually generates a commit message indication the revert and what commit it reverted. However, it's quite possible to do reverts in other ways, or to just change the commit message of a commit generated by git revert.
Looking for those generated revert commit message might already be a good enough heuristic for what you're trying to achieve. If not, you'd have to actually look through other commits, comparing their diffs against each other, checking if one is the exact reverse operation of another. But even that isn't a good solution. Often enough reverts are slightly different than just the reverse of the commit they're reverting, for example to accommodate for code changes that happened between the commit and the revert.
The following instruction will dump out only the parent hashes. Less filtering needed...
git show --no-patch --format="%P" <commit hash>
The answer using git cat-file is using a git "plumbing" command, which is generally better for building scripts as the output format is not likely to change. The ones using git show and git rev-parse may need to change over time as they are using porcelain commands.
The bash function I've been using for a long time uses git rev-list:
gitismerge () {
local sha="$1"
msha=$(git rev-list -1 --merges ${sha}~1..${sha})
[ -z "$msha" ] && return 1
return 0
}
The list of porcelain/plumbing commands can be found in the docs for the top level git command.
This code uses git-rev-list with a specific gitrevisions query ${sha}~1..${sha} in a way that prints a SHA's second parent if it exists, or nothing if it is not present, which is the exact definition of a merge commit.
Specifically, SHA~1..SHA means include commits that are reachable from SHA but exclude those that are reachable SHA~1, which is the first parent of SHA.
The results are stored in $msha and tested for emptiness using bash [ -z "$msha" ] failing (returning 1) if empty, or passing (returning 0) if non-empty.
[ -z foo ] actually do? I want to know this because I'm interested in using this but not in a bash script... also, what are the downsides&upsides of your solution compared to the cat-file one? cheers –
Compress is_merge () { return $(( ! `git rev-list --no-walk --count --merges "$@"`)) } –
Sommerville is_only_child() { return $(git rev-list --no-walk --count --merges "$@"); }... –
Landeros git version 2.24.3 (Apple Git-128) –
Cosher )) for it to compile in a bash script.) Please consider posting as an answer. –
Caridadcarie rev-list --no-walk --count --merges, but I don't have a mac anymore (working from Windows/WSL now), so I can't test. –
Cosher I'm finding all answer over complicated and some even not reliable.
Especially if you want to do different actions for merge and regular commit.
IMO best solutions is to call git rev-parse using second parent expression ^2 and then check for an errors:
git rev-parse HEAD^2 >/dev/null 2>/dev/null && echo "is merge" || echo "regular commit"
This works perfectly for me. Most of example above is just a decoration which just discards unwanted output.
And for windows cmd this works nicely too:
git rev-parse "HEAD^2" >nul 2>nul && echo is merge || echo regular commit
note quote characters
One way to test for a merge commit:
$ test -z $(git rev-parse --verify $commit^2 2> /dev/null) || echo MERGE COMMIT
As for git revert commits, I agree with @rafl that the most realistic approach is to look for the revert message boilerplate in the commit message; if someone changed it, detecting so would be very involved.
test -z do exactly? the question doesn't ask for bashisms... –
Compress Yet another way to find a commit's parents:
git show -s --pretty=%p <commit>
Use %P for full hash. This prints how many parents HEAD has:
git show -s --pretty=%p HEAD | wc -w
The accepted answer works well for manual inspection of the result, but has a fatal flaw for scripting: the commit message itself could contain a line starting with "parent", and you might accidentally catch that, instead of the meta data at the top of the output.
A more reliable alternative is:
git show --summary <commit>
And check if a line starts with Merge:. This is similar to git cat-file, but it will prefix the commit message with spaces, so you can grep for it safely in a script:
git show --summary HEAD | grep -q ^Merge:
This will return 0 for merge commits, 1 for non-merge commits. Replace HEAD by your desired commit to test.
Example usage:
if git show --summary some-branch | grep -q ^Merge: ; then
echo "some-branch is a merge"
fi
This works because the commit message itself is prefixed by 4 spaces, so even if it contained a line starting with "Merge:", it would look like Merge:.., and the regex would not catch it. Note the ^ at the start of the regex, which matches the start of the line.
git cat-file grep? can you elaborate? –
Compress If the output of the following command is 1, that will indicate it is an individual commit. If not, it is a merge commit
git cat-file -p $commitID | grep -o -i parent | wc -l
To check whether it's a merge commit,
# Use the FULL commit hash because -q checks if the entire line is matched.
git rev-list --merges --all | grep -qx <FULL_commit_hash>
echo $? # 0 if it's a merge commit and non-zero otherwise
To check whether it's a revert commit, you'll have to go through the other answers.
© 2022 - 2024 — McMap. All rights reserved.