Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

DiffDebugging

martinfowler.com

Post reply on HN
Print view View original

21–30 of 43 posts

Re: DiffDebugging

#21

Post by m463 »

ReleaseCandidat wrote: post #20
jkaptur wrote: post #7

> I originally posted this page on 2004-06-01... Diff debugging isn't a term that's caught on much in the industry, but I haven't seen a another term generally used to describe it. I can't speak to 2004, but these days "bisect" is the standard term in my circles (even when we're not actually using git and its bisect command). It would be interesting to know whether git was the first to associate that word with this a…

Bisecting an interval has been in use in mathematics quite some time before the existence of Git. Bolzano proved (his version of) the intermediate value theorem in 1817, but it has been used in calculations for _way_ longer.

I think we said "use a binary search to find the regression" or similar.

Re: DiffDebugging

#22

Post by theyinwhy »

pixel_tracing wrote: post #10

A well known very large successful trillion dollar company emphasizes this heavily and it’s called identifying Cause By, regressions are categorized before a build is submitted, in the current build, or in previous builds. It’s extremely important to identify cause by (commit) in order to either revert or fix.

Sounds interesting. Could you elaborate, I don't quite understand it. You test for regression errors before commit? But why commit with known regression errors?

Re: DiffDebugging

#23

Post by heads »

juped wrote: post #19

Note that when (other people's, surely, not yours) bad git history with unrelatedly-broken commits everywhere means you can't bisect, you can use bisect --first-parent to travel down only the first-parent history (which should be just merges to master) rather than having to laboriously figure out whether it's "bad" or "skip" this time. If you're unfortunate enough to have an impoverished "linear history", you're stuc…

The usual definition of “linear history” is equivalent to what you see with “git log --first-parent”. Linear history doesn’t mean that people share every “wip” commit from their private feature branch with everyone else.

With linear history you squash everything into a single, working commit which is applied to the tip of the shared branch. The rationale is that each change is like a published piece of writing: it will have been through multiple drafts and final versions as well as being edited and peer reviewed, but ultimately the only thing any of your peers care about is the finished work. None of the incomplete, broken, or unreviewed intermediate versions belong in the shared history and they can be thrown away.

Two counter points to this. First, the code review discussion is often recorded forever but in a social tool that’s kept separate from the code itself.

Second, if you end up being as famous for your code as Austen, Thackeray, Shakespeare or Da Vinci were for their literature then your “work in progress” commits and v0 drafts are very valuable and worth keeping. The amount of people this could apply to is not a large number.

Re: DiffDebugging

#24

Post by bad_username »

The culture of rebasing and squashing is the enemy of DiffDebugging. When you squash, you make your deltas very big and less useful. When you rebase, you generally lose your deltas completely, because a rewritten history consists of commits nobody generally tried out.

Re: DiffDebugging

#25

Post by eternal_braid »

bad_username wrote: post #24

The culture of rebasing and squashing is the enemy of DiffDebugging. When you squash, you make your deltas very big and less useful. When you rebase, you generally lose your deltas completely, because a rewritten history consists of commits nobody generally tried out.

The culture refers to commits like: "add tests" "track new files" "test passes" "tests compile" "temp" and not to logically independent changes.

Re: DiffDebugging

#26

Post by 48864w6ui »

ReleaseCandidat wrote: post #20
jkaptur wrote: post #7

> I originally posted this page on 2004-06-01... Diff debugging isn't a term that's caught on much in the industry, but I haven't seen a another term generally used to describe it. I can't speak to 2004, but these days "bisect" is the standard term in my circles (even when we're not actually using git and its bisect command). It would be interesting to know whether git was the first to associate that word with this a…

Bisecting an interval has been in use in mathematics quite some time before the existence of Git. Bolzano proved (his version of) the intermediate value theorem in 1817, but it has been used in calculations for _way_ longer.

Going back a little more, there's Zeno

Re: DiffDebugging

#27

Post by rightbyte »

nonethewiser wrote: post #8
nerdponx wrote: post #3

This has been an essential tool for me over the years as a working "data scientist". Let's say you've been working on an "algorithm", which is a combination of cleverly-crafted SQL to fetch the right data, some ad-hoc data processing code in Python, getting predictions from a model, and some additional mathy stuff to translate the model prediction into something useful. You probably built it interactively in a REPL o…

I worked somewhere that had very complicated price calculations. The complexity came from all sorts of options like pricing schemes, taxes, etc. Many were optional and there were all sorts of interdependencies. It returned an object with lots of pricing details. It really, really sucked to change or debug and there were 0 tests. I added some tests like you described. Some known price inputs and configuration options…

A think such "does the behaviour change" tests are fine. Like, you could not travel back in time and force doing docs and tests on the original sinners.

Re: DiffDebugging

#28

Post by 48864w6ui »

Why is this general technique worth a blog post by someone who makes his living coaching working programmers, and not taught in elementary school?

(To be fair I think the first time I heard it explicitly from a teacher was Jr high shop class)

Edit: at what age do people usually learn to play 20 questions?

Re: DiffDebugging

#29

Post by pnt12 »

bad_username wrote: post #24

The culture of rebasing and squashing is the enemy of DiffDebugging. When you squash, you make your deltas very big and less useful. When you rebase, you generally lose your deltas completely, because a rewritten history consists of commits nobody generally tried out.

Unless we're talking about different workflows, squashing works great.

In my team, we merge squash our PRs, having a guideline that they should be a small increment. Here's what happrns:

- when you checkout a commit, you are guaranteed to have a version that was reviewed by a person and validated by ci/cd - most commits have chsnegs with substance, instead of "log", "debug", etc

Without squash, a person can push 3 commits to a feature branch, ci/cd says the last commit is OK, it gets merged, and you may get 2 commits that don't compile or cause a very basic runtime error due to some typo or whatever.

(not that it could not be solved with due diligence, but that comes with higher effort too)

How do you assure working commits and avoid noise without either squash or rebase?

Re: DiffDebugging

#30

Post by pnt12 »

broast wrote: post #11
RegW wrote: post #4

DiffDebugging is not a term I have ever heard of before, but I guess it's something I do on a regular basis. The code used to work, it doesn't now, WTF has changed?

Right, this is the common sense approach for identifying the cause of a regression. Not sure what people do other than this unless it's a very simple codebase

I don't see this technique applied too often. I see more often:

- reading the affected code - reproducing the problem step by step with a debugger

Which I guess works for all kinds of problems and not just for regressions, therefore people are more used to it?

Post reply on HN