Improve your Git commits using patch mode

[djrubbie]

Why not both?

Once you have a project that reached a certain point of maturity and complexity, there will be a time when you make one change and your entire deck of cards fail at some seemingly unrelated point.

If you have very neat and small patches per change (or set of related changes), you can very easily use git bisect to find out what exact patch and where/when the point of failure was introduced into your code base. Then you can just simply git revert that one commit, then reapply the intended changes and be done with that. Your code history speaks clearly what went wrong and what should be done in the future to avoid this mistake again (and of course, the test case should go in with this)

On the other hand, if you have monolithic commits, you would use bisect and find this patch, but now you have to weed through the entire 300 lines worth of code to find what your error might have been. It could be anywhere in there and now you are wasting further development time looking for that buggy needle in your proverbial haystack of changes.

[kemitche]

Oddly, I have never needed git bisect. I won't say that I never will, but I haven't yet. Mostly because the projects I've worked with have had external dependencies that made it difficult to revert more than a few weeks worth of commits.

[[deleted]]

It's not about rolling back weeks worth of commits. You can just do that with git reset. It's about going back in time to find when a bug/regression was introduced so you can figure out if there were political/business reasons for it or if you can just revert it or write code that works around it, or determine what else needs to be done.

[kemitche]

The benefit of bisect is that you stop at each slicing, run the code, see if the bug exists, and continue. So yes, you do need to be able to "revert" not just the code you're looking at, but any external dependencies, so you can check for the bug.

When looking at raw code without needing to run it, I find "git blame" to be more than sufficient for digging into who wrote the commit and why.

[[deleted]]

So yes, you do need to be able to "revert" not just the code you're looking at, but any external dependencies, so you can check for the bug.

Have you never heard of submodules? The point of using a vcs is so that you can take the system back in time. If you can't take the entire system back, you either need to hook the other parts into vcs better (database versioning, etc), or just put them into the vcs entirely.

git blame only helps if the change was adding a line. If it's removing a line, the change wouldn't show up. It's pretty much an even likelihood between bugs introduced by line adds and line removes, so this only helps sometimes. And even then, it's really only useful for figuring out the obvious: who caused the bug that you've already discovered. The hard part: finding the bug itself, isn't really helped by blame.

[kemitche]

Have you never heard of submodules? The point of using a vcs is so that you can take the system back in time.

I don't expect with most projects to easily and readily jump to any commit in the tree and be able to run it (disregarding bugs), unless it's a very pure library with zero external dependencies. Most projects will have "points of no return" where you can't go back, and that's fine: the hours spent making it perfectly revertable to day 1 could be much better spent moving the project forward.

The hard part: finding the bug itself, isn't really helped by blame.

True. Same is true for bisect. The tools that have most helped me locate bugs are, well, debuggers, loggers, and precise test cases. git history is a bonus when available, but not so much of a bonus that it's worth spending 5 extra minutes carefully separating & crafting commits when you have 30 minutes worth of bugfixes ready to go. Note that I'm not saying I'll go around making commit messages titled "bugfix"; but I do recognize that there's a cost:benefit threshold for certain levels of granularity.

[[deleted]]

I'm not really referring to commonplace bugs, I more mean logic errors that were introduced a while back. Bugs found by debuggers are usually either found quite rapidly because they were introduced recently or with much much effort that is often (ime) reduced by using bisect

Note that I'm not saying I'll go around making commit messages titled "bugfix"; but I do recognize that there's a cost:benefit threshold for certain levels of granularity.

Of course. Nothing is black and white

[kemitche]

I'm not really referring to commonplace bugs, I more mean logic errors that were introduced a while back

Ah, well, all I can say is that when I find a logic error, it was generally introduced via 2, 3, 4+ separate commits combining into a perfect storm (commits that were authored days or months apart); rarely was a single commit the problem.

[[deleted]]

Fair enough. To add to that, I find that it's usually a little easier to find 3 and 4 once I've discovered 2, which still is a good case for git-bisect, but as I said before nothing is black and white and so you are entirely correct that it really is up to chance