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
