git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Darren Hart <dvhltc@us.ibm.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, u.kleine-koenig@pengutronix.de, "Hansen\,
	Dave" <haveblue@us.ibm.com>, Will Schmidt <willschm@us.ibm.com>
Subject: Re: BUG ? git-log omits changesets if the file is identical between revs
Date: Fri, 02 Jul 2010 16:24:32 -0700	[thread overview]
Message-ID: <4C2E7530.3080603@us.ibm.com> (raw)
In-Reply-To: <7vocepzga3.fsf@alter.siamese.dyndns.org>

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

      reply	other threads:[~2010-07-02 23:24 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-02 18:50 BUG ? git-log omits changesets if the file is identical between revs Darren Hart
2010-07-02 22:10 ` Junio C Hamano
2010-07-02 23:24   ` Darren Hart [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4C2E7530.3080603@us.ibm.com \
    --to=dvhltc@us.ibm.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=haveblue@us.ibm.com \
    --cc=u.kleine-koenig@pengutronix.de \
    --cc=willschm@us.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).