Empty PRs being created, is this expected?

[dsyme]

I'm getting situations where empty PRs are being created - that is there's a merge commit being added, but the diffs are empty.

Reading the docs it feels like these PRs shouldn't be created, I'm wondering if there's something I'm doing wrong.

[dsyme]

The action is nothing surprising, but actually looking at it now perhaps I should be using git pull rather than git merge

name: Auto-prepare a PR from update to main
on:
  push:
    branches:
      - update

jobs:
  create-pr:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
        with:
          ref: main
          fetch-depth: 0
      - name: Merge update branch into main
        run: |
          git fetch origin update
          git merge origin/update
      - name: Create Pull Request
        uses: peter-evans/create-pull-request@v5
        with:
          branch: integrate/update-to-main
          title: "Merge update into main"
          body: "This is an automated pull request to update the main branch with the latest changes from update."
          delete-branch: true

[peter-evans]

Hi @dsyme

Please take a look at this example. I think this is what you are trying to do.
https://github.com/peter-evans/create-pull-request/blob/main/docs/examples.md#keep-a-branch-up-to-date-with-another

I don't think using merge is going to work.

[dsyme]

Thanks! My scenario is a little different - we have two branches production and main but allow changes to flow into both (e.g. hotfixes into production and normal dev work into main). I'm using this action to automate the PRs for the integrations between the two.

The problem is that merge commits always appear - and this really stems from the fact that the GitHub UI doesn't support PRs that are fast-forward merges, so the act of merging a PR always leaves a merge commit, squash or rebase of some kind in the commit history. This means that you end up with an endless infinite ping pong of empty merge commits between the two branches.

I found a workaround which is like this. But I do wonder if this could be the default behaviour.

Thank you for the GH action btw, it's very useful!

jobs:
  create-pr:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
        with:
          ref: production
          fetch-depth: 0
      - name: Promote main to production
        run: |
          git config --global pull.ff only
          git config --global user.email "..."
          git config --global user.name "..."
          git fetch origin
          # Check if there are any actual code differences between the two branches. If so, merge 
          # the main branch into production. If not, do nothing, which will not result in creation of a PR.
          # This prevents PRs being created when there are no actual code changes only merge commits
          if git diff --quiet origin/production...origin/main; then
            echo "production branch already includes everything from main branch"
          else
            git merge origin/main
          fi
      - name: Create Pull Request
        uses: peter-evans/create-pull-request@v5
        with:
          branch: integrate/main-to-production
          title: "[Release] Promote main to production"
          delete-branch: true

[peter-evans]

Maybe to avoid the merge commits you could try this in your workflow:

1. checkout production
2. fetch main (origin)
3. create a new local branch on the HEAD of production called temp-merge, for example
4. merge origin/main into temp-merge
5. checkout production again (this part is like the example I linked, but we don't need to fetch because temp-merge is already available locally)
6. do git reset --hard temp-merge
7. run create-pull-request

Apologies if I misunderstood and this doesn't work. 😄