Automatic Gerrit rebase from refs/for/master may cause more than 1 history entry in master

Question

When doing operation rebase on Gerrit I saw that it is possible to create more than 1 history item on master when moving from refs/for/master.

1. Commits will have the same change ID

2. Commits will have different SHA-1

3. The first commit is OK, the next one is empty (no files are attached)

Such extra commits are spoiling master history. What may be the reason of such behaviour?

Answer 1

I found yet another and more elegant solution (in my opinion) to eliminate empty commit messages.

In Gerrit project options you may set the following options to avoid empty workitems if git is able to do merge with rebase automatically (there are no conflicts which need human intervention):

• Projects -> General -> Submit Type -> Rebase if Necessary
• Projects -> General -> Automatically resolve conflicts -> TRUE

In fact, with such strategy, gerrit will inform that automatic merge is not possible and will do nothing. On the other hand, if rebase+automatic merge is successful, there will be just one for/master->master workitem.

Answer 2

Sounds like a merge commit. In that case the commit message is often copied from the last commit

Answer 3

You have to be more specific, but,

When doing operation rebase ... first commit is OK, the next one is empty ... Such extra commits are spoiling master history. What may be the reason of such behaviour?

Git history is non-linear, and when you rebase, git (gerrit) may have to merge changes from the two development histories, which may themselves include merge commits - those may look empty to you. However it is also possible that you've been affected by this issue - please check if that's your use case.

Commits will have different SHA-1

This is generally expected with rebase. Please read 3.6 Git Branching - Rebasing.