In the 1.0.8 release (at least), 'darcs changes' on a moved file
(with 'darcs mv') does not report any changes. It probably should.

Tuomo Valkonen wrote:
> New submission from Tuomo Valkonen <tuomov@iki.fi>:
> 
> In the 1.0.8 release (at least), 'darcs changes' on a moved file
> (with 'darcs mv') does not report any changes. It probably should.
> 

I'm not able to reproduce this:

[14:16:22] lele@paci:p $ darcs init
[14:16:25] lele@paci:p $ touch a
[14:16:27] lele@paci:p $ darcs add a
[14:16:29] lele@paci:p $ darcs record -a -m "first"
Finished recording patch 'first'
[14:16:35] lele@paci:p $ darcs mv a b
[14:16:46] lele@paci:p $ darcs record -a -m "second"
Finished recording patch 'second'
[14:16:48] lele@paci:p $ darcs cha
Fri Aug 18 14:16:48 CEST 2006  lele@nautilus.homeip.net
   * second

Fri Aug 18 14:16:35 CEST 2006  lele@nautilus.homeip.net
   * first
[14:16:51] lele@paci:p $ darcs cha -v
Fri Aug 18 14:16:48 CEST 2006  lele@nautilus.homeip.net
   * second

     move ./a ./b

Fri Aug 18 14:16:35 CEST 2006  lele@nautilus.homeip.net
   * first

     addfile ./a
[14:16:54] lele@paci:p $ darcs --version
1.0.8 (release)
[14:17:14] lele@paci:p $ darcs cha b
Changes to b:

Fri Aug 18 14:16:48 CEST 2006  lele@nautilus.homeip.net
   * second

Fri Aug 18 14:16:35 CEST 2006  lele@nautilus.homeip.net
   * first

ciao, lele.

On 2006-08-18 12:23 +0000, Lele Gaifax wrote:
> I'm not able to reproduce this:
> 
> [14:16:22] lele@paci:p $ darcs init
> [14:16:25] lele@paci:p $ touch a
> [14:16:27] lele@paci:p $ darcs add a
> [14:16:29] lele@paci:p $ darcs record -a -m "first"
> Finished recording patch 'first'
> [14:16:35] lele@paci:p $ darcs mv a b
> [14:16:46] lele@paci:p $ darcs record -a -m "second"
> Finished recording patch 'second'
> [14:16:48] lele@paci:p $ darcs cha

