Re: [PATCH] log: use true parents for diff even when rewriting

Junio C Hamano [off-list ref] writes:

Thomas Rast [off-list ref] writes:

quoted

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.

quoted

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

Hello Thomas,

On Tue, Jul 23, 2013 at 09:27:06AM +0200, Thomas Rast wrote:

Junio C Hamano [off-list ref] writes:

quoted

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.

the merge is only included in the output if on both parent paths the
file is touched. So this is a non-issue, isn't it? (Well, only if it has
more than 2 parents and not all ancestor paths touch the file, the
number of parents shown is changed.)

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |