On GitHub, there are, essentially, two different ways to see the commit history of a repository:

From time to time, you may notice that these two commit views show different information. That is, the history for a single file may omit commits found on the repository's commit history.

In essence, Git has several different ways of showing the history of a repository. When Git shows the history of a single file, it "simplifies" history by omitting commits that did not change the file. But rather than look at every commit to decide whether it touched the file, git will omit a whole branch if that branch, when merged, did not impact the final contents of the file. Any commits on that branch that touched the file will not be shown.

For a file's commit history, GitHub explicitly follows this simple strategy, for two reasons:

  • It makes the history simpler by removing commits that did not actually contribute to the final result ( e.g., if a side branch made a change and then reverted it, or if a side branch contains a messy version of some changes that were cherry-picked and cleaned up)

  • It's significantly more efficient to compute, as we can avoid looking at whole side-branches of the history that did not impact the file

Of course, this truncated view might not always contain the information you're after. Sometimes, you do want to know about failed experiments, or messy history, or even be finding out what went wrong in a questionable merge. As mentioned above, Git does have many ways of viewing history, and GitHub provides a view with more information on a repository's commits page.

For more information on how Git considers commit history, you can read up on the "History Simplification" section of the git log help article.

Further reading