Bzzt. You recorded the move. The problem only occurs on unrecorded
moves. (I should've mentioned that, but seem to have thought it obvious.)
Darcs doesn't seem to use the _darcs/patches/pending information.

Tuomo Valkonen wrote:
> Bzzt. You recorded the move. The problem only occurs on unrecorded
> moves. (I should've mentioned that, but seem to have thought it obvious.)
> Darcs doesn't seem to use the _darcs/patches/pending information.
> 

Uhm, "darcs changes" obviously shows *only* recorded patches. Maybe you 
meant "darcs whatsnew", but that too is working ok here...

[14:36:31] lele@paci:p $ touch c
[14:40:17] lele@paci:p $ darcs add c
[14:40:23] lele@paci:p $ darcs record -a -m "third"
Finished recording patch 'third'
[14:40:31] lele@paci:p $ darcs mv c d
[14:40:35] lele@paci:p $ darcs cha
Fri Aug 18 14:40:31 CEST 2006  lele@nautilus.homeip.net
   * third

Fri Aug 18 14:16:48 CEST 2006  lele@nautilus.homeip.net
   * second

Fri Aug 18 14:16:35 CEST 2006  lele@nautilus.homeip.net
   * first
[14:40:37] lele@paci:p $ darcs wha
{
move ./c ./d
}

ciao, lele.

On 2006-08-18 12:44 +0000, Lele Gaifax wrote:
> 
> Lele Gaifax <lele@nautilus.homeip.net> added the comment:
> 
> Tuomo Valkonen wrote:
> > Bzzt. You recorded the move. The problem only occurs on unrecorded
> > moves. (I should've mentioned that, but seem to have thought it obvious.)
> > Darcs doesn't seem to use the _darcs/patches/pending information.
> > 
> 
> Uhm, "darcs changes" obviously shows *only* recorded patches. Maybe you 
> meant "darcs whatsnew", but that too is working ok here...

Okay, let's go through this command by command:

	noi:~/a$ darcs init
	noi:~/a$ touch b
	noi:~/a$ darcs add b
	noi:~/a$ darcs rec -a -m 1
	Finished recording patch '1'
	noi:~/a$ darcs mv b c

Now, let's check the changelog for 'c':

	noi:~/a$ darcs cha c
	Changes to c:

	noi:~/a$

Nothing! It didn't work! Full log works, though:

	noi:~/a$ darcs cha
	Fri Aug 18 15:49:18 EEST 2006  Tuomo Valkonen <tuomov@iki.fi>
	  * 1

Or changes on b, which no longer exists:

	noi:~/a$ darcs cha b
	Changes to b:

	Fri Aug 18 15:49:18 EEST 2006  Tuomo Valkonen <tuomov@iki.fi>
	  * 1

After recording:

	noi:~/a$ darcs rec -a -m 2
	Finished recording patch '2'
	noi:~/a$ darcs cha c
	Changes to c:

	Fri Aug 18 15:50:14 EEST 2006  Tuomo Valkonen <tuomov@iki.fi>
	  * 2

	Fri Aug 18 15:49:18 EEST 2006  Tuomo Valkonen <tuomov@iki.fi>
	  * 1

Tuomo Valkonen wrote:
>> Lele Gaifax <lele@nautilus.homeip.net> added the comment:
>> Uhm, "darcs changes" obviously shows *only* recorded patches. Maybe you 
>> meant "darcs whatsnew", but that too is working ok here...
> 
> Okay, let's go through this command by command:
> 
> 	noi:~/a$ darcs init
> 	noi:~/a$ touch b
> 	noi:~/a$ darcs add b
> 	noi:~/a$ darcs rec -a -m 1
> 	Finished recording patch '1'
> 	noi:~/a$ darcs mv b c
> 
> Now, let's check the changelog for 'c':
> 
> 	noi:~/a$ darcs cha c
> 	Changes to c:
> 
> 	noi:~/a$
> 

Ok, I see your point, but as said, I still think this is not a bug, as 
"changes" does look *only* in inventory of recorded patches. Indeed, you 
get the very same behaviour on any other not-yet-recorded action:

[14:40:45] lele@paci:p $ touch e
[14:59:22] lele@paci:p $ darcs add e
[14:59:28] lele@paci:p $ darcs cha e
Changes to e:

[14:59:34] lele@paci:p $

I'd find somewhat confusing if "darcs changes" overlapped with "darcs 
whatsnew". From darcs POV, not-yet-recorded changes do not belong to the 
repository, and as such "darcs changes" does not report pending actions 
like a "darcs get" does not copy them to the new repository.

ciao, lele.

On 2006-08-18 13:06 +0000, Lele Gaifax wrote:
> I'd find somewhat confusing if "darcs changes" overlapped with "darcs 
> whatsnew". From darcs POV, not-yet-recorded changes do not belong to the 
> repository, and as such "darcs changes" does not report pending actions 
> like a "darcs get" does not copy them to the new repository.

But there is no overlap, and I'm not asking to report the pending changes;
there isn't even a log entry for them. The moved file already has other
changes in the log in my example, which are listed by 'darcs changes' if
the file is not specified. But for the particular file, darcs temporarily
forgets them until the move is recorded.

Tuomo Valkonen wrote:
> But there is no overlap, and I'm not asking to report the pending changes;
> there isn't even a log entry for them. 

Ah, ok.

 > The moved file already has other
> changes in the log in my example, which are listed by 'darcs changes' if
> the file is not specified. But for the particular file, darcs temporarily
> forgets them until the move is recorded.

It's not that darcs forgot anything, the changes are still there and you 
can get them by asking about the old-file-now-renamed

[15:22:29] lele@paci:p $ darcs mv b f
[15:22:38] lele@paci:p $ darcs cha f
Changes to f:

[15:22:40] lele@paci:p $ darcs cha -v b
Changes to b:

Fri Aug 18 14:16:48 CEST 2006  lele@nautilus.homeip.net
   * second

     move ./a ./b

Fri Aug 18 14:16:35 CEST 2006  lele@nautilus.homeip.net
   * first

     addfile ./a

I find this behaviour less confusing than what you propose, there must 
be a clear border line that separates concretely recorded changes from 
the pending ones.

OTOH, maybe "darcs changes" could emit a (better) message when asked 
about a file that's not under its control (in other words, you get the 
same (empty) output even with "darcs changes this-file-is-not-here")

ciao, lele.

On 2006-08-18 13:34 +0000, Lele Gaifax wrote:
> I find this behaviour less confusing than what you propose, there must 
> be a clear border line that separates concretely recorded changes from 
> the pending ones.

There is no confusion. From 'darcs changes --help'

"""
Changes gives a changelog-style summary of the repository history,
including options for altering how the patches are selected and displayed.
"""

The moved file has a history, and darcs should report it. 

Infact, I find it odd that 'darcs changes' reports changes to files
that are no longer in the repository even when this has already been
recorded:

    ~/a$ darcs init
    ~/a$ touch a
    ~/a$ darcs add a
    ~/a$ darcs rec -a -m 1
    Finished recording patch '1'
    ~/a$ darcs mv a b
    ~/a$ darcs rec -a -m 2
    Finished recording patch '2'
    ~/a$ darcs cha a
    Changes to a:

    Fri Aug 18 17:16:13 EEST 2006  Tuomo Valkonen <tuomov@iki.fi>
      * 2

    Fri Aug 18 17:16:08 EEST 2006  Tuomo Valkonen <tuomov@iki.fi>
      * 1

It seems like 'darcs changes' does a simple 'grep' in the changelog,
instead of tracking the changes that apply to an object it presently
knows about. (Adding a new file 'a', does not report the changes to
the old version, however.)

> OTOH, maybe "darcs changes" could emit a (better) message when asked 
> about a file that's not under its control (in other words, you get the 
> same (empty) output even with "darcs changes this-file-is-not-here")

The current behaviour, or what you propose, is telling the user
to "piss off and figure it out yourself". It unnecessarily complicates
matters for the user, and the user should be the king. Darcs knows
about the moved file, so it should report what it has been told about
its history, i.e. the log entries.

Tuomo Valkonen wrote:
> There is no confusion. From 'darcs changes --help'
> 
> """
> Changes gives a changelog-style summary of the repository history,
> including options for altering how the patches are selected and displayed.
> """
> 
> The moved file has a history, and darcs should report it. 

And as demonstrated, it reports it. It's just that the pending changes 
*does not* belong (yet, maybe) to the repository history.

> It seems like 'darcs changes' does a simple 'grep' in the changelog,
> instead of tracking the changes that apply to an object it presently
> knows about. (Adding a new file 'a', does not report the changes to
> the old version, however.)

As you showed, and as I already told a few times, yes: as stated in the 
help of the command, darcs "greps" through the "changelog" (the 
repository inventory, in darcs speaking), and output any patch that 
touched the given file. So, by definition, it does not print anything 
about a file not (yet) mentioned in the history, and surely a 
not-yet-recorded rename falls into this case.

> 
>> OTOH, maybe "darcs changes" could emit a (better) message when asked 
>> about a file that's not under its control (in other words, you get the 
>> same (empty) output even with "darcs changes this-file-is-not-here")
> 
> The current behaviour, or what you propose, is telling the user
> to "piss off and figure it out yourself". It unnecessarily complicates
> matters for the user, and the user should be the king. Darcs knows
> about the moved file, so it should report what it has been told about
> its history, i.e. the log entries.

