Request for D core devs: git pull --rebase

Martin Nowak dawg at dawgfoto.de
Sun Nov 6 15:50:28 PST 2011


On Sun, 06 Nov 2011 22:28:58 +0100, Jonathan M Davis <jmdavisProg at gmx.com>  
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


More information about the Digitalmars-d mailing list