git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v6] Add new git-related helper to contrib

From
Junio C Hamano <gitster@pobox.com>
Date
May 23, 2013, 21:52 UTC
Message-ID
<7vppwhcqjq.fsf@alter.siamese.dyndns.org>
In-Reply-To
<CAMP44s0X-79Pn4gq_rqBbti-xUobyYDc8Gy-3-g=sq8siZqq8g@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
Show 6 quoted lines
>> 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.

Previous: Felipe ContrerasNext: Felipe Contreras
Message 18 of 27 in “Add new git-related helper to contrib”
  1. Add new git-related helper to contribFelipe Contreras, May 19, 2013
  2. Eric SunshineMay 20, 2013
  3. Junio C HamanoMay 22, 2013
  4. Junio C HamanoMay 22, 2013
  5. Felipe ContrerasMay 22, 2013
  6. Junio C HamanoMay 22, 2013
  7. Felipe ContrerasMay 22, 2013
  8. Junio C HamanoMay 22, 2013
  9. Junio C HamanoMay 22, 2013
  10. Junio C HamanoMay 22, 2013
  11. Felipe ContrerasMay 22, 2013
  12. Junio C HamanoMay 23, 2013
  13. Felipe ContrerasMay 23, 2013
  14. Felipe ContrerasMay 23, 2013
  15. Junio C HamanoMay 23, 2013
  16. Junio C HamanoMay 23, 2013
  17. Felipe ContrerasMay 23, 2013
  18. Junio C HamanoMay 23, 2013
  19. Felipe ContrerasMay 23, 2013
  20. Junio C HamanoMay 23, 2013
  21. Felipe ContrerasMay 23, 2013
  22. Junio C HamanoMay 23, 2013
  23. Felipe ContrerasMay 24, 2013
  24. Felipe ContrerasMay 23, 2013
  25. Felipe ContrerasMay 23, 2013
  26. Junio C HamanoMay 23, 2013
  27. Felipe ContrerasMay 22, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.