You put it very badly. I'm after all a (very happy) darcs user, and 
never thought darcs told me anything like that. I know the difference 
between what is recorded in the repository history, and what's just 
"noise" in the filesystem, and luckily this notion matches with that of 
darcs.

You are simply obliterating the distinction between "history" and 
"pending facts". The former comes out with "changes", the latter with 
"whatsnew". What's so complicated in this?

I wonder what should darcs emit, in your vision, in the following context:

$ darcs rm this-file-is-being-replaced
$ touch this-file-is-being-replaced
$ darcs add this-file-is-being-replaced
$ darcs changes this-file-is-being-replaced

If I'm king, I'd expect to obtain the *very* same result from there as I 
would obtain in a clone of that, that it:

$ cd ..
$ darcs get repo cloned
$ cd cloned
$ darcs changes this-file-is-being-replaced

I hope this clears out that my POV has the same value as yours. I'm only 
somewhat luckier in sharing it with darcs :-)

ciao, lele.

On 2006-08-18 14:54 +0000, Lele Gaifax wrote:
> Lele Gaifax <lele@nautilus.homeip.net> added the comment:
> > """
> > Changes gives a changelog-style summary of the repository history,
> > including options for altering how the patches are selected and displayed.
> > """
> > 
> > The moved file has a history, and darcs should report it. 
> 
> And as demonstrated, it reports it. It's just that the pending changes 
> *does not* belong (yet, maybe) to the repository history.

