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

Re: Google Summer of Code 2009: GIT

From
Junio C Hamano <gitster@pobox.com>
Date
Mar 12, 2009, 20:18 UTC
Message-ID
<7vmybqjxzy.fsf@gitster.siamese.dyndns.org>
In-Reply-To
<alpine.DEB.1.10.0903121214390.16753@asgard.lang.hm>
david@lang.hm writes:
Show 12 quoted lines
> defining terminology that was mentioned before
>
> merge drivers are run by git to do the merges and create the conflict
> markers. git already has a 'plug-in architecture' for these drivers
> (you can define file types and tell git to use a particular merge
> driver for this file type)
>
> merge helpers are run by the users if there is a conflict and make use
> of the markers. depending on what you end up using for conflict
> markers, you may not need to write a merge helper (for OO, if your
> conflict markers are good enough you can use OO to resolve conflicts
> easily, no need for a new tool)

Not really. A merge helper can look at the stages in the index to get the (original, ours, theirs) tuple and start to work from there (and doing a helper as a backend of mergetool will be one way to make it easier), and for such helper the driver does not have to do anything.

> with this terminology, you can't do merge helpers without doing the
> merge drivers first (what does the helper look for as an indicator of
> a conflict?)

The answer to that question is "the index", and your "you can't" is too strong.

I agree with you that the original "editor" for the specific type of document (e.g. OOo, inkskape, ...) can be used to fix things up if a driver can leave conflict markers in such a way that the helper does not have to do three-file merge, and that would be a nice thing to have. But for a helper that can do a real three-file merge (and in this thread I think somebody said OOo can do that), then it is Ok for a driver to punt.

But even then, *if* there is a driver *and* it can do trivial merges cleanly and safely, it would be a huge productivity win, as you do not have to run a helper every time you see two branching touching the same document even they did so to edit totally unrelated parts of it.

Previous: saurabh guptaNext: saurabh gupta
Message 75 of 76 in “Google Summer of Code 2009: GIT”
  1. Saurabh GuptaMar 11, 2009
  2. Daniel BarkalowMar 11, 2009
  3. David SymondsMar 11, 2009
  4. saurabh guptaMar 11, 2009
  5. Johannes SchindelinMar 11, 2009
  6. David SymondsMar 11, 2009
  7. Johannes SchindelinMar 11, 2009
  8. Johannes SchindelinMar 11, 2009
  9. saurabh guptaMar 11, 2009
  10. Johannes SchindelinMar 11, 2009
  11. saurabh guptaMar 11, 2009
  12. Johannes SchindelinMar 11, 2009
  13. saurabh guptaMar 11, 2009
  14. Rogan DawesMar 11, 2009
  15. saurabh guptaMar 11, 2009
  16. Johannes SchindelinMar 11, 2009
  17. saurabh guptaMar 11, 2009
  18. Daniel BarkalowMar 11, 2009
  19. Johannes SchindelinMar 11, 2009
  20. Michael J GruberMar 12, 2009
  21. Johannes SchindelinMar 12, 2009
  22. Michael J GruberMar 12, 2009
  23. david@lang.hmMar 12, 2009
  24. saurabh guptaMar 11, 2009
  25. Michael J GruberMar 12, 2009
  26. david@lang.hmMar 11, 2009
  27. Johannes SchindelinMar 11, 2009
  28. david@lang.hmMar 11, 2009
  29. Johannes SchindelinMar 11, 2009
  30. saurabh guptaMar 11, 2009
  31. david@lang.hmMar 11, 2009
  32. saurabh guptaMar 11, 2009
  33. david@lang.hmMar 11, 2009
  34. Johannes SchindelinMar 11, 2009
  35. david@lang.hmMar 11, 2009
  36. Junio C HamanoMar 11, 2009
  37. thestar@fussycoder.id.auMar 12, 2009
  38. Junio C HamanoMar 12, 2009
  39. saurabh guptaMar 12, 2009
  40. david@lang.hmMar 12, 2009
  41. Junio C HamanoMar 12, 2009
  42. saurabh guptaMar 12, 2009
  43. david@lang.hmMar 12, 2009
  44. saurabh guptaMar 12, 2009
  45. Rogan DawesMar 13, 2009
  46. saurabh guptaMar 13, 2009
  47. Junio C HamanoMar 11, 2009
  48. saurabh guptaMar 11, 2009
  49. david@lang.hmMar 12, 2009
  50. saurabh guptaMar 12, 2009
  51. david@lang.hmMar 12, 2009
  52. saurabh guptaMar 12, 2009
  53. david@lang.hmMar 12, 2009
  54. saurabh guptaMar 12, 2009
  55. david@lang.hmMar 12, 2009
  56. saurabh guptaMar 13, 2009
  57. Johannes SchindelinMar 18, 2009
  58. david@lang.hmMar 18, 2009
  59. Johannes SchindelinMar 19, 2009
  60. david@lang.hmMar 19, 2009
  61. Johannes SchindelinMar 19, 2009
  62. david@lang.hmMar 19, 2009
  63. saurabh guptaMar 19, 2009
  64. Caleb CushingMar 19, 2009
  65. Johannes SchindelinMar 19, 2009
  66. Caleb CushingMar 21, 2009
  67. saurabh guptaMar 19, 2009
  68. Johannes SchindelinMar 19, 2009
  69. david@lang.hmMar 20, 2009
  70. Johannes SchindelinMar 20, 2009
  71. david@lang.hmMar 20, 2009
  72. Johannes SchindelinMar 20, 2009
  73. david@lang.hmMar 20, 2009
  74. saurabh guptaMar 21, 2009
  75. Junio C HamanoMar 12, 2009
  76. saurabh guptaMar 21, 2009

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.