How to avoid auto-merge message when sending Pull Request

Question

In order to keep my fix branch updated with upstream master branch, I wrote a contab to auto-merge upstream commits during the process of fixing on my own branh. But now, when I want to send PR to the upstream repo, I found the diff page shows like this:

[commit1] myfix1
[commit2] myfix2
[commit3] auto-merge
[commit4] auto-merge
[commit5] auto-merge

....

There're plenty of "auto-merge" messages in my PR now! It's very ugly....

What can I do to avoid these kind of stuff before I send PR?

Answer 1

I'm not sure your auto-merge commits are really that ugly or if they really matter.

When I merge PR on GitHub I don't look at the individual commits. I look at the final diff. I often ask the developer to roll back some of his changes, and add some new. After he's done with fixes and pushes again, I look at the final diff again and the rolled back changes will be gone as if never happened, as far as I'm concerned.

Reading commit by commit is not practical when merging a PR. It's really best to look at the total changes. If I want to look at the details of a specific commit, I can guess that the commits with "auto-merge" in the comment are not doing anything interesting, I wouldn't look at those.

But if you really want to avoid these commits in the future, then do not auto-merge, but use rebasing instead. In the end, this is only a cosmetic issue, not a real problem.

Answer 2

If you are trying to rebase instead of merge then you have 2 options

assuming branch master, and remote origin

• Fetch then rebase

  git fetch origin master
  git rebase origin/master
  

• Pull with flag rebase

  git pull origin master --rebase
  

  This way git will prefer rebasing instead of merging

Even though I'm one of the people who prefer using merge over rebase, I wouldn't really advise using rebase if you find any conflicts, especially if your local tree is more than one or two commits, you'll find your self resolving the same conflict once for each local commit you have.

Note: In case things go south, you can always abort

git rebase --abort

This will return your local branch to it's original form.

I still don't understand why you really need that cron job, you only need to rebase once before pushing, at least that's what I do.

Answer 3

git rebase is the command which fits to your situation :

Your situation is somewhat like

you are working on the branch feature as in my example and some one has performed two more commits on master so currently you are not in sync with master so you have to perform Git rebase after your Git pull or Git fetch

so it looks somewhat like

and then you can push your changes to origin.