From: Steven Grimm <koreth@midwinter.com>
Date: Wed, 28 Nov 2007 22:06:44 GMT
Subject: Re: [PATCH v2] Teach 'git pull' about --rebase
Message-ID: <37EFF273-D8E1-4042-966B-743CE9D753AA@midwinter.com>
In-Reply-To: <Pine.LNX.4.64.0711282156520.27959@racer.site>

On Nov 28, 2007, at 1:58 PM, Johannes Schindelin wrote:
> Besides, the operation "pull" is about getting remote changes  
> incorporated
> in your current branch.  IMHO "pull = fetch + merge" is only a  
> technical
> detail, and we should not be bound by it too much.

Yeah, I agree. I almost never use "pull" as is because I almost always  
want to rebase. That is, it's basically clutter for me as a command  
right now, and it would remain so even if a separate fetch+rebase  
command were added.

I think this may be a difference in perspective based on how one uses  
git. If I were an integrator I would probably use "pull" as is a lot  
more because I would want the merges represented explicitly in my  
history. But most of the time I'm working as a leaf node in the tree  
of repositories, interacting only with a central integration repo, and  
I basically never want a give-me-the-remote-changes operation (which  
is really more of a "sync me up with the latest changes from the rest  
of the team" operation) to put a merge in my history.

What's more, when I'm introducing git to new people in my environment,  
right now I tell them about fetch and rebase and pretty much have to  
tell them to avoid running "pull" until they're comfortable with git,  
since I know their histories would be full of meaningless merges  
otherwise. It'd be nice to have new people run one less command as  
part of their normal day-to-day work.

-Steve