All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Rast <trast@inf.ethz.ch>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Subject: Re: [PATCH] log: use true parents for diff even when rewriting
Date: Tue, 23 Jul 2013 09:27:06 +0200	[thread overview]
Message-ID: <87k3khpwhh.fsf@linux-k42r.v.cablecom.net> (raw)
In-Reply-To: <7v61w2clli.fsf@alter.siamese.dyndns.org> (Junio C. Hamano's message of "Mon, 22 Jul 2013 14:48:25 -0700")

Junio C Hamano <gitster@pobox.com> writes:

> Thomas Rast <trast@inf.ethz.ch> writes:
>
>> When using pathspec filtering in combination with diff-based log
>> output, parent simplification happens before the diff is computed.
>> The diff is therefore against the *simplified* parents.
>>
>> This works okay, arguably by accident, in the normal case: the pruned
>> commits did not affect the paths being filtered, so the diff against
>> the prune-result is the same as against the diff against the true
>> parents.
>>
>> However, --full-diff breaks this guarantee, and indeed gives pretty
>> spectacular results when comparing the output of
>>
>>   git log --graph --stat ...
>>   git log --graph --full-diff --stat ...
>>
>> (--graph internally kicks in parent simplification, much like
>> --parents).

Hmm, I stopped writing the message midway through.  There should be
another two paragraphs here about storing the original parent list on
the side for later use when showing the diff.

>> Perhaps like this.  It's getting a bit late, so I'm not sure if I'm
>> missing another user of the "true" parent list, but it does fix the
>> issue you reported.
>
> Conceptually I can see how this will change the history
> simplification in the vertical direction (skipping the ancestry
> chain and jumping directly to the closest grandparent that touched
> the specified path), but I am not sure how well this interacts with
> history simplification in the horizontal direciton (culling
> irrelevant side branches from the merge).

But isn't that similarly confusing for the user as Uwe's original
problem?  Suddenly we'd be showing a merge commit as an ordinary one,
simply because the merged history did not affect the filtered
pathspecs.  Thus we would show everything that has been merged on the
*other* files as a big diff.  Would that be useful?  It would certainly
be a big difference in how the commit is shown.

> I also have to wonder if we always want to incur this save-parents
> overhead, or we are better off limiting it to only when --full-diff
> is in effect.

I haven't quite convinced myself that it is 100% safe to use the
rewritten parents when --full-diff is not in effect...

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

  reply	other threads:[~2013-07-23  7:27 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-22  9:08 git log anomalities Uwe Kleine-König
2013-07-22 10:40 ` Thomas Rast
2013-07-22 21:22 ` [PATCH] log: use true parents for diff even when rewriting Thomas Rast
2013-07-22 21:48   ` Junio C Hamano
2013-07-23  7:27     ` Thomas Rast [this message]
2013-07-23  7:49       ` Uwe Kleine-König
2013-07-23 19:55   ` Junio C Hamano
2013-07-31 20:13   ` [PATCH v2] " Thomas Rast
2013-07-31 22:55     ` Jeff King

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=87k3khpwhh.fsf@linux-k42r.v.cablecom.net \
    --to=trast@inf.ethz.ch \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=u.kleine-koenig@pengutronix.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.