Add rename detection

[martinvonz]

We should use rename detection at least when diffing and merging.

The footnote on https://blog.palantir.com/optimizing-gits-merge-machinery-2-d81391b97878 has some information about how Git does it.

[dbarnett]

A few logistical questions:

1. Is rename tracking explicit metadata (like in mercurial) or implicit (like git)? Do we know yet?
2. Are there baby steps towards getting this working, like for example updating jj diff to notice renames but nothing else?
3. Do we anticipate big gotchas with how rename tracking interacts with other features, like how the semantics are shared to git and other backends or breaking how conflicts work in renamed files?

I ran into an especially ugly rename+edit case recently and got intensely interested in improving this. =) I'd wanted to use jj split to separate revisions for the pure rename from the subsequent edits and that did not go well...

[joyously]

Is rename tracking explicit metadata (like in mercurial) or implicit (like git)?

This question is confusing because Git doesn't deal with files (it has blobs), but it does have a mv command.
Bazaar(Breezy) also has a mv command, and it deals with renames better than Git.

[martinvonz]

We don't know yet if we're going to do rename tracking or rename detection. I'm leaning towards tracking, mostly because it seems like it would scale better. One interesting case that rename detection handles well when commit A adds file foo, commit B modifies it, and then you amend A with a rename from foo to bar (https://bz.mercurial-scm.org/show_bug.cgi?id=5457).

Also, if we want to track renames and also track content moves at the sub-file level (like git blame -C), then we would either have to track moved content at the sub-file level, or we'd have to somehow augment the file-level tracking information. It might be enough to track that "some content was moved out of file foo and into file bar" and then detect at query time exactly which content it was.

We should also keep in mind that diffing will hopefully get smarter in the future. In particular, I hope we'll start doing language-/AST-aware diffing and merging at some point. So we probably don't want to do any sub-file-level tracking of moved content, because we'll probably be able to detect exactly what moved in the future. Relevant message from Linus Torvalds: https://gist.github.com/borekb/3a548596ffd27ad6d948854751756a08

[martinvonz]

Is rename tracking explicit metadata (like in mercurial) or implicit (like git)?

This question is confusing because Git doesn't deal with files (it has blobs), but it does have a mv command. Bazaar(Breezy) also has a mv command, and it deals with renames better than Git.

Right, I think that's exactly what David is saying - that Git doesn't track renames. Mercurial does track renames.

[ChrisPenner]

The lack of any way to resolve conflicts where I've edited a file and I merge or rebase something which has renamed that file is a bit of a bummer at the moment;

I'd appreciate even a manual way to fix this, e.g. if I could edit the conflicted revision and somehow tell jj that the file isn't deleted it just moved.

Also, since the conflicts are a result of a rebase I can't do something like jj restore file.txt -r <rev> to remove the conflict markers so I can copy-paste, I have to manually go through and handle each changed line removing the +/- and re-indenting everything since I don't have any merge tools set up.

To compare the two, this would take me about 40mins using jj, when I switched back to git and rebased my branch there it succeeded without any conflicts at all; luckily jj figured out what I did in Git and going from there was relatively painless, so huge compliments there 🙌🏼

I don't get conflicts terribly often on my current project, but if I ended up with these even rarely it would be a dealbreaker for using jj for me.

Cheers!