Re: Current state / standard advice for rebasing merges without information loss/re-entry?

[Junio C Hamano <gitster@pobox.com>]

Philip Oakley <philipoakley@iee.email> writes:

> So, essentially, it's talking a small part of the rerere-train at each
> step in the replay, so that it's more focussed.

As rerere database is designed to be an O(1) hashtable, having
knowledge of how many other merge conflicts are to be resolved
shouldn't affect the time you need to find the relevant record
to use to help you resulve the conflict you currently see.

That reminds me of one topic.  I often wondered if it were a mistake
that I didn't make the rerere database easily transferrable across
repositories (just like "stash cannot be transport via fetch" which
is being worked on recently).  As long as a mergy history that will
need to be recreated later gets transferred to a new repository, it
can be used to "train" the rerere database in the new repository, so
it probably is a much lower priority.

"git rerere" command on the other hand may be in desperate need to
learn the "train" subcommand to officially support it (and deprecate
the "contrib/rerere-train.sh").  Especially given that we now can do
the necessary "trial merges" in core, without touching the working
tree or the index, thanks to the "ort" merge-backend.

The size of such a project may be appropriate for GSoC (if done the
same way as the script, smudging HEAD, index and the working tree),
or may exceed what is reasonable for GSoC (if done all in-core using
ort machinery).