default behaviour for `gitmerge` (no arguments)

Hi there, long time user; first time caller here.

I wanted to suggest an improvement to git-merge which will either save some typing or save some network resources. It won't save huge amounts of either but every little helps!

Currently, some of my colleagues frequently end up typing:

    git pull; ...; git checkout otherbranch; git pull

Now, we have quite a low commit rate, it's unlikely (albeit vaguely possible) that two people are working on the branch at the same time. This means the second pull is doing a fetch which it effectively pointless.

Now of course this is a tiny amount of wastage, and while I could argue that it would be an issue under poor network conditions that's not my point. As a coder I'd want to get rid of the redundant fetch if I know it's redundant.

Unfortunately my other option is:

    git pull; ...; git checkout otherbranch; git merge myremote/otherbranch

which is annoying extra typing. Even with tab completion, it's redundant extra typing because in these cases I'm trying to merge with the branch being tracked.

My suggestion is that `git merge` defaults to the same merge that a `git pull` would perform, and there are 2 extra factors that make me think it's a workable idea:

1) At the moment, `git merge` does nothing. Except mock me for not giving it a
command in a format it recognises. This change wouldn't have any effect that
would cause anyone a problem

2) When I checkout a branch which has unmerged changes in the tracking branch,
git *tells me* what branch I will be taking action with "Your branch is behind
the tracked remote branch '...' by 4 commits, and can be fast-forwarded" - but
then makes me type it out explicitly anyway!

I appreciate that there are many workflows where there is an advantage in performing a second pull in case there are additional changes since the first pull, but I still think there is a string case for git merge having a more sensible default, as git pull does.

What do you think?

Thanks, Gareth