Am 3/8/2012 8:14, schrieb Jeff King: > What if the user could specify a partial ordering of refs, and we used > that order when listing merge parents in the resulting commit. So for > example, if you said that: > > refs/remotes/origin/master > refs/heads/master > > then doing: > > $ git checkout master > $ git pull origin master > > would result in a "flipped" merge commit, with origin/master as the > first parent, and master as the second. I have wished for such a thing several times already. It happens when I have a topic with changes that trigger a complete rebuild of the project. When I merge it to master, I have to # on topic git checkout master #1 git merge topic #2 #1 triggers a rebuild, but I don't do a build. Then #2 again triggers a rebuild, but in reality the only changes since the last build are those from master since the topic forked (no, I can't use ccache). To avoid the situation, I jump through hoops by preparing an index and worktree with the merge result while I am on topic: # on topic git checkout --detach git merge master # triggers rebuild of only master's changes # merge result ready; carry it over to master and repeat the merge git reset --soft master git checkout master git merge topic # fails if content merge is necessary git checkout master -- file/needing/content/merge # (*) git merge topic # now succeeds This would not be necessary if the order of the merge parents could be specified, e.g.: # on topic git merge --into master (*) Jumping through these hoops make sense only if file/needing/content/merge is _not_ the one that triggers the complete rebuild. -- Hannes -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html