Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: ignore merge commits to target branch at tip of history #35

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

chore: ignore merge commits to target branch at tip of history #35

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 15 additions & 2 deletions git-branch-linearity.sh
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,13 +6,26 @@ TARGET_BRANCH="${1:-main}"
echo "Target branch: $TARGET_BRANCH"
git fetch origin $TARGET_BRANCH 2> /dev/null

out=$(git log origin/${TARGET_BRANCH}..HEAD --merges --oneline)

# Detection of (PR) merge commits at tip of HEAD:
target_sha=$(git rev-parse origin/${TARGET_BRANCH})
# Get SHA of parent commit
merge_target=$(git log --merges --oneline --parents --no-abbrev-commit HEAD^..HEAD | cut -d" " -f2)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand that if the last commit is a merge commit and has the head of the target branch as the left child, you will ignore it (consider it's the GitHub generated one) and check for merge commit in the below commits.

It's not clear to me if this approach works if someone did the same thing in his/her branch that GitHub CI does, i.e. he/she merged the main branch into its development branch, which we also wouldn't want in case of linearity check.

I tried locally and the check worked, but it was because the origin/main commit was the right child of the merge commit and not the left child.

Are you sure testing always the left child will achieve the expected results?
Unfortunately, I was not able to test it in a real PR, I had some difficulties reproducing the issue.

BTW I thought initially to use something more GitHub specific, using for instance the environment variable exported.
The GITHUB_SHA contains the tip commit (which will be the merge commit if one was created)
and GITHUB_HEAD_REF contains the source branch name (and is only defined in PR context)

If the 2 don't point to the same thing, we are probably in a GitHub merge commit situation.
Or simpler, if GITHUB_HEAD_REF is non-empty, we do git rev-parse ${GITHUB_HEAD_REF} to get the tip commit to use.

BTW I found this page informative about the process: https://www.kenmuse.com/blog/the-many-shas-of-a-github-pull-request/

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok I think it will work because locally the left child is the target of the merge (ours) and the right side what is merged into the target (theirs).
A local merge commit will merge main into the current branch, so it will end up on the right.
Whereas GitHub create a new branch from the base commit and merge the pull request branch into it so the origin/main commit will be on the left.

I still think using GITHUB_HEAD_REF would be simpler but as you want :-)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Took me a while (and needed some calm time) to wholly follow through your points.
I have to say, I did not think at all about any GH-specific variables, only about the git history itself. But what you suggested makes a lot of sense.

So the case you were concerned about is if we have a merge commit from main into the dev branch (what we don't want to allow) at the tip of the history.
But this is detected correctly because it has the left and right parent commits inversed.

In any case, yes, I think using the GITHUB_HEAD_REF is a good idea here. And ignoring it if it's empty.
We could even compare SHAs of rev-parse $GITHUB_HEAD_REF and HEAD^ and if they match assume we are in a GH merge commit scenario and start the history check from that SHA?

# If parent is the target branch, start from the commit before the merge commit
if [ "$target_sha" = "$merge_target" ] ; then
tip="HEAD^"
else
tip="HEAD"
fi

out=$(git log origin/${TARGET_BRANCH}..${tip} --merges --oneline)
exit_status=$?
if [ -n "$out" ]
then
echo "Please rebase your branch" >&2
echo "If your branch or its base branch is a release branch then ignore this error" >&2
echo "\nMerge commit(s):" >&2
echo >&2
echo "Merge commit(s):" >&2
echo "$out" >&2
# Disclaimer: current version of the check doesn't work well with release branches
exit_status=1
Expand Down