[darcs-users] post-hoc move

[Hamish Allan]

On Fri, Jul 31, 2009 at 7:05 AM, Dan Pascu<dan at ag-projects.com> wrote:

> On Thursday 30 July 2009, Hamish Allan wrote:
>
>> Personally, I don't think "darcs move" should do the actual physical
>> move at all. "darcs add" doesn't physically create a file; "darcs
>> remove" doesn't physically delete one. Likewise, "darcs move" should
>> simply mean "change your concept of what this file is called".
>
> I disagree. From a usability point of view, this would be a regression, as it
> would always require me to type 2 commands to do the operation.

Okay, let me revise my position to: I think it would be *really*
useful to have a switch to darcs move so that I can type "darcs move
-retrospectively $LOC1 $LOC2" after I've already moved $LOC1 to $LOC2.

> Of course with
> add it doesn't add the file because it cannot create one out of thin air.

Of course it can. Try typing "touch newfile" at your unix shell
sometime and see what happens. (And indeed, to Darcs the adding of the
file is separate from the adding of the content chunk within the new
file.)

But most of the time, you want to add the file after it's already
created. Why? Because you've already used another tool to create the
file, e.g., a text editor.

For exactly the same reason, it would be useful to apply a move
retrospectively. Most IDEs allow you to rename files from within them,
which is not so different to creating a file within your text editor,
is it? Not to mention all the various other ways a file may have been
moved or renamed outside of the shell, e.g., a refactoring tool.

> You
> have to create the file somehow before you can actually add it to darcs. With
> remove it doesn't remove it because that's the semantics: to remove the file
> from darcs control but keep it around on disk.

That's a circular argument: "the behaviour is different for case B
because that's how case B behaves".

> If I want to get rid of it
> entirely I just remove it on the filesystem.

Likewise, if I want to move a file I can just move it on the
filesystem. But if I've *already* moved it, to get Darcs to track that
move I have to unrevert the change and move the file back just so that
Darcs can move it over again itself. To my mind, that's a considerably
worse usability issue than having to do two operations to move a file.
But I'm not even arguing for that; I just think a "-retrospectively"
option to "darcs move" would be *really* useful.

> Currently all these operations
> can be done in 1 step (except file creation for add, but I do not expect add
> to create and populate a file as well anyway).

I don't understand this. Haven't you just described how a remove is a
two-step operation?

Best wishes,
Hamish