Skip to main content

Debugging with Git Bisect - Find Bugs Fast

Tracking down a bug in a large codebase can be frustrating. **Git bisect** helps by using a binary search to quickly find the exact commit that introduced the issue.


## Step 1: Start Git Bisect

Begin by starting bisect mode:

```sh

git bisect start

```


## Step 2: Mark a Good and Bad Commit

Specify a known working commit:

```sh

git bisect good a1b2c3d

```

Mark the current commit (where the bug exists) as bad:

```sh

git bisect bad

```


## Step 3: Test and Mark Commits

Git checks out a middle commit. Run your app and test it:

```sh

./gradlew bootRun

```

If the bug exists:

```sh

git bisect bad

```

If the bug is not present:

```sh

git bisect good

```


## Step 4: Find the Bad Commit

Once Git finds the problematic commit, it displays:

```sh

1234567 is the first bad commit

```


## Step 5: Reset Git Bisect

Once the issue is identified, reset bisect mode:

```sh

git bisect reset

```


## Conclusion

Using **git bisect** can save you hours when debugging! Instead of checking each commit manually, bisect efficiently pinpoints the issue in just a few steps.


Comments

Post a Comment

Popular posts from this blog

Handling Kafka Retries in Spring Boot: Blocking vs. Reactive Approaches

  Introduction Apache Kafka is designed for high availability, but failures still happen—network issues, broker crashes, or cluster downtime. To ensure message delivery, applications must implement retry mechanisms. However, retries behave differently in traditional (blocking) vs. reactive (non-blocking) Kafka producers. This guide covers: ✅ Kafka’s built-in retries ( retries ,  retry.backoff.ms ) ✅ Blocking vs. non-blocking retry strategies ✅ Reactive Kafka retries with backoff ✅ Fallback strategies for guaranteed delivery ✅ Real-world failure scenarios and fixes 1. Kafka Producer Retry Basics When Do Retries Happen? Kafka producers automatically retry on: Network errors (e.g., broker disconnect) Leader election (e.g., broker restart...
Post a Comment
Read more

🔄 Kafka Producer Internals: send() Explained with Delivery Semantics and Transactions

Kafka Producer Internal Working Apache Kafka is known for its high-throughput, fault-tolerant message streaming system. At the heart of Kafka's data pipeline is the Producer —responsible for publishing data to Kafka topics. This blog dives deep into the internal workings of the Kafka Producer, especially what happens under the hood when send() is called. We'll also break down different delivery guarantees and transactional semantics with diagrams. 🧠 Table of Contents Kafka Producer Architecture Overview What Happens When send() is Called Delivery Semantics Kafka Transactions & Idempotence Error Handling and Retries Diagram: Kafka Producer Internals Conclusion 🏗️ Kafka Producer Architecture Overview Kafka Producer is composed of the following core components: Serializer : Converts key/value to bytes. Partitioner : Determines which partition a record should go to. Accumulator : Buffers the records in memory be...
Post a Comment
Read more

Project Reactor Important Methods Cheat Sheet

🔹 1️⃣ subscribeOn – "Decides WHERE the Pipeline Starts" 📝 Definition: subscribeOn influences the thread where the data source (upstream) (e.g., data generation, API calls) runs . It affects the source and everything downstream (until a publishOn switches it). Flux<Integer> flux = Flux.range(1, 3) .doOnNext(i -> System.out.println("[Generating] " + i + " on " + Thread.currentThread().getName())) .subscribeOn(Schedulers.boundedElastic()) // Change starting thread .map(i -> { System.out.println("[Processing] " + i + " on " + Thread.currentThread().getName()); return i * 10; }); flux.blockLast(); Output: [Generating] 1 on boundedElastic-1 [Processing] 1 on boundedElastic-1 [Generating] 2 on boundedElastic-1 [Processing] 2 on boundedElastic-1 [Generating] 3 on boundedElastic-1 [Processing] 3 on boundedElastic-1 📢 Key Insight: ...
Post a Comment
Read more