Re: git log --follow doesn't follow a rename over a merge

[James Blackburn <jamesblackburn@gmail.com>]

On 16 June 2011 20:36, Junio C Hamano <gitster@pobox.com> wrote:
> James Blackburn <jamesblackburn@gmail.com> writes:
>
>> Given the file was removed during my 'merge' graft in commit X,
>> shouldn't it be visible  in log without --simplify-merges?
>
> The merge simplification logic does not treat earlier parent commits any
> differently than later parent commits of a merge (except when two parents
> are the same with respect to a given pathspec, and if the logic needs to
> pick only one, the earlier parent will be picked), and that is by design.
>
> So the short answer is no.

I think this is quite tough to grok.  Git blame shows me a path, and
git log -- <path> returns no output in the simple example I gave.

In this case --simplify-merges gives me a complete log for the path,
but man git-log tells me it should do the opposite:
       --simplify-merges
           Additional option to --full-history to remove some needless
merges from the resulting history, as there are
           no selected commits contributing to this merge.

I'm not sure how I would have figured out this switch might be just
the trick to show the commits that touched this path, without your
input.

As a naive user I expected:
  git log -- four
to tell we which commits changed the path 'four'. Especially those
commits which are reachable from my current HEAD.  I don't really
understand why one branch of history is worth following over another,
especially as the branch chosen, the older one, doesn't contain 'four'
at all.

Cheers,
James