Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

My main headache with git — which is absent from the list in the blog – is that it tracks snapshots instead of tracking changes. It's probably less of an issue for software developers where a "version" is what this all is about — after all, that's what you ship, but if you try to use version control in a context of academic writing or data analysis, it can become very difficult to track individual contributions. All git can do is to compare snapshots and allow you to impose a resemblance causal order onto them (which you can freely manipulate anyway with rebasing, squashing etc.). If your workflow consists of trying out many different ideas and then choosing which of them to keep and which to discard, git can be extremely painful — you either end up with a history that is a complete mess or waste a lot of time rebasing and reorganising the (fake anyway) order of snapshots.

That's why I am exited for tools like Pijul that attempt to actually track changes.



Snapshots do have the advantage of not having to know anything about the data.

Tracking changes necessarily needs to define a way to describe how things may change.

Perhaps another take on the issue is that changing data should be structured to be more snapshot friendly?


I'm one of the authors of Pijul, and I have plans to turn it into a synthesis of snapshots and patches, I've implemented the formats and initial steps, see https://pijul.org/posts/2022-01-07-compressed-sanakirja/

The formats are ready for the next steps, but since this is only useful for really massive repos, I want to wait a little bit before spending the time on these features. If more people start using it, it may provide the motivation needed.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: