[Myrmornis]

One good reason is to keep your tests separate from the fixes that make your tests pass. That way you can check your test fails before the next commit makes it pass, eliminating the risk of a false negative (test passes that would have anyway).

[Cthulhu_]

That's one approach I suppose, it leaves evidence of "I wrote a test first" and such.

However, it also feels more like a "work log" than a "commit log"; I like to make my commits atomic (test + code at the same time), so that in theory, each individual commit will pass CI. If you separate them, you can't just revert one commit, you need multiple.

[assbuttbuttass]

That sounds like it would break bisect

[Myrmornis]

You could reorder so that the test comes in a commit after the fix rather than before if you want to be able to use plain git bisect, so that no commits are failing. The important thing is that you can use git (i.e. revert in this case) to edit the history to remove the fix and verify the test fails.

[Myrmornis]

Fair. I think what I'd say is that we don't have to use plain git bisect -- it would be quick to make a bisect script that doesn't land on the failing-test commits. Especially seeing as most teams squash before merging, we should have the freedom to create failing-test commits.

[bonzini]

You can develop with failing tests and reorder them after the code change before publishing your branch.

[assbuttbuttass]

Of course, but this thread was in the context of someone "carefully curating" their git history

[jolmg]

Right, maybe a better way to get what they're going for would be

  git checkout @~ ^tests

where ^tests is zsh's way of saying * except for tests. So you get the tests/ of the current commit and the code of the prior.

[locknitpicker]

> That sounds like it would break bisect

Nonsense. First off, you can pick the starting commit, and nothing forces you to pick the test one. Second, bisect is designed to tracks changes from good state to bad state based on your personal criteria of what good and bad is. This means that you are free to put up tests that make sense to you (i.e., all tests except the one that was added as a red test) and even not run a test at all.

[assbuttbuttass]

Suppose we have a failing test. For many commits, gp carefully separated their change that would break our test, from the change that would fix the test. At some point, someone forgot to run the tests, and introduced a commit that broke the test without adding a second commit to fix it. Now it's treated as a "pre-existing failure," and many more commits are added on top.

How would you identify the commit that broke the test?

[locknitpicker]

> How would you identify the commit that broke the test?

You're asking how to use bisect.

You start with a range of commits you picked. All that bisect does is help you search for a commit within that range that introduces a regression. The responsibility to specify which commits you cover is yours, not the tool.

[assbuttbuttass]

And then bisect fails because it finds one of the many commits that broke the test before the actual regression

[locknitpicker]

> And then bisect fails because it finds one of the many commits that broke the test before the actual regression

And that's ok. You skip the commit and move on with your life.

[account42]

And you can also use bisect by first figuring out the broken commit some other way and then marking everything as good if its before that one or bad if its after - but that's not a very productive use of bisect and if its the only available one I think its fair to call it broken.

[locknitpicker]

> And you can also use bisect by first figuring out the broken commit some other way (...)

Bisect exists to be a tool you can use to fix the problems you are facing.

It you are faced by problems you create for yourself and you are unwilling to work around the problems you are creating then there is no tool on earth that can help you.