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

Re: [PATCH 1/2] Check order when reading index

From
Jaime Soriano Pastor <jsorianopastor@gmail.com>
Date
Aug 26, 2014, 12:08 UTC
Message-ID
<CAPuZ2NHafXQthtuq-RnTvpjVfNPaXHEy8SejuhPEnG+MwCK=sg@mail.gmail.com>
In-Reply-To
<CAPc5daW-ZckFfhyueNLnPaBeriAmCUVJjFc1cw0O5iRi8F+Kng@mail.gmail.com>
On Mon, Aug 25, 2014 at 10:52 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 13 quoted lines
> On Mon, Aug 25, 2014 at 12:44 PM, Jeff King <peff@peff.net> wrote:
>> For my own curiosity, how do you get into this situation, and what does
>> it mean to have multiple stage#1 entries for the same path? What would
>> "git cat-file :1:path" output?
>
> That is how we natively (read: not with the funky "virtual" stuff
> merge-recursive does) express a merge with multiple merge bases.
> You also should be able to read this in the way how "git merge" invokes
> merge strategies (one or more bases, double-dash and then current
> HEAD and the other branches). I think there are some tests in 3way
> merge tests that checks what should happen when our HEAD matches
> one of the stage #1 while their branch matches a different one of the
> stage #1, too.

I'm a bit lost with this, conceptually it doesn't seem to be any problem with having multiple merge bases, but I don't manage to reproduce it. With "natively" do you mean some internal state that is never written into the index? If this were the case then there wouldn't be any problem with the restriction when reading the index file.

I have also tried to reproduce it by directly calling git-merge-recursive and the most I have got is what it seemed to be like a conflict in the stage #1:

$ git ls-files -s 100644 1036ba5101378f06aa10c5fa249b67e14f83166b 1 conflict 100644 2638c45f8e7bc5b56f70e92390153572811782c3 2 conflict 100644 178481050188cf00d7d9cd5a11e43ab8fab9294f 3 conflict

$ git cat-file blob 1036ba5101378f06aa10c5fa249b67e14f83166b <<<<<<< Temporary merge branch 1 G ======= E F

>>>>>>> Temporary merge branch 2

And after thinking a bit more about it, I don't see a way to have two stage #1 entries for the same path with git commands only. It seems that all entries are added through the add_index_entry_with_check() function (except maybe the added to the cached tree extension), and this function replaces existing entries if they have the same name and stage. Also, all tests pass with the patch, without allowing two entries for the same stage.

So I'm afraid that I don't fully understand this case :/
Previous: Junio C HamanoNext: Jeff King
Message 34 of 51 in “read-cache.c: Ensure unmerged entries are removed”
  1. read-cache.c: Ensure unmerged entries are removedJaime Soriano Pastor, Aug 12, 2014
  2. read-cache.c: Ensure unmerged entries are removedJaime Soriano Pastor, Aug 12, 2014
  3. Junio C HamanoAug 12, 2014
  4. Jaime Soriano PastorAug 13, 2014
  5. Junio C HamanoAug 13, 2014
  6. Jaime Soriano PastorAug 15, 2014
  7. Junio C HamanoAug 15, 2014
  8. Jaime Soriano PastorAug 16, 2014
  9. Junio C HamanoAug 18, 2014
  10. Jaime Soriano PastorAug 18, 2014
  11. 0/4 Handling unmerged files with merged entriesJaime Soriano Pastor, Aug 20, 2014
  12. 1/4 read_index_unmerged doesn't loop forever if merged stage exists for unmerged fileJaime Soriano Pastor, Aug 20, 2014
  13. 2/4 Error out when adding a file with merged and unmerged entriesJaime Soriano Pastor, Aug 20, 2014
  14. 3/4 Added tests for the case of merged and unmerged entries for the same fileJaime Soriano Pastor, Aug 20, 2014
  15. Junio C HamanoAug 20, 2014
  16. Jaime Soriano PastorAug 21, 2014
  17. Junio C HamanoAug 21, 2014
  18. 4/4 git update-index --cacheinfo can be used to select a stage when there are merged and unmerged entriesJaime Soriano Pastor, Aug 20, 2014
  19. Junio C HamanoAug 20, 2014
  20. Jaime Soriano PastorAug 21, 2014
  21. Junio C HamanoAug 20, 2014
  22. Jaime Soriano PastorAug 21, 2014
  23. Check order when reading indexJaime Soriano Pastor, Aug 21, 2014
  24. Jaime Soriano PastorAug 21, 2014
  25. Duy NguyenAug 21, 2014
  26. Junio C HamanoAug 21, 2014
  27. 1/2 Check order when reading indexJaime Soriano Pastor, Aug 24, 2014
  28. 2/2 Loop index increases monotonically when reading unmerged entriesJaime Soriano Pastor, Aug 24, 2014
  29. Jaime Soriano PastorAug 24, 2014
  30. Junio C HamanoAug 25, 2014
  31. Junio C HamanoAug 25, 2014
  32. Jeff KingAug 25, 2014
  33. Junio C HamanoAug 25, 2014
  34. Jaime Soriano PastorAug 26, 2014
  35. Jeff KingAug 26, 2014
  36. Junio C HamanoAug 26, 2014
  37. Jaime Soriano PastorAug 26, 2014
  38. Junio C HamanoAug 26, 2014
  39. 1/2 read_index_from(): catch out of order entries when reading an index fileJaime Soriano Pastor, Aug 27, 2014
  40. 2/2 read_index_unmerged(): remove unnecessary loop index adjustmentJaime Soriano Pastor, Aug 27, 2014
  41. Eric SunshineAug 29, 2014
  42. read_index_from(): catch out of order entries when reading an index fileJaime Soriano Pastor, Aug 29, 2014
  43. Junio C HamanoAug 29, 2014
  44. Jaime Soriano PastorAug 27, 2014
  45. Junio C HamanoAug 27, 2014
  46. Jaime Soriano PastorAug 27, 2014
  47. Jaime Soriano PastorAug 25, 2014
  48. Johannes SixtAug 21, 2014
  49. Junio C HamanoAug 21, 2014
  50. Junio C HamanoAug 12, 2014
  51. Jaime Soriano PastorAug 13, 2014

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.