This alone should already be a nice UI improvement: in the
fast-forward case, with this patch applied, in place of
git fetch . refs/notes/x:refs/notes/commits
one could write
git notes merge x
This reminds me: it would be nice if non-builtin scripts could use
git notes --get-notes-ref $refarg
to learn the configured notes ref. In other words, shouldn't the
default_notes_ref() exposed in patch 2 also be exposed to scripted
callers? If someone else doesn't get around to it, I can mock
something up in the next few days.
[...]
[...]
So the command is usable as-is from other builtins. Nice.
[...]
Should the verbosities be of enum type?
enum notes_merge_verbosity {
DEFAULT_VERBOSITY = 2,
MAX_VERBOSITY = 5,
etc
};
I would find it easier to read
if (o->verbosity >= DEFAULT_VERBOSITY)
fprintf(stderr, ...)
unless there are going to be a huge number of messages.
Would trace_printf be a good fit for messages like this one? If not,
any idea about how it could be made to fit some day?
(It is especially nice to be able to direct the trace somewhere other
than stdout and stderr when running tests.)
Can an empty ref be distinguished from a missing ref? It would be
nice to error out when breakage is detected.
[...]
With a recursive merge of the ancestors, of course. :)
The difficult part is what to do when a merge of ancestors results in
conflicts.
[...]
Maybe
o.verbosity += verbosity;
or
o.verbosity = DEFAULT_NOTES_MERGE_VERBOSITY + verbosity;
to allow the default verbosity to be set in one place?
Mm. In the long run, will (result != 0) mean "merge conflict"?
Thanks for a pleasant read.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html