| Issue 1824: | repo: repo sync should force fast-forward merge | |
| 1 person starred this issue and may be notified of changes. | Back to list |
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).
Mar 12, 2013
Project Member
#1
bklarson@gmail.com
Status:
Invalid
|
|
| ► Sign in to add a comment |