Re: Google Summer of Code 2009: GIT

Saurabh Gupta <saurabhgupta1403@gmail.com> writes:

The way "merge" works is:

 - A tree-level 3-way merge is done (either inside merge-recursive backend
   or with "read-tree -m O A B" inside merge-resolve), and trivial merges
   are resolved at the whole-file level without need for any helper.
   Roughly speaking, the definition of "a trivially mergeable path" is a
   path that only one side modified while the other side didn't, or both
   sides modified identically.

 - The remaining paths need to be merged at file level.  The gitattributes
   mechanism is used to decide what exact algorithm to use based on what
   the merged file is; we have a plain-text "xdl" merge driver and "union"
   merge driver built-in, in addition to "binary" merge driver (which
   always says "the changes conflict; use ours as a tentative result).

   When a merge driver is called, it is given three blobs: original, ours
   and theirs (any one of them could be missing).  It is the driver's
   responsibility to come up with an automated merge result when the
   changes do not overlap and report success, or leave an intermediate
   "conflicted merge" and report conflicts.  In either case, the driver is
   expected to return _one_ single bytestream as its tentative result.

 - Cleanly merged paths are updated in the index and their results are
   written out to the work tree.  For paths the merge drivers reported
   conflicts, tentative results returned by the merge drivers are written
   out to the work tree but the index entries for them are left in an
   unmerged state.

 - If all paths are cleanly merged, "git merge" and friends write the
   index out as a tree and create a commit out of it (unless otherwise
   instructed) and report success.

 - When a merge left conflicts, the user can use external tools like "git
   mergetool" to resolve the conflict in the work tree, starting from the
   tentative result given by the merge driver, and "git add" to register
   the resolution to the index.

When people say a "merge helper" in the context of git, I think they think about at least two kinds, that work at very different layers. It is unclear which one you are more interested in, or you are tackling both.

 - A group of new merge drivers that handle various structured text
   formats (e.g. XML based ones), on which the default plain-text merge is
   not suitable, would be a good addition to the git suite.  If you are
   interested in doing this as your GSoC project, it would very much be
   git specific.

 - Amerge helper that takes three files (original, ours and theirs) as its
   input and helps the end user (perhaps graphically) merge them can be
   used at a backend to the "git-mergetool", by registering a filetype as
   "binary" (so that the low-level merge driver won't even try merging the
   contents at the file level), and letting "git-mergetool" invoke the
   "helper" with these three files.  The development of this kind of
   "helper" would not be a git specific project.

Obviously it would help the users to have both, but which kind is more important?

In a collaborative environment, people do not work in void without any communication with each other, and they actively try not to step on each other's toes. Even when changes are made from both sides of a merge to the same file (in other words, a file level merge is required), in the majority of cases, the changes do not overlap, and being able to resolve such merges cleanly most of the time, without having to resort to an external "git mergetool", is a huge win in productivity. I think a domain specific "merge driver" project would benefit the git users a lot more than a domain specific "merge helper" that can be used as a "git mergetool" backend (and can also be used outside git).

Of course, you can do both.

But my point is it is unclear which one you meant when you said "merge helper".