Hi Elijah, On Thu, 7 Jun 2018, Elijah Newren wrote: > am-based rebases suffer from an reduced ability to detect directory > renames upstream, which is fundamental to the fact that it throws away > information about the history: in particular, it dispenses with the > original commits involved by turning them into patches, and without the > knowledge of the original commits we cannot determine a proper merge base. > > The am-based rebase will proceed by first trying git-apply, and, only if > it fails, will try to reconstruct a provisional merge base using > build_fake_ancestor(). This fake ancestor will ONLY contain the files > modified in the patch; without the full list of files in the real merge > base, renames of any missing files cannot be detected. Directory rename > detection works by looking at individual file renames and deducing when a > full directory has been renamed. > > Trying to modify build_fake_ancestor() to instead create a merge base that > includes common file information by looking for a commit that contained > all the same blobs as the pre-image of the patch would require a very > expensive search through history, may find the wrong commit, and outside > of rebase may not find any commit that matches. > > But we had all the relevant information to start. So, instead of > attempting to fix am which just doesn't have the relevant information, > instead note its strength and weaknesses, and change the default rebase > machinery to interactive since it does not suffer from the same problems. I'll let Eric comment on the grammar, and I'll comment on the idea behind this commit instead. IMHO `git rebase -i` is still too slow to be a true replacement for `git rebase --am` for the cases where it serves the user well. Maybe we should work on making `rebase -i` faster, first? I imagine, for example, that it might make *tons* of sense to avoid writing out the index and worktree files all the time. That was necessary in the shell script version because if the ridiculous limitations we subjected ourselves to, such as: no object-oriented state worth mentioning, only string-based processing, etc. But we could now start to do everything in memory (*maybe* write out the new blob/tree/commit objects immediately, but maybe not) until the time when we either have succeeded in the rebase, or when there was a problem and we have to exit with an error. And only then write the files and the index. In any case, I think that the rather noticeable change of the default would probably necessitate a deprecation phase. Ciao, Dscho
