Re: BUG ? git-log omits changesets if the file is identical between revs

Darren Hart <dvhltc@us.ibm.com> writes:

This is expected, and it is by design.

$ git log --oneline --simplify-merges --full-history --graph \
  v2.6.33.5..v2.6.33.5-rt23 -- arch/powerpc/kernel/entry_64.S

will give you a less simplified history. The first commit we find in its output is:

* ef4afcc Merge stable/linux-2.6.33.y into rt/2.6.33

and if you look at that commit:

$ git show --pretty=short --stat -m ef4afcc -- arch/powerpc/kernel/

you will notice that:

 - ef4afcc is a merge between ac43be5 and a00123d;

 - arch/powerpc/kernel/entry_64.S has not changed between a00123d and this
   merge result ef4afcc;

 - There are many changes made to this path in the history leading to the
   other parent of the merge, ac43be5.

 - When Thomas created ef4afcc, after looking at ac43be5 and a00123d, he
   took the version from a00123d.  Effectively, what happend on the side
   branch that led to ac43be5 did _not_ contribute to the end result at
   all.

 - There was no change to the path between v2.6.33.5 and a00123d (as they
   are the same commit ;-).

 - Hence there is nothing noteworthy to report when explaining how the
   path came about since v2.6.33.5 and v2.6.33.5-rt23.

BTW, this has nothing to do with the path being the same between your HEAD and v2.6.33.5. You can try:

  $ git checkout v2.6.33.5-rt23
  $ echo >>arch/powerpc/kernel/entry_64.S
  $ git commit -m 'random change' arch/powerpc/kernel/entry_64.S
  $ git log --oneline v2.6.33.5.. -- arch/powerpc/kernel/entry_64.S
  b736245 random change

and notice that the change you just made is the only one that is needed to explain how the file came into its current shape since the named bottom version (v2.6.33.5).

If you look for "history simplification" in the list archive you will find Linus explaining why this simplification is the right thing to do number of times, but the short version is that "git log $path" by default gives you _one_ possible and simplest explanation of how the $path came about into its current shape, and "one possible and simplest" is what you want most of the time, because "all possible explanations" is very expensive to compute and often unreadable.

But the "--simplify-merges --full-history" trick I showed above may also be another good thing to know.