On Thu, May 23, 2013 at 4:52 PM, Junio C Hamano <gits...@pobox.com> wrote:
> Felipe Contreras <felipe.contre...@gmail.com> writes:
>>> Imagine that your scoreboard originally has three blocks of text
>>> (i.e. blame_entry) A, B, and C, and the current suspect for A and C
>>> are the same, while we already know what the final guilty party for
>>> B is (which may be some descendant of the "suspect").
>> I don't see how that's possible, but whatever.
> The tree in your latest commit HEAD has a file with block of text A
> followed by block of text B followed by block of text C.  The latest
> commit was the one that added B (perhaps new lines were inserted, or
> perhaps existing contiguous block of text was replaced, there is no
> difference between these two cases).  You start digging the history
> of this file from HEAD.
> Your scoreboard begins with a single blame-entry that covers all
> three segments, with its suspect set to HEAD.  Then pass_blame()
> discovers that top and bottom segments are older than this latest
> commit, and splits the originally-one blame entry into three blame
> entries.  The first and the third blame entries cover the block A
> and the block C respectively, and their suspect fields are both set
> to HEAD^.  The second blame entry covers the block B and its suspect
> does not change (it still is HEAD).  Then it returns to the caller.
> The caller of pass_blame() looks at the scoreboard and finds these
> three blame entries.  The second one's supect is still the original
> suspect the caller asked pass_blame() to exonerate blames for, and
> the suspect failed to do so for block B.  The final blame for the
> middle block is now known to be HEAD.
> After all of the above, the next iteration of while(1) loop begins.
> That is how you arrive to the "whatever" situation.  You have three
> blame entries, A, B and C, and suspect of A and C are the same,
> while B has a different suspect.
> Then in that "next iteration", we pick blame entry for A and decide
> to see if HEAD^, which is the suspect for A, can be exonerated of
> blames for _any_ (not just A) blame entry it currently is suspected
> for.  We call pass_blame() and it will find and process both A and
> C with a single "git diff-tree", attempting to pass blame to HEAD^^
> and its ancestors.

All right, my code still works in that situation.

Felipe Contreras
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to