8 ms·
Slightly meta: Turning off the syntax highlighting entirely seems a bit hardcore to me, however, I always read each commit I do via git diff / pull request view
by jakub_g 10y ago
Slightly meta: Turning off the syntax highlighting entirely seems a bit hardcore to me, however, I always read each commit I do via git diff / pull request view, which does not have syntax highlighting (other than red/green for removals/additions), and I always strive to make the diff look good for each commit (which means, doing one thing at a time in each commit, and making sure it reads well).
Unfortunately, not everyone I work with reads their code (yep, they write-commit-push-and-forget!) which sometimes makes code review a not so nice experience.
Please, please, read your diffs before sending code for review.
- taeric 10y agoI'm just trying to convince folks to actually write commit messages. :) I don't think anyone is relying on diffs to find bugs. Do they? Similarly, before doing something complicated at work, please talk about it with a coworker first. Last thing I want is to try to decipher a complicated piece of code without a good motivator as to why I'm doing so. Advanced warning is a great motivator.
- jmhain 10y agoI do this, but not mainly to find bugs, though on rare occasions I do. I almost always find something, e.g. stylistic aberrations, overzealous changes from an intellij refactor, debug statements I forgot to remove, part of another change I'd thought I'd stashed but somehow ended up in the commit. It blows my mind that anybody would not read their diffs.
- taeric 10y agoFair. I try to do this. I still make mistakes, I'm sure. This ultimately comes down to a "good intentions." Would be neat to make a mechanism out of it.
- DSMan195276 10y agoI agree completely. On that note, I also consider `git add -A` to be horrible practice. Adding files manually makes you tons more aware of what changes you actually made, and also prevents you from accidentally adding extra files you don't want. I also recommend people to look at the Linux kernel git history for good examples of how to use git well. Even if you have no knowledge of kernel code (and most people don't) it's still extremely clear how each commit makes a single change and is fairly easy to review. Now, the Linux kernel has the luxury of being able to demand people fix their commits, but that's not to say you shouldn't strive to reach similar states in your commits.
- OJFord 10y ago> I also consider `git add -A` to be horrible > practice. Adding files manually makes you tons more > aware Agreed, but I take it further than that - I always use `git add -p` because it forces me to read through everything, and make everything in the commit deliberate. Even if you think you just made a slight change to a file or two and definitely want everything, you'd be surprised how often it lets me pick up some aesthetic change, comment change, or dependency version bump that's completely unrelated to the commit message I'm about to write.
- jakub_g 10y agoI am in the other extreme: I always use `git add -A` (but I read the diff before) and avoid doing more than one thing in the first place (which would make me want to use `git add -p`). IMO it is an antipattern to do bazillion changes at once, and then do several commits out of it (unless you really know what you're doing) - because you commit a state of the repo that (probably) never existed. I prefer to do change, commit, do change, commit, and at the end do interactive rebase and perhaps squash some things together.
- msarchet 10y ago> because you commit a state of the repo that (probably) never existed The state doesn't exist in the repository until the code has been committed - so your statement is a little backwards. Sure the code might never have only had that edit in it, but the repository has no changes until a commit is made.
- dwaltrip 10y agoWhat the commenter means is that one might accidentally select some invalid or non-sensical set of partial changes (that won't compile or run) in an effort to create a logical progression between state A, "no feature", and state B, "feature is complete". If a bug is found, the invalid state of the intermediate commits might make it harder to isolate the change that caused the bug. That being said, I generally use "git add -p". I've gotten accustomed to trying to have clean commits. Although, sometimes the changes have enough complexity that breaking them up becomes too painful and I end up with a few messy commits. Such is life.
- artursapek 10y agoAgreed. The first thing the older guys taught me at my first internship was `git add --patch`.
- robohamburger 10y agoLearning to this both after writing the code and being able to plan what chunks of works I do when is a game changer and really useful when you work on a team. I sometimes find waiting until I am done working on something to break it up into small commits can be a headache.
- hawski 10y agoI prefer doing this with 'git gui'. It's standard and is very simple to use. What is important you can easily select chunks or lines to stage or unstage.
- jasoncchild 10y ago>Slightly meta: Turning off the syntax highlighting entirely seems a bit hardcore to me, however, I always read each commit I do via git diff / pull request view, which does not have syntax highlighting (other than red/green for removals/additions), and I always strive to make the diff look good for each commit (which means, doing one thing at a time in each commit) ...alas, some projects require 1 commit per pr, max... ...then again, if you do a 1:1 commit:change as default the rebase msg is much easier to structure :)
- hellofunk 10y agoI'm amazed someone wouldn't read their diffs, just for their own sanity. It's a great summary to remind yourself what you just did to resolve an issue. And what if your cat just walked over your keyboard while you weren't looking? Your diff will tell you this. Silly but meaningful example.
- Kubuxu 10y agoI always use `git commit -v` (with alias). You get the diff in the editor when you write commit message.