# Is having \`replace\` a sensible idea?
**URL:** https://discourse.pijul.org/t/is-having-replace-a-sensible-idea/530
**Category:** Development
**Created:** [September 9, 2020, 8:32pm UTC](https://discourse.pijul.org/t/is-having-replace-a-sensible-idea/530 "2020-09-09T20:32:24Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@jeltsch](https://discourse.pijul.org/u/jeltsch)
#### Post date: [September 9, 2020, 8:32pm UTC](https://discourse.pijul.org/t/is-having-replace-a-sensible-idea/530/1 "2020-09-09T20:32:24Z")
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?
---
### Author:  [@nylen](https://discourse.pijul.org/u/nylen)
#### Post date: [September 9, 2020, 8:42pm UTC](https://discourse.pijul.org/t/is-having-replace-a-sensible-idea/530/2 "2020-09-09T20:42:43Z")
> [@jeltsch](#):
>
> My personal recommendation would be to not implement it.
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.
---
### Author:  [@joyously](https://discourse.pijul.org/u/joyously)
#### Post date: [September 10, 2020, 3:00pm UTC](https://discourse.pijul.org/t/is-having-replace-a-sensible-idea/530/3 "2020-09-10T15:00:34Z")
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.
---
### Author:  [@porky11](https://discourse.pijul.org/u/porky11)
#### Post date: [May 5, 2021, 4:07pm UTC](https://discourse.pijul.org/t/is-having-replace-a-sensible-idea/530/4 "2021-05-05T16:07:43Z")
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?
---
### Author:  [@pmeunier](https://discourse.pijul.org/u/pmeunier)
#### Post date: [May 5, 2021, 4:48pm UTC](https://discourse.pijul.org/t/is-having-replace-a-sensible-idea/530/5 "2021-05-05T16:48:08Z")
> [@porky11](#):
>
> What would be the benefit over running `sed` ?
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.