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
-
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
