Steve Hoelzer wrote:
> Why isn't there a pull command in git gui's remote menu? Am I supposed
> to fetch and then merge? Is that preferred over pull for some reason?
Yes, it is. Blind "git pull" without knowing what you're going to
fetch is not recommended, because it tends to create tons and tons
of "useless" merges, where all commits are on one branch and there's
no clear distinction between them. Such merges are useless because
you'd be better off with a linearized history (bisection turns out
slightly easier, fe).
"git pull" is primarily intended for
* people like Linus, who merge in a lot of other people's code.
* bleeding-edge *users* that just want the latest and greatest.
* "vcs = cvs" users, that never care about history
For all other workflows I've ever encountered, doing "git pull"
blindly always ends up being worse than
* developing on topic-branches and merging those when ready.
* doing 'git pull --rebase', to linearize a series of small
fixes before pushing them back up.
* 'git fetch' + manually inspect new code + 'git merge'.
Steve Hoelzer <[hidden email]> wrote:
> Why isn't there a pull command in git gui's remote menu?
I got lazy and didn't write support for it. Before today nobody has
really asked me why it was missing so it seemed to be unimportant.
> Am I supposed to fetch and then merge?
Yes, that works.
> Is that preferred over pull for some reason?
I find it easier to teach new Git users "fetch + merge" rather
than pull. It helps to reinforce the idea of having your own
local state that differs from the state on the upstream repository.
I consider pull to be more of a power-user feature. But many in the
Git community disagree with me and find teaching pull is easier, with
fetch+merge being power user features.
So patches to add pull to git-gui would be accepted, but they won't
be getting written by me anytime soon. I've got too much other
stuff going on to write a feature that isn't very interesting to me.