pull/push inconsistencies

["Martin Langhoff" <martin.langhoff@gmail.com>]

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