Hacker News Reader

Comment by Benjammer | Hacker News Reader

>you notice something goes wrong later,

What, specifically, do you mean by "something goes wrong later"? Like a full outage of some kind? A production bug? A mistake according to the design spec? A failed test in CI? A failed human QA validation? What are we talking about here?

>it's much easier to trace where the problem is.

Furthermore, why would the git commit structure have anything to do with debugging any type of issue, regardless? Isn't debugging mostly comprised of combing through logs, adding random print statements to console output, and using an IDE debugger? Or some kind of more advanced tracing/profiling tools? Are you debugging by hunting in commit histories and Jira tickets or something?

Or are you talking about blaming, not "tracing where the problem is", but "tracing who the problem is"?

View on HN

This post explains it better than I can in a comment: https://medium.com/@fredrikmorken/why-you-should-stop-using-...

That article is some FUD about a real bug in a feature branch being masked due to other bugs that were introduced by the rebase itself.

That is not realistic because, firstly, a very specific test can (and should) be used for git bisect. You're not just testing for "software fails", but "very specific case fails in a specific way".

If some intermediate issues prevent you from testing the specific test case (you're not able to call "good" or "bad"), you can tell git bisect to skip that commit.

Shit happens! Bug was introduced a month ago, but two weeks ago, a range of commits happened that don't even build in your environment. git bisect will hit that.

The article also glosses over the possibility that git bisect goes back farther than the bad commit. Commits that are not testable can occur earlier or later than the one we are looking for.

Basically the article is just a new version of the old meme "merging is dangerous". except that it doesn't make any sense, since both "git merge" and "git rebase" textually merge code.

I think the best point of this article is accidentally introducing breakages into history that later defeat the purpose of git-bisect. However, in practice I haven't run into this problem, at least not in an insurmountable way.

One solution is, if you can run your tests with e.g. `make test`, you can run `git rebase --exec "make test"` which will run your test suite against every commit being rebased. I've only done it a handful of times, and because of how long it takes I'd only run it after finishing a rebase that wound up needing resolutions, instead of doing it up front and having to wait for the tests to finish at each commit before potentially resolving another upcoming conflict.

If you are very paranoid about breaking commits being pushed, disallowing rebase isn't enough: any dev could simply write a commit with a breakage. You'd have to set up pre-commit hooks to run your tests, or a pre-push hook to run `git rebase --exec "make test"`. TIL there is also a post-rewrite hook, which sounds like it solves exactly your worry with rebase, but as I mentioned, introduces long delays between rebase commits/resolutions–I'd probably forget what I was doing during each test run, haha.

It can definitely be made workable, but why do so much in pursuit of a slightly neater git log? I place a much higher value on the hashes of my commits not changing than having extra merge commits.

FWIW I prefer rebasing locally (to squash/split/cleanup commits, or catch up to upstream) and merging remotely (create a merge commit at the completion of each work branch). I just wanted to get the info out there for those interested!

Good point. I think people don't realize just how much git is capable of doing. Pretty much any strategy can be made to work with git, and it's super extensible if you need it to be.

I generally follow your strategy myself as long as it's something small, but I think there's this meme out there that having merge commits in your branch is somehow shameful, when in reality it should celebrated as an accurate history.

>Why do we use Git at all? Because it is our most important tool for tracking down the source of bugs in our code. Git is our safety net.

I disagree with git as a bug tracking tool, it's a distributed code repository. It's closer to google docs than it is to an IDE debugger or a system log.

I also disagree with the idea that "tracking down the source of bugs" has anything to do with quality or a "safety net."

Can someone please explain to me where this kind of "commit blame" culture comes from? And what the point is? What is the next step that happens after you identify the "offending commit"? I don't understand why you wouldn't just open a new PR to fix the bug and move the fuck on with your life? What business value is there in this type of exercise to specifically identify which git commit "caused a bug"?

Reply on news.ycombinator.com