pull/push inconsistencies

I am noticing some UI inconsistencies with pull/push. Not sure where they are -- and quite busy atm -- if they are in bash I might be able to hunt them down and fix. In case anyone else cares...

--

When tracking several branches from a repo, git-pull does a fetch (of all the remote heads) and merges _only the tracking branch currently checked out_. That's ok. However, if I checkout another tracking branch and issue git-pull, the merge does not happen because git-fetch finds nothing new on the remote side. git-pull should merge anyway if remotes/origin/<trackinghead> is ahead of the local head.

The workaround is to call git-merge explicitly, but git-pull is misleading the user saying "nothing to merge" instead of completing the merge.

--

My second issue is that git-push does not update remotes/<repo>/<headname> so if I do git-push && gitk --all it looks as if I haven't pushed. Misleading again. :-/

--

Third issue - if I do

  # we start with a cloned repo that is in sync with
  # its "origin" repo. No local commits to speak of...
  # git-fetch brings updates to 3 remote branches - none affecting the current
  # checked out branch...
   git-fetch
   git-commit some/path
   git-push

the output of git-push will show _4_ branches being pushed. For some reason git-push says that it's pushing remotes/origin/branchname -> origin/branchname for all the branches fetched recently -- and not modified! I expect only _1_ branch to be named during push - the only one.

None of the above are showstoppers, but the user feedback of these commands - the very core workflow for beginners - is quite confusing. I know how to check that things are correct in spite of the messages, and by now I trust git internals to do the right thing. But newcomers are getting some frights over here...

cheers,

martin