I'm not sure whether this is really a bug, or just darcs not behaving in the way
I'd expect. "darcs annotate filename" doesn't give the name, date etc of the
last modifying patch. This is with 1.0.5rc1 on Windows.
An example of this happening (using cygwin's shell, because it makes things
easier to do, but the same thing happens when it's done in cmd.exe):

[edwint: ...c/New Folder]$ mkdir test
[edwint: ...c/New Folder]$ cd test
[edwint: ...New Folder/test]$ darcs init
[edwint: ...New Folder/test]$ cat > x
line 1
line 2
[edwint: ...New Folder/test]$ darcs add x
[edwint: ...New Folder/test]$ darcs record
addfile ./x
Shall I record this patch? (1/?) [ynWsfqadjkc], or ? for help: y

hunk ./x 1
+line 1
+line 2
Shall I record this patch? (2/?) [ynWsfqadjkc], or ? for help: y

What is the patch name? Created x
Do you want to add a long comment? [yn] n

Finished recording patch 'Created x'
[edwint: ...New Folder/test]$ cat >> x
Line 3
[edwint: ...New Folder/test]$ darcs record 
hunk ./x 3
+Line 3
Shall I record this patch? (1/?) [ynWsfqadjkc], or ? for help: y

What is the patch name? Changed x
Do you want to add a long comment? [yn] n

Finished recording patch 'Changed x'
[edwint: ...New Folder/test]$ darcs annotate x
# File x created by [Created x
# edwint**20051128095010]  as ./x
# Following line added by [Created x
# edwint**20051128095010] 
 line 1
# Following line added by [Created x
# edwint**20051128095010] 
 line 2
+Line 3

There is no reference to anything that would make it possible to find out what
patch actually added the "Line 3"

Edwin

The behavior is the same with linux and also with darcs 1.0.3,
and the documentation says:

  If a file name is given, the last modifying patch details of
  that file will be output, along with markup indicating patch
  details when each line was last (and perhaps next) modified.

I think the documentation is a little hard to understand.
And it is also a little unexpected that 'darcs ann f' gives
the same result as 'darcs ann f -p .'

But then, there may be tools parsing darcs's output relaying
on the current behavior.

On Mon, Nov 28, 2005 at 10:58:32AM +0000, Tommy Pettersson wrote:
> The behavior is the same with linux and also with darcs 1.0.3,
> and the documentation says:
> 
>   If a file name is given, the last modifying patch details of
>   that file will be output, along with markup indicating patch
>   details when each line was last (and perhaps next) modified.
> 
> I think the documentation is a little hard to understand.
> And it is also a little unexpected that 'darcs ann f' gives
> the same result as 'darcs ann f -p .'

Indeed that is the reasoning.  The + indicates "this patch", which is
taken to be the most recent one.  Probably not the best choice.

> But then, there may be tools parsing darcs's output relaying
> on the current behavior.

I'm not sure, but wouldn't want to change the behavior for this reason.  We
could, however, add a new version of annotate as a query subcommand if
someone wanted to work on this.
-- 
David Roundy
http://www.darcs.net

David Roundy wrote:
> Indeed that is the reasoning.  The + indicates "this patch", which is
> taken to be the most recent one.  Probably not the best choice.

Ah, I had misunderstood what "this patch" meant. I had been thinking it 
meant the most recent patch which touched the file in question, rather 
than the most recent patch full stop.  Things make more sense now.

Edwin

I would appreciate a command that didn't give special treatment to the most
recent patch.  The "darcs-reannotate" tool I wrote chokes on the special case.

I'm willing to work on an option that disables the special treatment.  Should it
be an option to "annotate" or a subcommand of "query"?

On Mon, Nov 28, 2005 at 09:41:17PM +0000, Kannan Goundan wrote:
> I'm willing to work on an option that disables the special treatment.  Should it
> be an option to "annotate" or a subcommand of "query"?

I think the best thing is a completely new Query subcommand
that does not replicate the mess of Annotate.  It should
basically do what Annotate does on files and directories (the
"blame" output), but in a clean and easy to read/parse form.
I haven't looked at your reannotate tool, but perhaps
that format could be used.  It would of course be good to
have the local patch numbers in place first, so that line
annotations could use those numbers/hashes, but the command
can be documented as experimental and changed later.

With a --tag option, it should output that version of the
file/directory, and a --patch option could do the +/- thing.

On Tue, Nov 29, 2005 at 12:13:54PM +0000, Tommy Pettersson wrote:
> I think the best thing is a completely new Query subcommand
> that does not replicate the mess of Annotate. [...]

Agreed.

> With a --tag option, it should output that version of the
> file/directory, and a --patch option could do the +/- thing.

I agree on the --tag, but think that probably for consistency the --patch
option should behave the same as --tag, except that it refers to a version
right after that patch (i.e. doesn't do the +/- thing).  We could perhaps
have a separate command that "shows changes to a file caused by a given
patch" which does the +/- thing if someone finds that useful (which is not
unlikely).
-- 
David Roundy
http://www.darcs.net

I'm marking this as "feature" because the communication seems to indicate that
the current "annotate" is working as expected, although it may be unintuitive. A
new feature in the form of a "darcs show" subcommand is desired. 

I also removed the assignment label, since the assignee hasn't produced any work
in two years.

Merging in issue166.  From msg8009 and msg8011:

I was chatting with Johan Tibell about this, and he suggested this output:
  LineNum Author Line

See also:
  http://badgertronics.com/writings/cvs/cvsannotate-sample.html

I realise this did not come up during the hacking sprint discussion, but this
may be a good candidate for Darcs 2.5

I claim that issue1866 is a pre-requisite for this.

This is not going to happen before 2.5.

Moreover, as a grumpy old man, I'd never let anyone introduce a command
that does the same thing as annotate but with a different output format.
Is there a good reason why we can't change the current annotate output
format?

I'd be worried about compatibility, but personally I would prefer just
replacing annotate with the new output or maybe having (ugh) a flag if
breaking 3rd party tools is a big deal.

On Fri, 18 Jun 2010 06:30:52 +0000
Reinier Lamers <bugs@darcs.net> wrote:

> 
> Reinier Lamers <tux_rocker@reinier.de> added the comment:
> 
> This is not going to happen before 2.5.
> 
> Moreover, as a grumpy old man, I'd never let anyone introduce a command
> that does the same thing as annotate but with a different output format.
> Is there a good reason why we can't change the current annotate output
> format?

The current annotate output is unfriendly and unhelpful, I agree that
replacing it is a better solution. The change could be announced early
in the alpha/beta cycle to give third-parties a chance to respond in
case they depend on it. 

   Mark

Just updating this ticket so as not to overspecify: we may just well
replace annotate itself or add a flag like --output=easy

Here is the format used by git blame:
http://book.git-scm.com/5_finding_issues_-_git_blame.html

> Here is the format used by git blame:
> http://book.git-scm.com/5_finding_issues_-_git_blame.html

Looks OK to me. 

   Mark

annotate was replaced in 2.8.