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.
How can I filter GitHub commits by date range, in a friendlier way than git log?
We have a repository hosted on GitHub. I'm trying to track down a bug and have narrowed the date range for when it could have been introduced. I would like to easily review commits in that date range, and ideally I'd like to get other team members to help in this review.
I know that from the command line I can use git log with --since and --until options, but that just gets me a log -- a list of commit hashes and messages -- on my local machine. In order to see what happened, I have to jump through some extra hoops client-side, and that's a necessarily solitary activity.
What I would like, instead, is a way to produce that list on the web, with the commit hashes being links to the commits like they are in the full history on GitHub, so that it's easy to browse the many commits in the date range to get a sense of what changed and zero in on the likely suspects. If I could do this on the web, I could share links to specific changes of possible interest with team members who are better qualified than I am to evaluate them.
I searched for a solution and found more people with my problem, but no answer. I found an open issue for a third-party package requesting search by date range, but nothing for GitHub itself.
How can I see GitHub commits in a date range with GitHub's usual convenient links and changelists/diffs?
1 answer
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_BAD C_GOOD will walk you through running a manual binary search 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 :)
0 comment threads
4 comment threads