Re: [PATCH v7 0/5] git log -L, all new and shiny

Junio C Hamano [off-list ref] writes:

Junio C Hamano [off-list ref] writes:

quoted

Thomas Rast [off-list ref] writes:

quoted

This would be the first backwards coupling between the revision-walk and
the diff generation parts, at least that I know of.

I am not convinced if you need to have any unusual back-coupling to
begin with, by the way.

If you say "git log -p [--options] -- pathspec", the revision
machinery does filter commits that do not touch any paths that patch
pathspec with the TREESAME logic, but that does not necessarily mean
you will see _all_ the commits that are not TREESAME.

[...]

The revision machinery looks at C and finds its parent B.  It runs
object level tree comparison and finds that their trees are
different at path F.  It makes a mental note that it may need to
show the log message of C, and asks the diff machinery to run
diff-tree between B and C.  The diff machinery finds that it needs
to show something even in the presense of -w option by actual
comparison, and just before showing the very first line of patch
output, it shows the log message of C (due to the earlier "mental
note").

Then the revision machinery looks at B.  It does the same between B
and A, but this time around, the diff machinery finds that, even
though A and B were _not_ TREESAME at the revision traversal level,
there is nothing to be shown after filtering with the -w option.
Hence no patch is shown and log message for B is not shown, either.

Thanks for the great explanations.

Having spent some time letting this sink in (and being busy doing other
things), I think it's actually a good idea.  It forces us to go back and
change it around so that the diff machinery gets a say _before_ we
simplify history.  I think this bit will be important for log -L history
to make sense, and it's a bug waiting to happen for the -w case.

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