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

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

[Darren Hart]

Looking at the linux-tip git tree, I was having trouble understanding
the following results while trying to track down a kernel bug:

URL: git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-tip.git

$ git checkout -b 2.6.33.5-rt23 v2.6.33.5-rt23
$ git log --pretty=oneline v2.6.33.5.. arch/powerpc/kernel
ef4afcc4401e92982f4ffd3fae6a9a6745a98596 Merge stable/linux-2.6.33.y into rt/2.6.33
1540c84b5ed657ed71dce06915bba461e6b09574 Merge branch '2.6.33.4' into rt/2.6.33
ac4d7f0bed9b03204539de81c8b62b35c9f4e16a Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git
6aa4659865454a3885195aa49348c46a69e6bee2 powerpc: rtasd: do not check for irq_disabled on RT
5f854cfc024622e4aae14d7cf422f6ff86278688 Forward to 2.6.33-rc8
5a017e25b44f6e66b0254c84270c0f1bf8689ebe Merge commit 'v2.6.31' into rt/head
570f410b475b45462197d09ddca25e47616da5ac Merge branch 'rt/base' into rt/rt-2.6.31
bda9263432072d7879fe13fdaf9dbbd372b4d2fc Merge branch 'linus' into rt/base
92bfe2d63ed46764b0b0a6e9b63bb9e81023ab80 powerpc: realtime support
e7e7fcb92fc6ef2cdb8cc070e9c0d26f03f7b8eb powerpc: mmu gather and tlb fixes
b4f4919b32aeadc6e0c1a0bc996e541073e0bcf7 powerpc: kprobes: Fix missed preemption check
5b659531c96943c3eea21b3dbcb83e6320d0f46b powerpc: OF convert to atomic lock
32ff9169c2f6c94c900f08217359972e2f3eb17f powerpc: Annotate atomic_locks
5a950072e4c1036abcdb35610d053e49bdde55c9 xtime_lock: Convert to atomic_seqlock
fd2bde5dd1689cc8ede833604cc19d1c835faf61 genirq: Convert irqdesc lock to atomic_spinlock

This lists the following change of interest:
92bfe2d63ed46764b0b0a6e9b63bb9e81023ab80 powerpc: realtime support

$ git whatchanged 92bfe2d6 -n1
commit 92bfe2d63ed46764b0b0a6e9b63bb9e81023ab80
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Fri Jul 3 08:44:51 2009 -0500

    powerpc: realtime support
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

:100644 100644 d00131c... 0b46b68... M  arch/powerpc/Kconfig
:100644 100644 43e0734... 4bb9ce4... M  arch/powerpc/kernel/entry_64.S
:100644 100644 88d9c1d... 1a82d48... M  arch/powerpc/kernel/idle.c
:100644 100644 054dfe5... 8f1d8cd... M  arch/powerpc/platforms/chrp/time.c
:100644 100644 e1f33a8... db7cf0d... M  arch/powerpc/xmon/xmon.c

Note that this change modified arch/powerpc/kernel/entry_64.S. However,
if we log the changes to that single file with same revision range as
for the parent directory above, we get an empty result set:

$ git log --pretty=oneline v2.6.33.5.. arch/powerpc/kernel/entry_64.S
<null>

Is this perhaps because entry_64.S is now identical between v2.6.33.5
and v.2.6.33.5-rt23?

$ git diff v2.6.33.5.. arch/powerpc/kernel/entry_64.S
<null>

If so, is this perhaps a bug? It seems like 92bfe2d6 should show up in
the log regardless...

I'm not sure of the significance, but another point of reference, using
the ... rev syntax yields:
$ git log --pretty=oneline v2.6.33.5... arch/powerpc/kernel/entry_64.S
92bfe2d63ed46764b0b0a6e9b63bb9e81023ab80 powerpc: realtime support

If this is all expected behavior, could someone please explain why it is
so?

Regards,

-- 
Darren Hart
IBM Linux Technology Center
Real-Time Linux Team

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

[Junio C Hamano]

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

> $ git checkout -b 2.6.33.5-rt23 v2.6.33.5-rt23
> $ git log --pretty=oneline v2.6.33.5.. arch/powerpc/kernel
> ef4afcc4401e92982f4ffd3fae6a9a6745a98596 Merge stable/linux-2.6.33.y into rt/2.6.33
> ...
> 92bfe2d63ed46764b0b0a6e9b63bb9e81023ab80 powerpc: realtime support
> ...
> $ git whatchanged 92bfe2d6 -n1
> commit 92bfe2d63ed46764b0b0a6e9b63bb9e81023ab80
> ...
> :100644 100644 43e0734... 4bb9ce4... M  arch/powerpc/kernel/entry_64.S
> ...
> $ git log --pretty=oneline v2.6.33.5.. arch/powerpc/kernel/entry_64.S
> <null>

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.

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

[Darren Hart]

Junio,

Thank you for the detailed explanation of what is apparently a common 
question - which I just didn't know how to phrase to find the previous 
discussions on simplified history.

Thanks,

Darren

On 07/02/2010 03:10 PM, Junio C Hamano wrote:
> Darren Hart<dvhltc@us.ibm.com>  writes:
>
>> $ git checkout -b 2.6.33.5-rt23 v2.6.33.5-rt23
>> $ git log --pretty=oneline v2.6.33.5.. arch/powerpc/kernel
>> ef4afcc4401e92982f4ffd3fae6a9a6745a98596 Merge stable/linux-2.6.33.y into rt/2.6.33
>> ...
>> 92bfe2d63ed46764b0b0a6e9b63bb9e81023ab80 powerpc: realtime support
>> ...
>> $ git whatchanged 92bfe2d6 -n1
>> commit 92bfe2d63ed46764b0b0a6e9b63bb9e81023ab80
>> ...
>> :100644 100644 43e0734... 4bb9ce4... M  arch/powerpc/kernel/entry_64.S
>> ...
>> $ git log --pretty=oneline v2.6.33.5.. arch/powerpc/kernel/entry_64.S
>> <null>
>
> 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.
>
>


-- 
Darren Hart
IBM Linux Technology Center
Real-Time Linux Team