On Sep 7, 2014, at 9:50 PM, Pascal Quantin <pascal.quantin@xxxxxxxxx> wrote:
> Because as you committed directly in master, you might have a merge commit lying around created if you updated without rebasing.
This comes in handy for me - I do "git update" whenever I want to update one of my trees:
$ cat ~/bin/git-update
#! /bin/sh
#
# No, I don't *WANT* to change my workflow to what the Git Community(TM)
# thinks is should be. I don't *WANT* to keep checking crap into my
# personal repository if it's not done yet.
#
# This implements the moral equivalent of "svn update". It stashes
# changes away, does a pull, rebases to the remote, and then does
# a "stash apply" to apply the changes and un-stash them.
#
git stash; git pull; git rebase; git stash pop
(Yes, it should probably avoid doing the "git stash pop" if there wasn't anything pushed in the first place, and, yes, it should probably do something such as a "git stash drop" if the pop applied changes and then didn't discard the top of the stash stack because it requires manual intervention, so it's not *quite* a perfect replacement for "svn update".)
I try to get into the habit of doing a "git update" before committing a change (or even just doing it after a change gets reviewed and accepted).