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

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

Advanced Kafka Resilience: Dead-Letter Queues, Circuit Breakers, and Exactly-Once Delivery

Introduction In distributed systems, failures are inevitable—network partitions, broker crashes, or consumer lag can disrupt data flow. While retries help recover from transient issues, you need stronger guarantees for mission-critical systems. This guide covers three advanced Kafka resilience patterns: Dead-Letter Queues (DLQs) – Handle poison pills and unprocessable messages. Circuit Breakers – Prevent cascading failures when Kafka is unhealthy. Exactly-Once Delivery – Avoid duplicates in financial/transactional systems. Let's dive in! 1. Dead-Letter Queues (DLQs) in Kafka What is a DLQ? A dedicated Kafka topic where "failed" messages are sent after max retries (e.g., malformed payloads, unrecoverable errors). ...
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