On Wed, Oct 27, 2010 at 1:50 PM, <Euguess@xxxxxxxxx> wrote: > On Oct 27, 2010 1:36pm, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: >> Eugene Sajine wrote: >> >> >> >> > Thanks for prompt answer. But let me clarify: >> >> > >> >> > When you do pull git performs: >> >> > >> >> > fetch of the remote branch to the FETCH_HEAD >> >> > and then merge of FETCH_HEAD into the local branch >> >> > >> >> > What I'm saying is that your local branch should be rebased on top of >> >> > FETCH_HEAD instead >> >> > >> >> > In this case there is no such thing as "often rebased public branch". >> >> >> >> Ah, but there is. >> >> >> >> Imagine you are Junio and just received a pull request from Pat. >> >> Then you might try: >> >> >> >> Â$ git pull pat for-junio >> >> >> >> which will do all the fetching and merging magic that "git pull" >> >> is known for. ÂNow if pat's for-junio branch is based on the tip >> >> of your current branch, this will be a fast-forward and it doesn't >> >> matter whether you merge or rebase. ÂBut what if there are some >> >> intervening commits? >> >> >> >> Â$ git pull eric for-junio >> >> Â$ git pull pat for-junio >> >> >> >> If this pull were the rebasing kind, the result would be for Eric's >> >> commits to be rewritten based on Pat's. >> > > Oh, I see. In this case you're right. > My scenario is probably making more sense for the "centralized approach", > where the exchange goes via some blessed bare repo on the server. > So, I just have to run git pull --rebase to get my scenario working, right? > > > Thanks! > Eugene Actually it seems that it will not work as i would expect... git pull --rebase is going to rebase the upstream on top of my local branch, right? Is this really intended behavior? Shouldn't it rebase my local on top of the upstream instead? Thanks, Eugene -- 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