Code reviews reduce logical errors, call out typos, and prevents accidentally committing more code than intended (1). They're essential for all s...
For further actions, you may consider blocking this person and/or reporting abuse
The
:Gdiffcommand in tpope/vim-fugitive is really handy for this too (see also vimcast 32. I've seen magit for emacs do similar things, too. Really useful for making sure you don't put in any unnecessary changes into a commit after a furious bout of writing. And for splitting an otherwise-too-big set of changes across logical commits.Neat way to automate something I usually do manually. Usually I do something like
git diff -w master > tmp/diffs.txt(orhg diff -r default > tmp/diffs.txt), and examine that, both looking for things that shouldn't be there (like debugging calls and such) and to compose a detailed pull request description. (Sometimes I'll also do this before an individual commit.)I've been completely hooked on SourceTree because it facilitates this way of staging content by default.
It works so well that I've completely abandoned
git add -p(which was my default), and I'm having a hard time using magit in emacs because of SourceTree. When I'm sorting out a smaller set of changes into separate commit, I can still get away with magit.I do prefer magit for interactive rebasing though, which I do often when I inevitably forgot to stage a hunk in a previous commit.
True. But please, be aware, that when you commit only portions of what you've changed, it will be probably the code that you've never actually tried to compile or run or test. And there's no guarantee, that this particular state of code is good. So it is very nice to have some kind of CI server running in the background to catch this kind of problems
I do that, very useful. You can also 'git add -N file' with new files, it adds their existence but not their content, so the latter appears in git diff and git add -p.