[packetlost]

> "If I split a file in two I still want to be able to see blame correctly for the author of the function, not one file as freshly created and the other with a bunch of deletes." > > Now this is a good idea that I've never seen in a VCS.

There's a reason no one has done that, the VCS would have to have a semantic understanding of what it's tracking. I'm sure that's possible, but I think would see extremely limited success. Honestly, it may have even been done for proprietary languages and VCS systems that have since faded into obscurity.

I'd settle for searching the git history for a particular regex/string and then running a blame on that.

[mamcx]

The other way is to make the tool UX do the semantic, ie:

`git split`

Something that I enjoy with jujutsu is that the semantics is the tool itself. ONCE you do that, the rest become easier!

[Pet_Ant]

1) An “easy” way to implement this would be to treat the original file as the parent to both files. You can add a new command “split” if needed to mark the new file as a fork of the existing file.

2) language sensitive version control seems like the next thing. We need like an LSP for VCSes.

[tlb]

git actually does this. `git diff --find-copies`

[Pet_Ant]

If I run blame on the new file the will I see the commits made by the original writers? Will it find the same code if it was written independently? It’s not about find copies it about recording changes to a code base as an artifact and not to files. The closest git has is limited rename support.

[tlb]

Yes, if you run `git blame -C`.