CODEWITHSUNDEEP
gitgit-checkout
Jonathan Clark
Jonathan Clark

Reputation: 1260

Git - Commit with no changes contains bug

Git commit history

Consider this git history. If I checkout the second highlighted commit (or any commits above it / newer), then it contains a bug that I can see on screen (specifics of bug not too relevant).

If I checkout the third commit (or any commits below it / older), then I no longer see the bug on screen.

As you can see though, the second commit containts 0 changed files with 0 additions and 0 delations.

How then does switching between these two commits introduce or remove the bug that I'm trying to fix!? I can't tell which files are being changed between the two commits?

Update

The above image isn't strictly true, the actual situation is below. I didn't realise this could happen in GIT, if someone could explain how NO BUG could get reintroduced on the "Ensure we always return an integer" commit that would be great!

Full git history

Upvotes: 1

Views: 391

Answers (3)

torek
torek

Reputation: 488815

History is rarely a straight line

In your updated graph image, you have newer commits towards the top and older commits towards the bottom. Everything has been forced into a nice neat straight line. But this is a warped view of reality, in the same way that every view is warped. (We can introduce Einstein and relativity if needed, to prove this, but let's just take it as a given that we like to view things from where we sit / stand now, as opposed to where things were back when they were however they were and we didn't have today's perspective. Tomorrow or next year we'll have yet another perspective!)

Let's redraw this history a different way to make things clearer. We'll put older work on the left and newer work on the right and draw it in parallel, like this:

...--o--o---o
             \
              X--X--X   <-- master
             /
...--o---X--X   <-- feature/buggy
         ^
         |
  bug introduced

where X represents a commit with a bug. Note that the first buggy commit, on the bottom row, came after one of the good commits shown on the top row, then the second buggy commit came at the same time as (or even slightly before) the last good commit on the top row. The bug was obviously first introduced at the point I've marked.

Now, if we draw this linearized vertically with newer commits at the top, we get:

.
.
.
X   (still has bug introduced by merge)
X   (bug first introduced by merge)
o   (commit from the top row, not broken)
X   (bug in feature/buggy - commit from the bottom row)
X   (bug in feature/buggy)
o   (commit from the top row, not broken)
.
.
.

In the linearized view, the buggy commits are separated by good commits. In a "correct" (or at least less-distorted) view that looks at history one "leg" at a time, the buggy commits are all in a row.

The actual view you show, in the updated graphic, has a commit whose log message says Merge remote-tracking branch 'AWS/... (this gets cut off), but which is not a merge commit (a commit with two or more parents). This is the kind of merge made by git merge --squash, or—on some web interfaces—clicking a button labeled something like "squash and merge". These commits are made by using Git's merge machinery but do not record correct history.1 So in this case, the only way I know this is from harsh experience: I've seen this exact kind of problem before. The graphs I've drawn here show how things would look if the merge had been a regular merge, instead of a squash merge.

None of this is all that critical here, but someone in your organization should probably take some time and learn how Git works at a fine-grained level, to make finding and fixing bugs easier in the future.

1This is often intentional: the idea is to lie about the history to make future investigation easier, even in in fact it makes future investigation harder. How well this "squash" feature works depends on the skill and knowledge of those who use it. Anyone using it blindly is using it wrong, in the same sense that anyone who uses power tools without learning how to use them safely is using them wrong, even if they're accidentally using them right. 😀

Upvotes: 2

Khalil Khalaf
Khalil Khalaf

Reputation: 9407

Have you heard of git bisect?

This command when executed and followed, will pinpoint the exact one commit that introduced the bug.

Briefly, you start by executing the command and giving it a "starting point" (a commit SHA) that you know did NOT have the bug, then you give it an "ending point" (also a commit SHA) that you know DID have the bug, then git will do divide-&-conquer sort of process and will checkout versions for you, on each checkout, you test and see if the bug is there or not and you tell it to git (bad vs good), and git will continue the search based on your input. Finally, it will display the commit that introduced the bug.

Worth a try and is easy (and super fun) to do.

Upvotes: 1

Tim Biegeleisen
Tim Biegeleisen

Reputation: 521794

I will comment on what the following text actually means:

Showing 0 changed files with 0 additions and 0 deletions

This just means that the bottom (second) commit doesn't have any changes versus the commit which came before it. So, if checking out this commit resolves the bug, it doesn't necessarily mean that the commit is what introduced the changes to fix it. Rather, some earlier commit is responsible. For a diagram, consider:

A -- B -- C

The bug was introduced in commit C, but was not present in commit A. Since commit B was effectively a no-op, it too also does not have the bug present.

Upvotes: 2

Related Questions