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).
