Johan Herland <johan@xxxxxxxxxxx> writes:
> For merges between notes refs with no common history the merge should be
> a straightforward joining of trees. This also covers the "history-less"
> notes refs, like Peff's notes-cache, and should work whether the notes
> refs point to parentless commits, or point directly to tree objects (if
> we want to support that). For merges between notes refs with common
> history we want to do a (more or less regular) three-way merge.
Note that a "history-less" merge is just a special three-way merge
pretending as if their common ancestor is an empty tree. There is no
point in special casing the former.
> In both cases (with or without common history), conflicts may ensue,
> and these must of course be resolved in some way. Since the notes refs
> have no accompanying worktree, we must find some other way to resolve
> conflicts.
I would say we may not even have to "resolve" the conflicts in the usual
sense of the word.
You can run "ls-tree" on three trees, removing '/' from the output to
obtain the list of objects that are annotated, and do a three-way merge at
the object level first. For the ones that do have diverging changes on
both sides, you just run "git notes append" to add the data from the other
side and be done with it ;-).
That way you don't have to worry about how "git merge" merges things, how
it uses the index, nor how it uses the working tree, as you won't be using
anything from "git merge" at all.
That would be the first step.
The second step would be to designate a special directory that would exist
only during a conflicted "notes merge" in $GIT_DIR, just like MERGE_HEAD
serves as the signal we are in a conflicted merge. When
$ git notes merge <other>
is run, if (and only if) you need a manual merge resolution, you would
create this directory, which will have:
- a temporary index that has the result of the tree level merge, but you
will:
(1) only register the entries that have conflicted; and
(2) flatten the fan-out structure.
- files that have conflicted merge result, whose names are 40-byte object
names that are annotated; and
- something like MERGE_HEAD to keep track of the <other>, so that you can
create a merge commit when concluding the merge.
You can chdir to the directory and use "git diff" and "git ls-files -u" to
inspect the conflicts, and run "git add <filename>" to mark a resolved
note.
You would need a separate command ("git notes commit" perhaps) to conclude
the merge. At that point, you would iterate over this temporary index
(which only has conflicted notes), pulling out the list of <object name
being annotated, the annotation>, add these annotates to produce a new
notes tree, record that tree as a merge commit in the notes namespace, and
finally remove the notes merge working directory.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html