Welcome to the Power Users community on Codidact!

Power Users is a Q&A site for questions about the usage of computer software and hardware. We are still a small site and would like to grow, so please consider joining our community. We are looking forward to your questions and answers; they are the building blocks of a repository of knowledge we are building together.

Post History

71%

+3 −0

Q&A How can I filter GitHub commits by date range, in a friendlier way than git log?

I would handle this with git bisect. Assuming you have a known good old commit C_GOOD (this would be your "since") and a known bad new commit C_BAD (this would be your "until"), git bisect start C_...

posted 1y ago by matthewsnyder‭ · edited 1y ago by matthewsnyder‭

Answer

#3: Post edited by

matthewsnyder‭ · 2023-10-25T16:41:04Z (about 1 year ago)

Copy Link

Raw

Markdown

I would handle this with [`git bisect`](https://git-scm.com/docs/git-bisect). Assuming you have a known good old commit `C_GOOD` (this would be your "since") and a known bad new commit `C_BAD` (this would be your "until"), `git bisect start C_BAD C_GOOD` will walk you through running a manual [binary search](https://en.wikipedia.org/wiki/Binary_search_algorithm) to efficiently find which commit introduced the bug. There are some caveats that go with binary search, for example, it will get confused if the bug was fixed and reintroduced multiple times in your commit range.
Basically, bisect will checkout some commit in the range for you, ask you if it looks good or bad (you do this by typing `git bisect good` or `git bisect bad`), and use that to decide which next commit to try as it searches.
Note that bisect treats "bug" and good/bad as very subjective. Maybe the "bug" is that the code looks ugly to you. When bisect gives you a commit, you take a look at the code, and respond good/bad based on whether it looks ugly to you. The result will be the first commit that made it look ugly to you.
Of course you should be consistent in your good/bad judgement, otherwise bisect might give incorrect results. As in, don't change your mind on what counts as good/bad halfway through the bisect :)

I would handle this with [`git bisect`](https://git-scm.com/docs/git-bisect). Assuming you have a known good old commit `C_GOOD` (this would be your "since") and a known bad new commit `C_BAD` (this would be your "until"), `git bisect start C_BAD C_GOOD` will walk you through running a manual [binary search](https://en.wikipedia.org/wiki/Binary_search_algorithm) to efficiently find which commit introduced the bug. There are some caveats that go with binary search, for example, it will get confused if the bug was fixed and reintroduced multiple times in your commit range.
Basically, bisect will checkout some commit in the range for you, ask you if it looks good or bad (you do this by typing `git bisect good` or `git bisect bad`), and use that to decide which next commit to try as it searches.
Note that bisect treats "bug" and good/bad as very subjective. Maybe the "bug" is that the code looks ugly to you. When bisect gives you a commit, you take a look at the code, and respond good/bad based on whether it looks ugly. The result will be the first commit that made it look ugly.
Of course you should be consistent in your good/bad judgement, otherwise bisect might give incorrect results. As in, don't change your mind on what counts as good/bad halfway through the bisect :)

#2: Post edited by

matthewsnyder‭ · 2023-10-25T16:40:36Z (about 1 year ago)

Copy Link

Raw

Markdown

I would handle this with [`git bisect`](https://git-scm.com/docs/git-bisect). Assuming you have a known good old commit `C_GOOD` (this would be your "since") and a known bad new commit `C_BAD` (this would be your "until"), `git bisect start C_BAD C_GOOD` will walk you through running a manual [binary search](https://en.wikipedia.org/wiki/Binary_search_algorithm) to efficiently find which commit introduced the bug. There are some caveats that go with binary search, for example, it will get confused if the bug was fixed and reintroduced multiple times in your commit range.
Basically, bisect will checkout some commit in the range for you, ask you if it looks good or bad (you do this by typing `git bisect good` or `git bisect bad`), and use that to decide which next commit to try as it searches.
Note that bisect treats "bug" and good/bad is very subjective. Maybe the "bug" is that the code looks ugly to you. When bisect gives you a commit, you take a look at the code, and respond good/bad based on whether it looks ugly to you. The result will be the first commit that made it look ugly to you.
Of course you should be consistent in your good/bad judgement, otherwise bisect might give incorrect results. As in, don't change your mind on what counts as good/bad halfway through the bisect :)

I would handle this with [`git bisect`](https://git-scm.com/docs/git-bisect). Assuming you have a known good old commit `C_GOOD` (this would be your "since") and a known bad new commit `C_BAD` (this would be your "until"), `git bisect start C_BAD C_GOOD` will walk you through running a manual [binary search](https://en.wikipedia.org/wiki/Binary_search_algorithm) to efficiently find which commit introduced the bug. There are some caveats that go with binary search, for example, it will get confused if the bug was fixed and reintroduced multiple times in your commit range.
Basically, bisect will checkout some commit in the range for you, ask you if it looks good or bad (you do this by typing `git bisect good` or `git bisect bad`), and use that to decide which next commit to try as it searches.
Note that bisect treats "bug" and good/bad as very subjective. Maybe the "bug" is that the code looks ugly to you. When bisect gives you a commit, you take a look at the code, and respond good/bad based on whether it looks ugly to you. The result will be the first commit that made it look ugly to you.
Of course you should be consistent in your good/bad judgement, otherwise bisect might give incorrect results. As in, don't change your mind on what counts as good/bad halfway through the bisect :)

#1: Initial revision by

matthewsnyder‭ · 2023-10-25T16:40:09Z (about 1 year ago)

Copy Link

Raw

Markdown

I would handle this with [`git bisect`](https://git-scm.com/docs/git-bisect). Assuming you have a known good old commit `C_GOOD` (this would be your "since") and a known bad new commit `C_BAD` (this would be your "until"), `git bisect start C_BAD C_GOOD` will walk you through running a manual [binary search](https://en.wikipedia.org/wiki/Binary_search_algorithm) to efficiently find which commit introduced the bug. There are some caveats that go with binary search, for example, it will get confused if the bug was fixed and reintroduced multiple times in your commit range.

Basically, bisect will checkout some commit in the range for you, ask you if it looks good or bad (you do this by typing `git bisect good` or `git bisect bad`), and use that to decide which next commit to try as it searches.

Note that bisect treats "bug" and good/bad is very subjective. Maybe the "bug" is that the code looks ugly to you. When bisect gives you a commit, you take a look at the code, and respond good/bad based on whether it looks ugly to you. The result will be the first commit that made it look ugly to you.

Of course you should be consistent in your good/bad judgement, otherwise bisect might give incorrect results. As in, don't change your mind on what counts as good/bad halfway through the bisect :)

Communities

Post History