From: James Blackburn <jamesblackburn@gmail.com>
Date: Thu, 16 Jun 2011 21:29:36 GMT
Subject: Re: git log --follow doesn't follow a rename over a merge
Message-ID: <BANLkTi=7yFdkNgvGX38JM_GbS7=tqf=1sQ@mail.gmail.com>
In-Reply-To: <7vlix1h8lz.fsf@alter.siamese.dyndns.org>

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