[darcs-users] bug or inconsistency in darcs replace

David Roundy droundy at abridgegame.org
Sat Mar 27 17:34:58 UTC 2004

On Sat, Mar 27, 2004 at 09:21:17AM -0800, Kevin Smith wrote:
> David Roundy wrote:
> >I've thought about something like that.  I could do it by making darcs
> >automatically create "hunk" patches replacing the new token with the old
> >token before the replace, and queue those patches prior to the replace.
> >The problem is that this could be very confusing.  The queued changes
> >(which are stored in _darcs/patches/pending) would look like
> >
> >{
> >hunk ./foo.c 50
> >-I want to replace the word oldtoken with newtoken.
> >+I want to replace the word oldtoken with oldtoken.
> >replace [a-zA-Z] oldtoken newtoken ./foo.c
> >}
> Instead, probably sometime after 1.0, would it be possible to give the 
> replace patch type an extra modifier that would indicate that it had 
> been forced?
> Perhaps something like:
> replace! [a-zA-Z] oldtoken newtoken ./foo.c
> or
> replace --force [a-zA-Z] oldtoken newtoken ./foo.c

No, that wouldn't work, since it wouldn't be invertible.

> By the way, I'm still not entirely comfortable with the replace command,
> and would actually be slightly happier if it were removed from darcs. I
> think it's more dangerous than helpful. But that's just me.

It all depends on how you use it.  The beauty of the replace command is
that it's wonderfully easy to undo, even after a number of merges.

As I recall (correct me if I'm wrong), your concerns with replace stem from
the difficulties that could arise when replacing a "token" that could have
different meanings in different contexts, and where you only want to rename
one of those items (e.g. if two classes each have a method with the same
name, and you only want to rename that method in one of the classes.
Certainly in such a situation replace isn't very useful, since it works on
a file-level granularity, which isn't enough.

On the other hand, if you have a practice of giving each function a
different name, except when they inherently always should have the same
name (e.g. operator+), then replace won't be prone to the aforementioned
problem (accidentally replacing another function having the same name).  In
short, replace isn't always useful, and if used carelessly could lead to
interesting bugs when merges happen.  On the other hand, merges can always
lead to interesting bugs... and in certain cases, replace can save a whole
lot of trouble.
David Roundy

More information about the darcs-users mailing list