What I want from a version system is to capture event in history not like changes as a files but as events that capture a process.

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. I wish commits could be folded into larger commits so that you can still capture the individual changes but also not see them by default when looking at the history of a file.

Just a more human centric perspective on change history where it captures the way we talk and think about changes.

▲

WolfeReader a day ago | parent [-]

"I wish commits could be folded into larger commits so that you can still capture the individual changes but also not see them by default when looking at the history of a file."

Fossil merges do this. More people need to use Fossil; it's got a ton of great ideas.

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

▲

packetlost a day ago | parent [-]

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

▲

Pet_Ant a day ago | parent | next [-]

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.

▲

mamcx a day ago | parent | prev | next [-]

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!

▲

tlb a day ago | parent | prev [-]

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

▲

Pet_Ant a day ago | parent [-]

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 a day ago | parent [-]

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

	▲	WolfeReader a day ago \| parent [-]
		I legit did not know this. Thanks!