4 ms·

Why? It would be better, I frequently commit in. This way it is even easier to find the offending commit, because changes are smaller (yes, sometimes not worki

by krzyk 5y ago

Why? It would be better, I frequently commit in. This way it is even easier to find the offending commit, because changes are smaller (yes, sometimes not working at all).

wojciechpolak 5y ago
Because: "Fossil, in contrast, puts more emphasis on recording exactly what happened, including all of the messy errors..."
- mpweiher 5y ago
  Logical errors, dead-ends. You don't commit when the tests fail.
  - Cthulhu_ 5y ago
    Shouldn't, and shouldn't be able to (git pre-commit hook), but some people don't have that, some people use git as cmd+s.
yoz-y 5y ago
If tests must pass in every commit then you can just run bisect with the test runner and go grab a coffee.
- handrous 5y ago
  Agreed. I'm entirely not following how a commit stream that may contain entirely broken commits aids in bisecting to find a specific flaw. Those would just be noise, at best. Even if you're just manually testing each commit, you do need it to build and run.
  - krzyk 5y ago
    git bisect is not something one thinks when commiting code. And there is a difference between entirely broken builds and not-tested ones.
    - yoz-y 5y ago
      > git bisect is not something one thinks when commiting code. depends on the repo structure > And there is a difference between entirely broken builds and not-tested ones. depends on your testing philosophy and process
- krzyk 5y ago
  Does everyone test if their commits don't break the build? I doubt that, e.g. if you want to commit before going home, there isn't always time to test and more importantly until you push to master/target branch there is no need for it besides bisection, which I'm not sure if is common.
  - yoz-y 5y ago
    Depends on your workflow of course. Having all commits on master always pass tests (and thus requiring to rebase the merged branches so their individual commits pass) has advantages (such as this easy bisect). You would still be able to commit and push to your feature branch without breaking the CI. I guess it would be possible to enforce the rules on feature branches but that would be counter productive IMO.
    - krzyk 5y ago
      OK, but if you commit on feature branches then those commits will land also on master (squashing is not something popular and makes frequent commits pointless). Frequent commits (without making sure they pass tests) allow better git blame/annotate (figuring out why given line of code was added, and having a general comment "introduce feature ABC" is not helpful, but having a message "add field to to something" is). You can't make detailed commit messages if you have large changes. But yeah, everything depends on the workflow one commits to.
      - yoz-y 5y ago
        When I worked with git I squashed/reordered my feature branch to make it pass tests on every commit before merging it with the master. This is usually not very hard and you can still do small commits. You can even split new tests into a separate commit. Honestly I don’t really see why would you want to change code that breaks tests without updating them in the same commit. Updates in tests give strong signal to the PR reviewer to see that an API has changed. When fixing bugs it’s also nice to be able to reproduce it with a test case first, then fix it.
mcintyre1994 5y ago
The problem is that bisect depends on being able to determine whether the commit you land on has the newly found bug or not. That almost certainly depends on it at least building, so that you can run it and check. If you can't do that then you can't determine if the bug exists on that commit, and you can't bisect effectively.
- steerablesafe 5y ago
  You can always skip, can't you?

by krzyk 5y ago

Why? It would be better, I frequently commit in. This way it is even easier to find the offending commit, because changes are smaller (yes, sometimes not working at all).

wojciechpolak 5y ago

Because: "Fossil, in contrast, puts more emphasis on recording exactly what happened, including all of the messy errors..."

mpweiher 5y ago
Logical errors, dead-ends. You don't commit when the tests fail.
- Cthulhu_ 5y ago
  Shouldn't, and shouldn't be able to (git pre-commit hook), but some people don't have that, some people use git as cmd+s.

yoz-y 5y ago

If tests must pass in every commit then you can just run bisect with the test runner and go grab a coffee.

handrous 5y ago
Agreed. I'm entirely not following how a commit stream that may contain entirely broken commits aids in bisecting to find a specific flaw. Those would just be noise, at best. Even if you're just manually testing each commit, you do need it to build and run.
- krzyk 5y ago
  git bisect is not something one thinks when commiting code. And there is a difference between entirely broken builds and not-tested ones.
  - yoz-y 5y ago
    > git bisect is not something one thinks when commiting code. depends on the repo structure > And there is a difference between entirely broken builds and not-tested ones. depends on your testing philosophy and process
krzyk 5y ago
Does everyone test if their commits don't break the build? I doubt that, e.g. if you want to commit before going home, there isn't always time to test and more importantly until you push to master/target branch there is no need for it besides bisection, which I'm not sure if is common.
- yoz-y 5y ago
  Depends on your workflow of course. Having all commits on master always pass tests (and thus requiring to rebase the merged branches so their individual commits pass) has advantages (such as this easy bisect). You would still be able to commit and push to your feature branch without breaking the CI. I guess it would be possible to enforce the rules on feature branches but that would be counter productive IMO.
  - krzyk 5y ago
    OK, but if you commit on feature branches then those commits will land also on master (squashing is not something popular and makes frequent commits pointless). Frequent commits (without making sure they pass tests) allow better git blame/annotate (figuring out why given line of code was added, and having a general comment "introduce feature ABC" is not helpful, but having a message "add field to to something" is). You can't make detailed commit messages if you have large changes. But yeah, everything depends on the workflow one commits to.
    - yoz-y 5y ago
      When I worked with git I squashed/reordered my feature branch to make it pass tests on every commit before merging it with the master. This is usually not very hard and you can still do small commits. You can even split new tests into a separate commit. Honestly I don’t really see why would you want to change code that breaks tests without updating them in the same commit. Updates in tests give strong signal to the PR reviewer to see that an API has changed. When fixing bugs it’s also nice to be able to reproduce it with a test case first, then fix it.

mcintyre1994 5y ago

The problem is that bisect depends on being able to determine whether the commit you land on has the newly found bug or not. That almost certainly depends on it at least building, so that you can run it and check. If you can't do that then you can't determine if the bug exists on that commit, and you can't bisect effectively.

steerablesafe 5y ago
You can always skip, can't you?