On Sun, 06 Nov 2011 22:28:58 +0100, Jonathan M Davis <[email protected]>
wrote:
On Sunday, November 06, 2011 20:40:12 Alex Rønne Petersen wrote:
I should clarify that this entire post was directed at *normal git pull
operations*. Not merging of pull requests. Those will (and should!)
result in a merge commit to make it easier to see when in history a pull
request was merged in.
Then I'm totally confused. When you pull from master to your own
repository,
you _don't_ want to use rebase, because then you can't push it back or
merge
it back in. And if you're merging into master, then it's almost always a
pull
request. Unless you're talking about the master in your own repository
rather
than the main one? Except that that doesn't make sense either, because
for
most people, pull requests come from their branches, and master
generally
matches what's in the main repository's master (if it doesn't, it's
probably
because they're doing pull requests from master).
So, I have no idea what you were trying to get across with your original
post
if you weren't talking about pull requests.
- Jonathan M Davis
I guess he's referring to the fact that updating a local branch with local
commits
through 'git pull' will merge in the remote branch while 'git pull
--rebase'
keeps your local commits on top of the updated remote branch.
I've never seen anything of this in the dmd repo.
Usually the merged branches are very short living.
OTOH for maintaining long living pull requests it might actually be
cleaner to merge,
so that possible merge errors can be found back in the history.
martin
