Commit history not appearing by running "git log"

Question

This is in reference to a question asked in git-commit-history-lost and the suggestions made has helped me in resolving the issue where one of the commit was not appearing in local but in the bitbucket , that commit was appearing

I followed the suggestion and was able to pull the commit history with the missing commit info in the local.

I would like to ask what has happened that commit is not appearing while running the command git log in the local ?

Also would be interested to know what this command git log --follow -p -- <file name>is performing.

How can we avoid such issues in future so that we can get each and every commit history by running git log

Answer 1

If you want to view the remote logs, first local needs to have a copy of the remote index. Do a git fetch this will help git understand what needs to be updated in local with respect to remote.

Now do a git log --all This shows all the logs on all branches.

NOTE: If you did not do a git fetch your local machine won't know what was updated in the remote branches.

git log only shows current local branch updates.

git log does not check, what is on the remote repository.

But git log --all shows all branches commit history.

To understand what are local and remote branches git bash differentiates all the green colored as local branches and red colored as remote branches, it may change for other bash terminals.

Answer 2

The man page (or git documentation) is your friend :

    --follow
        Continue listing the history of a file beyond renames (works only for a single file).

    -p, -u, --patch
        Generate patch (see section on generating patches).

So most likely, if you're positively sure that the commit is on the branch you were browsing and that it wasn't downstream, that is located AFTER the point you started to browse the branch (which can happen if you're in detached mode, checking out a particular commit at a given time), you file were once renamed, or deleted/recreated later.

Git works with "snapshots", which means that each time you commit, git actually stores the complete state of your working directory, independently of every other commit, even the parent one. It does by storing the complete file list into a tree object, which in turn points at objects containing file contents (these objects happening to be the same on every commit if they don't change, so no duplicated data is stored implying no waste of space).

This enables Git to be very efficient at comparing things, making the differentiation of two random commits really easy, even if they're totally unrelated. In fact, git just don't have to remember the event's history. The branches are materialized by the fact that each commit references its own parent(s), just like a linked list.

The drawback of this is that the correlation between two versions of a single given file is based on its filename. If this filename changes, this breaks the lineage of its own history.

Fortunately, git is aware of this and is provided with many heuristics that let it fall back on its feets. For instance, if it detects, within a single commit, both a file deletion and the spawning of a new file having the exact same content, then git will assume it's a file renaming, even if the user actually has really deleted then recreated the file. Anyway, regardless of git and on the strict filesystem point of view, both these operations would have been totally equivalent (we don't care about inodes or such).

If you do that with regular shell commands, Git will able to handle this but it's always a good idea to use git specific commands for this, such as :

git mv <oldfilename> <newfilename>

… because it gives it a chance to supply additional information if it thinks that some clues will get lost in this operation. Otherwise, all of this remains limited. Let's assume you've deleted a file, then recreated TWO other files having the same content, then nothing tells Git which is the renamed file and which is the new one.

Anyway, when facing this situation, you can explicitly ask to monitor these changes and automatically following the file state if it can, proceeding in history browsing. But as stated in the documentation, it therefore can follow only one file at a time.