Show the full patch for a git merge commit

Use the undocumented -m and -p options to show the main commit ID.
Why are these not in the help!?

git show -m -p 25172c1

Specify git config temporarily for one command

Use -c after the git call, before any other options:

e.g. to override your core.pager="less -r" setting:

    git -c 'core.pager=cat' log -n 3 --abbrev-commit

(source)

How to apply a named stash in git

git stash apply stash^{/foo1}

where foo1 is the full name of your stash (keep names short, with no spaces).

(source)

How to find who/what is changing a file in linux

A list:

• inotifywait - simple, attended
• auditctl - powerful, old school
• file system monitoring - more involved, more complete

See https://pinboard.in/u:random/t:audit

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)