On 2014-05-04 17:13, Felipe Contreras wrote: > Richard Hansen wrote: >> On 2014-05-04 06:17, Felipe Contreras wrote: >>> Richard Hansen wrote: >>>> On 2014-05-03 23:08, Felipe Contreras wrote: >>>>> It is the only solution that has been proposed. >>>> >>>> It's not the only proposal -- I proposed a few alternatives in my >>>> earlier email (though not in the form of code), and others have too. In >>>> particular: >>>> >>>> * create a new 'git integrate' command/alias that behaves like 'git >>>> pull --no-ff' >>> >>> Yeah but that's for a different issue altogheter. I doesn't solve the >>> problems in 1. nor 2. nor 3. >> >> 'git integrate' would handle usage cases #2 (update a published branch >> to its "parent" branch) and #3 (integrate a completed task into the main >> line of development), > > But these cases are completely different. One should reverse the > parents, the other one not.
No -- for both #2 and #3 I want the remote branch to be merged into the local branch. In the example I gave for use case #2, foo is a local branch with origin/foo as the configured upstream and origin/foo was forked off of origin/master. Someone pushed new stuff to origin/master, and the user wants the new stuff to also be in origin/foo. So the user does this: git checkout foo git pull --ff-only # this is use case #1 git pull origin master # this is use case #2 git push The merge commit created by 'git pull origin master' should have origin/master as the second parent, not the first. -Richard -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
