Is having `replace` a sensible idea?

Development
1

I think, some time ago, there was a discussion about whether Pijul should have an equivalent to darcs’s replace subcommand, which creates special patches for replacing tokens everywhere they occur. If I remember correctly, it was said that having such replacement patches would impose a performance penalty.

Has a replace subcommand been implemented meanwhile? If not, is it still planned to be implemented?

My personal recommendation would be to not implement it. I found the idea of patch types other than insertions and deletions interesting when reading about them years ago in the context of darcs. However, I never really found darcs replace useful, to the extend that I never ever used it. This was not least because changing a token is often accompanied by layout fixing and adding ordinary patches for fixing layout defeats the whole purpose of replacement patches.

Given that replace might not be very useful and additionally may spoil the performance of other commands, I guess it might be best to just not have it in Pijul. What do others think?

1 Like
2

Agree. A flat string replacement is almost never the correct approach to take when working with a codebase of any real-world size, and the additional complexity for both Pijul developers and users does not seem justified to me.

2 Likes
3

It seems to defeat the purpose of “version control”, but then maybe Pijul isn’t version control if it’s simply a way to store patches.
Someone mentioned being able to patch a patch, which replace sounds like.
I don’t have a mental model of what the purpose of such a thing is.

4

What would be the benefit over running sed?

Would you be able to merge two commits like these (based on the same version):

  1. renaming some specific function/class/etc. in multiple places
  2. using this function/class/etc. in a new file (not renamed yet)
    Would the new file be renamed automatically after merge?
5

From an academic point of view, the way Darcs does this is fun and elegant: replace commutes with future uses of the variable, meaning that future uses of the variable, from a remote, are replaced.

From a practical point of view, I’ve thought about ways to implement this. It seems possible, but involves a whole bunch of extra layers on top of Pijul, and can be implemented in the future with extra scripts and hooks, without changing the repository format (the patch format might not even need an extension, for what I have in mind).

From a usability point of view, I’m already scared of seeing Git handle my code (when merging and rebasing, for a single-author, single-branch project I trust it 100%), so having an automatic replacement script hanging over my code would scare me even more.