Re: [PATCH v2] Teach 'git pull' about --rebase

From: Steven Grimm <koreth@midwinter.com>
Date: Nov 28, 2007, 22:06 UTC
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:

Show 5 quoted lines

> 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