They're not (recorded) history; they are the changes needed to
reach from recorded history, the current state. Any command should
report things relative to the current state.

> As you showed, and as I already told a few times, yes: as stated in the 
> help of the command, darcs "greps" through the "changelog" (the 
> repository inventory, in darcs speaking), and output any patch that 
> touched the given file. So, by definition, it does not print anything 
> about a file not (yet) mentioned in the history, and surely a 
> not-yet-recorded rename falls into this case.

Thus 'changes' is fundamentally broken. It does not thread back from
current state, but works on something detached from it.

> You put it very badly. I'm after all a (very happy) darcs user, and 
> never thought darcs told me anything like that. I know the difference 
> between what is recorded in the repository history, and what's just 
> "noise" in the filesystem, and luckily this notion matches with that of 
> darcs.

Moved files are not noise; darcs knows about them. Files that it knows
nothing about are noise.

> 
> You are simply obliterating the distinction between "history" and 
> "pending facts". The former comes out with "changes", the latter with 
> "whatsnew". What's so complicated in this?

**Screaming**

Currently 'changes' works on history detached from present; it works
on data that is not understood in the present anymore. It works in
an alternate reality.

When I find the ruins of some building, I ask what's the history
of that building. When I'm in an empty space in the nature, I seldom
ask, what's the history of the building of that-and-that name, that
supposedly has been there. The present is the link to the past.

> I wonder what should darcs emit, in your vision, in the following context:
> 
> $ darcs rm this-file-is-being-replaced
> $ touch this-file-is-being-replaced
> $ darcs add this-file-is-being-replaced
> $ darcs changes this-file-is-being-replaced

Nothing; it's a new object. The link from the present to the old file 
has been lost.

Hmm... there's another misfeature or (bug) workaround here! That 
sequence result in an empty _darcs/patches/pending! 

> If I'm king, I'd expect to obtain the *very* same result from there as I 
> would obtain in a clone of that, that it:
> 
> $ cd ..
> $ darcs get repo cloned
> $ cd cloned
> $ darcs changes this-file-is-being-replaced

No; that repository has different current state. 'get' only fetches the
recorded history, not the present.

Tuomo Valkonen wrote:
> No; that repository has different current state. 'get' only fetches the
> recorded history, not the present.

Sorry Tuomo, but it's evident we live in two different universes. In 
mine, history begins when I commit stuff, and does not cover what I'm 
currently hacking on.

While I'm editing a file in Emacs, its actual content on the filesystem 
is still untouched, and I don't want that a grep, or a compilation, 
notice that I cleared it in my *buffer*. When I'm playing SQL, I'm 
expecting others don't see anything of my changes, until I do a COMMIT. 
In both cases, what I did [since last C-x C-s, or COMMIT] lives in a 
limbo (some #filename# for Emacs, an even more opaque memory for an SQL 
engine).

Under darcs, the history of a repository is written in its inventory, 
and stops there. The present is eventually written in its pending file. 
Two different commands let you inspect one or the other. Simple and 
effective. Confusing the two is a human imperfection that I'm glad darcs 
didn't try to mimic.

I won't debate further,
ciao, lele.

On 2006-08-18 15:56 +0000, Lele Gaifax wrote:
> Lele Gaifax <lele@nautilus.homeip.net> added the comment:
> Sorry Tuomo, but it's evident we live in two different universes. In 
> mine, history begins when I commit stuff, and does not cover what I'm 
> currently hacking on.

History is the recorded changes, but history is seen through the
present.

> 
> While I'm editing a file in Emacs, its actual content on the filesystem 
> is still untouched, and I don't want that a grep, or a compilation, 
> notice that I cleared it in my *buffer*. When I'm playing SQL, I'm 
> expecting others don't see anything of my changes, until I do a COMMIT. 

You don't share your working repository, do you?

> Under darcs, the history of a repository is written in its inventory, 
> and stops there. The present is eventually written in its pending file. 
> Two different commands let you inspect one or the other. 

But 'darcs changes' does not let me inspect the history of my repository,
as it does not do it through the present. It inspects something else,
and could thus live in a different universe altogether. It lives entirely
in the past; it is dead, and it can not communicate to me. There's a
gulf of time that turns its message into an indecipherable mess.

