Why do you want to see those commits? Is it because commits are great? I hope this is the reason you wish to see them, because Git is all about commits, and you should want to see them. I wish everyone felt this way!
I'm going to go out on a limb here and provide a slightly different solution than what you're asking for. In part because I don't think there is a exact solution for what you asked, but more importantly I think over time you may like this idea even better anyway. When I started using Git with a large repo and frequent changes, I realized, like you, that I wished to see commit information regularly, especially when pushing and pulling. It probably took me a year to go from having that desire to landing where I did, which is to rarely ever pull anymore. If someone had told me that when I first learned Git I probably would have thought they were nuts, so it may be hard to swallow until you experience it for yourself. (Spoiler alert: with this method you may stop pulling, but you'll still be pushing like you do now, except you'll already know what commits you'll be pushing before you do it.)
Basically the workflow starts by always having a good UI tool open with a display of your branch, including local outgoing and/or remote incoming commits. This view is kind of what you are asking for but with the extra advantage of you being able to quickly open any commit and see what the changes are, or diff any 2 commits. If you prefer to do this from the command line, you could use:
git status # output includes the number of commit differences between local and remote
git log @..@{u} # list the commits on the remote that you don't have yet
git log @{u}..@ # list the commits you have locally that aren't pushed yet
# Note: substitute a branch name for @{u} if you typically pull from another branch
Now, the above commands and/or UI views are only up to date as of the last time you fetched. Whenever you feel like it throughout the day, from the command line you issue git fetch
, and possibly refresh your UI view if it isn't set to do it automatically. I prefer to fetch from the command line because the output shows you which branches were added, deleted, modified from commit A to commit B, and which were forced pushed. You especially should fetch just before pushing. In case you forgot to fetch before pushing, I also recommend changing your push strategy to:
git push # always prefer this, but if you rebased your branch (or similar), then
# force push but only if all commits on remote branch have been fetched already
git push --force-with-lease
As for replacing pull, since you are fetching often now, and definitely before you would have done a pull, now you can simply do git merge
instead. (And if you used to pull from a different branch than now you would merge in that branch instead.)
Side Note: along a related line of no longer pulling, I also advocate not checking out shared branches anymore, and using their remote counterparts instead. Some example usage of this scenario is here.