We have a large repository with several submodules. Every now an then a submodule is accidentally rewinded when commiting a merge. (Sometime it happend when using TortoiseGIT and the submodule got checked. We also have a case where is happend using VS-Code.)

Is there a git command to find the commit which contains the rewind.

CodePudding user response：

As a first cut that should get the candidates down into easy eyeball territory, you're looking for commits where changed submodule entries aren't descended from what they were before.

Checking this conveniently is hardcore, but not hard.

find $PWD -type d -name objects -execdir test -f HEAD -a -d refs \; -print \
| sed \\,$PWD/.git/objects,d >.git/objects/info/alternates

git log -m --raw --no-abbrev --pretty=format:%H \
| awk ' NF==1 { commit=$1 }
        $1$2==":160000160000" {
                print "[[ `git merge-base "$3" "$4"` != "$3" ]] && echo "commit
        }
' | bash

The first set tells Git other places to find the objects it's about to be interested in, by finding all the submodule repos you've cloned for this repo (probably via git submodule update --init --recursive or some such helper). If you already have an objects/info/alternates file, which y8ou will if you're using reference clones, you probably want save your current alternates file and replace > with >> above.

The second set: the log does a quick what-changed scan through history, the awk looks for submodules that were changed but not added or deleted and prints shell commands to check whether the new version is a proper descendant of the old and print the commit id if not; piping those commands through the shell actually executes them.

Running this in my sed history produces 51 submodule updates, none of which fail the test: they're all just fast-forwarding to a newer submodule version.