On Wednesday 21 April 2010, Junio C Hamano wrote:
> 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.
Agreed.
> > 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,
The three trees you mention are (I assume) <base>, <ours> and <theirs>. What
if there is more than one merge-base? How do we re-use the recursive
strategy's "pre-merge" of merge-bases?
Next, we will need to be somewhat careful about using "ls-tree", to avoid
needlessly unpacking subtrees that are identical between <ours> and
<theirs>.
> 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 ;-).
I believe "git notes append" might not be suitable for all types of notes,
and that users would in some cases want to choose other strategies for
resolving conflicting notes. I'm currently planning to offer three fully
automatic resolvers: "ours", "theirs" and "union" (corresponding to the
_ignore, _overwrite and _concatenate combine_notes functions, respectively,
in notes.h).
> 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.
Ok, I'm just worried that it'll force us to re-implement much of the three-
way merge logic that's already implemented in the merge machinery.
> 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.
I agree that this is probably a better way to resolve conflicts in notes
(i.e. better than designing a way to semi-manually resolve conflicts without
a working tree).
We're then left with a few fully automatic conflict resolvers ("ours",
"theirs" and "union") which will always succeed (and therefore need no
special directory), and a "manual" resolver which sets up the special
directory as you describe above, and instructs the user to resolve the
merge, followed by 'git notes commit' to conclude the merge.
Thanks for the feedback. (BTW, I'm travelling next week, so don't expect any
immediate patches from me).
Have fun! :)
...Johan
--
Johan Herland, <johan@xxxxxxxxxxx>
www.herland.net
--
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