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

Re: Collaborative conflict resolution feature request

From
Chris Torek <chris.torek@gmail.com>
Date
Jun 16, 2020, 15:56 UTC
Message-ID
<CAPx1Gvf5R6b1NoUWHkaqLMaj6dr51hERVvuVe1X9k3NEafnBhg@mail.gmail.com>
In-Reply-To
<CAPx1GvdT6sZRtu8q1R9=fA-mE9pi1Ag-gKEzQfwbGap+KqSoSg@mail.gmail.com>
On Mon, Jun 15, 2020 at 10:32 AM Chris Torek <chris.torek@gmail.com> wrote:
> I've thought about this (some) myself in the past.  It seems to me that what
> is needed is the ability to pass the complete unmerged state on.
A few further thoughts:
 * Given one or more saved merges and either a clean state or an
   ongoing merge, we need a tool to combine these.  There are a lot of
   corner cases here but in general, if merge X has file F in conflict and
   merge Y has file F resolved, we can take the resolution from Y.
 * Partial merges (in the work-tree copy of a file) that are not yet added
   may be the trickiest.  A simple heuristic would be to look for the
   conflict markers and see if one work-tree copy has a resolution
   where another work-tree copy has a conflict.  Or, though this is
   harder, use the ours/theirs copies in the saved index trees to find
   actual conflicted regions and compare this to the work-tree copy
   to find resolved regions.
 * There is also an obvious question about what to do when combining
   two different proposed resolutions where the stage-zero and/or
   work-tree copies of the files don't match.

None of these preclude the basic ability to save and restore—and of course transport, through fetch/push—the unmerged state, which I think is the required enabling technology. The ideas above are more for combining parallel merge efforts. If it's acceptable for dev A to merge his/her part and pass the result to dev B, who merges theirs, and so on, the above is not required.

Chris
Previous: Chris TorekNext: Philip Oakley
Message 21 of 32 in “Collaborative conflict resolution feature request”
  1. Curtin, EricJun 12, 2020
  2. Johannes SixtJun 13, 2020
  3. Christian CouderJun 13, 2020
  4. Curtin, EricJun 13, 2020
  5. Philip OakleyJun 13, 2020
  6. Junio C HamanoJun 13, 2020
  7. Sergey OrganovJun 15, 2020
  8. Philip OakleyJun 15, 2020
  9. Stefan MochJun 16, 2020
  10. Curtin, EricJun 17, 2020
  11. Sergey OrganovJun 17, 2020
  12. Christian CouderJun 13, 2020
  13. Junio C HamanoJun 13, 2020
  14. Junio C HamanoJun 13, 2020
  15. Philip OakleyJun 14, 2020
  16. Konstantin TokarevJun 14, 2020
  17. Curtin, EricJun 15, 2020
  18. Philip OakleyJun 15, 2020
  19. Junio C HamanoJun 15, 2020
  20. Chris TorekJun 15, 2020
  21. Chris TorekJun 16, 2020
  22. Philip OakleyJun 15, 2020
  23. Junio C HamanoJun 17, 2020
  24. demerphqJun 18, 2020
  25. Curtin, EricJun 18, 2020
  26. Curtin, EricJun 18, 2020
  27. demerphqJun 18, 2020
  28. Curtin, EricJun 19, 2020
  29. Christian CouderJun 20, 2020
  30. Curtin, EricJun 21, 2020
  31. Christian CouderJun 16, 2020
  32. Sergey OrganovJun 15, 2020

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.