> Simple and  effective. 

Complex and retarded (literally).

> Confusing the two is a human imperfection that I'm glad darcs 
> didn't try to mimic.

The current behaviour is confusing. Commands operate on something that is
detached from how I see the state of the repository -- i.e. the working
copy, as these are the same thing in darcs. It's confusing, because 'darcs
changes' lives in a different universe than the one I observe. The working
copy, i.e. the present, is my window to the history; anything should
operate relative to that.

[This is something that probably should be discussed on darcs-users, so I CC]
[This is a comment to <http://bugs.darcs.net/issue244>, sorry for not quoting.]

I think the "problem" lies in using file names when asking darcs
for changes. The logical entity in darcs history that we think
of as a "file" can have different names at different points, so
it's not always clear what file entity a file name refers to.

I think there is no dispute about what part of the changes that
Changes and Whatsnew shall report. The difference between
recorded and unrecorded changes is very clear and simple. But
the problem of informing darcs about what file entity we want to
examine can sometimes be complicated, especially if old files
have been removed and the old file names have been reused.

In this particular case the question is: should a file entity be
referable by its currently unrecorded name, in addition to all
its previously recorded file names. It think it should, because
I think it generates the least surprise to users.

See also issue115

So one problem is that a file may have different names at different
points.  Another related problem (though maybe not for this bug) is that
the same name could mean different files at different points (eeew!).
Could lead to trickiness.

One thing we might consider doing is making the 'touching' matcher mean
"match on all files/directories that were called foo at some point in
their lives".

On 2006-08-20 11:16 +0000, Eric Kow wrote:
> One thing we might consider doing is making the 'touching' matcher mean
> "match on all files/directories that were called foo at some point in
> their lives".

I think the simplest notion is that of "grabbing an object and following
its history". Now, presently existing objects can be grabbed through
their present file names. The problem then becomes how to grab an object
that no longer exist, no longer has a file name to it. Perhaps the 
--to-patch/match/tag options should alter what is seen as the "present",
or alternative similar options cuold be added (though that makes the
number of options changes a rather big one). (Actually, the present
--to-* and --from-* options should perhaps be integrated into
--tags/--matches/--patches as special selectors.

Another rahter annoying feature regarding changes on a particular files 
is --last, by the way. One would expect it to display the last n patches
that changed the file, but instead it first filters the last n patches
and then matches against the file.

On Sun, Aug 20, 2006 at 11:34:21 +0000, Tuomo Valkonen wrote:
> Another rahter annoying feature regarding changes on a particular files 
> is --last, by the way. One would expect it to display the last n patches
> that changed the file, but instead it first filters the last n patches
> and then matches against the file.

See also issue92

I gather diff behaves the right way, but not changes.  I also agree that
the best use of --last would be it filtered *after* matching.

On Sun, Aug 20, 2006 at 11:16:49AM +0000, Eric Kow wrote:
> Eric Kow <eric.kow@gmail.com> added the comment:
> So one problem is that a file may have different names at different
> points.  Another related problem (though maybe not for this bug) is that
> the same name could mean different files at different points (eeew!).
> Could lead to trickiness.

Indeed, this is the complication.  I tend to agree with Tuomo (and
Tommy) that the current (possibly unrecorded) name is probably best to
match against.  With regard to no-longer-existing files, their most
recent name seems reasonable (which I believe is the current
behavior).

> One thing we might consider doing is making the 'touching' matcher mean
> "match on all files/directories that were called foo at some point in
> their lives".

I hadn't thought of that.  In the common case where there are no two
files with the same name in the history, this will almost always do
what the user expects, while in the uncommon extra-confusing case
where distinct files have shared a name, it'll present that
information in a coherent manner.  The only catch is that in order to
do this we may need to read through the entire history twice.  But I
guess in the common case we wouldn't have to do so, so it wouldn't
slow down the common case, as long as we're clever about it.
-- 
David Roundy

I confirmed this issue still exists with Darcs2, and just sent a regression to
the bugs/ directory to help with it. 

It's a possible candidate for being re-filed as "wishlist" item to help
prioritize things, since I believe the current behavior is working as expected
and acceptable, but the new behavior described here may be even more desirable.

Fixed long ago by:

Tue Jan 22 14:14:21 GMT 2008  David Roundy <droundy@darcs.net>
  * fix changes_moved_files bug.