repo: repo sync should force fast-forward merge

[GoogleCodeExporter]

Hi,

After updating a manifest project revision, switching from a previous tag 
(v1.12.1) to a newer tag (v1.12.2) on the same branch, repo sync makes git 
merge (by recursive method) the newer tag into the local repository. In this 
case, git want to create a merge commit and spawn an editor to create a merge 
commit message.

As the previous and newer tag are on the same branch, sharing the same history, 
a merge commit is not needed if one wants its local history to match the remote 
history.

The merge commit is created by git when merging a tag signed or annotated: this 
is the new default git behavor.

Most of the time, when following an upstream project, such merge commit are not 
welcomed: that's why repo sync use "git rebase" for local branch with patches 
on top of it.

But when there's no patches on the local branch, "repo sync" seems to use git 
merge, but as said earlier, git merge will create a merge commit when the tag 
is signed/annotated.

repo sync should be fixed to force a fast-forward merge by default and failed 
if the fast-forward merge cannot be done. Options could be added to either
 - reset the local branch (if the remote branch was wrongly rebased)
 - allow the creation the merge commit (but this is going to create a different history).

(This was wrongly reported as 
http://code.google.com/p/gerrit/issues/detail?id=1824 )

Original issue reported on code.google.com by yann@droneaud.fr on 12 Mar 2013 at 4:59

[GoogleCodeExporter]

Please find a log that describe how to reproduce the problem. I'm using 
git-repo to demonstrate the behavor of git merge.

repo should not use "git merge" to update a local branch if "git rebase" / "git 
merge --ff-only" works. "git merge" should only be used if the latter failed.

Original comment by yann@droneaud.fr on 13 Mar 2013 at 11:26

Attachments:

• git-repo-merge.log