Reasons to use "git pull --rebase" by default

Rebase is a really sharp knife. Sometimes a really sharp knife is what you need, but it's also possible to accidentally injure yourself.

(thanks to Bill Blunn for the imagery).

Reasons to use "git pull --rebase" and not "git pull" (which merges by default):

• Prevents massive weird conflicting-with-yourself problems if anyone rebases that branch later, e.g. just before merging to master
• Keeps all the commits together in a bunch at the top of the tree so you can easily identify them visually
• Allows "git diff master..HEAD" to work without including unrelated changes

Reasons not to use "git pull --rebase" and stick with "git pull" (using merges):

• It's the default, so most people will use it, and their merges will clash with your rebases

Comparison table:

issue	git pull (default: merge)	git pull --rebase
git log, in a feature branch	pro: you always see when master was merged con: your commits will be interleaved with others commits (less of a problem for short-lived branches)	pro: root of feature branch is transparently moved to head of master pro: all your commits are kept bunched together con: you don't know when master was merged con: you have to notify everyone downstream
diff feature branch against master	con: it's more difficult to diff against master	pro: "git diff master" just works
mixing rebase and merge	con: you can't rebase without weird conflicts	con: you can't merge downstream without weird conflicts (not sure about this one)

(thank you tablesgenerator.com)

Advanced subversion usage

Rebase branch on trunk

cd /working/dir/path/to/branch

svn log --stop-on-copy | tail -4 | grep ^r | cut -d' ' -f1 | sed 's/r//'
1111

svn propget db:::dweb::trunk:last_merge_from /working/dir/path/to/branch
2222

svn merge -r 1110:2222 https://remote/path/to/trunk /working/dir/path/to/branch

# check for conflicts and test

svn commit -m'Pull from trunk'

Diff branch against trunk

svn propget db:::dweb::trunk:last_merge_from /working/dir/path/to/branch
1111

svn diff https://remote/path/to/trunk@1111 https://remote/path/to/branch

How to use git with an svn repo

Do you have a subversion repo? Think you're stuck with outdated subversion workflows? Not anymore! Use the fabulous git to work with your subversion hosted code:

git svn clone https://example.com/path/to/trunk -T trunk -b branches -t tags

(may take a long time with large repos, e.g. several days)

Now you can rebase your code! You can do all your work with git - easily branch, stash, rebase, blame, etc. - and when you're done, push back to subversion.

(source)

See subversion branches:
git branch -r

Update the git repo (may take several hours for large repos - you don't need to run this more than once):
git svn fetch --fetch-all

Update the current branch (run this on trunk/master instead of "fetch" above):
git svn rebase

(source)