git annotate with date option not working?

hello,

can anyone confirm that this "--date" option is working for git annotate 
cmd.

i tried the same option on blame cmd which seems to be working, but not 
on the annotate which i use git annotate --date=relative or i wrote date 
config variable as blame.date which again work for blame but not 
annotate, but document says it should share same variable.

my env:
ubuntu 11.04 64
git ppa source 1.7.5.2

Regards

Chengwei Ding [off-list ref] writes:

can anyone confirm that this "--date" option is working for git
annotate cmd.

i tried the same option on blame cmd which seems to be working, but
not on the annotate which i use git annotate --date=relative or i
wrote date config variable as blame.date which again work for blame
but not annotate, but document says it should share same variable.

"git annotate" is left for backwards compatibility, so it might be
that not all git-blame switches work correctly with it.  

Does "git blame -c --date=relative" work?

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Hi,

can anyone confirm that this "--date" option is working for git annotate
cmd.

I tried 'git annotate --date=relative <onefile>' and it works perfectly here.
git version 1.7.4.1
ubuntu 11.04

It works also well on the git version 1.7.5.3.401.gfb674 (The latest on master)

Regards

-- 
Arnaud Lacurie

On 06/01/2011 11:40 AM, Jakub Narebski wrote:

Chengwei Ding[off-list ref]  writes:

quoted

can anyone confirm that this "--date" option is working for git
annotate cmd.

i tried the same option on blame cmd which seems to be working, but
not on the annotate which i use git annotate --date=relative or i
wrote date config variable as blame.date which again work for blame
but not annotate, but document says it should share same variable.

"git annotate" is left for backwards compatibility, so it might be
that not all git-blame switches work correctly with it.

Does "git blame -c --date=relative" work?

emm, no luck.

//Chengwei

On 06/01/2011 11:41 AM, Arnaud Lacurie wrote:

Hi,

quoted

can anyone confirm that this "--date" option is working for git annotate
cmd.

I tried 'git annotate --date=relative<onefile>' and it works perfectly here.
git version 1.7.4.1
ubuntu 11.04

It works also well on the git version 1.7.5.3.401.gfb674 (The latest on master)

Regards

try again on my machine, give same result when with and without --date. 
haven't tried latest master but did try the 1.7.5.3 official release 
(manual compiled)

//Chengwei

On Wed, Jun 01, 2011 at 10:20:37AM +0200, Chengwei Ding wrote:

can anyone confirm that this "--date" option is working for git
annotate cmd.

This is by design:

  $ git show 31653c1abc1ac80206db9efca56ff1969150d8fe
  Author: Eugene Letuchy [off-list ref]
  Date:   Fri Feb 20 14:51:11 2009 -0800
  [...]
      git annotate ignores the date format specifiers and continues to
      uses the ISO format, as before.
  [...]
  +       if (cmd_is_annotate) {
                  output_option |= OUTPUT_ANNOTATE_COMPAT;
  +               blame_date_mode = DATE_ISO8601;
  +       } else {
  +               blame_date_mode = revs.date_mode;
  +       }

The annotate command is a historical artifact, and will remain frozen in
time in terms of output format and features. If you want to use newer
features, use "git blame". If you really need the annotate output format
with newer blame features, use "git blame -c".

-Peff

Thx Peff, this really helps. So then doc on this cmd is outdated. Have
been used to emacs build-in vc which call annotate (rumor say it will
support git blame), anyway, have switch to other emacs git plugin now.

Thanks

发自我的 iPhone

在 Jun 1, 2011，18:16，Jeff King [off-list ref] 写道：

On Wed, Jun 01, 2011 at 10:20:37AM +0200, Chengwei Ding wrote:

quoted

can anyone confirm that this "--date" option is working for git
annotate cmd.

This is by design:

 $ git show 31653c1abc1ac80206db9efca56ff1969150d8fe
 Author: Eugene Letuchy [off-list ref]
 Date:   Fri Feb 20 14:51:11 2009 -0800
 [...]
     git annotate ignores the date format specifiers and continues to
     uses the ISO format, as before.
 [...]
 +       if (cmd_is_annotate) {
                 output_option |= OUTPUT_ANNOTATE_COMPAT;
 +               blame_date_mode = DATE_ISO8601;
 +       } else {
 +               blame_date_mode = revs.date_mode;
 +       }

The annotate command is a historical artifact, and will remain frozen in
time in terms of output format and features. If you want to use newer
features, use "git blame". If you really need the annotate output format
with newer blame features, use "git blame -c".

-Peff

On Wed, Jun 01, 2011 at 12:16:38PM -0400, Jeff King wrote:

On Wed, Jun 01, 2011 at 10:20:37AM +0200, Chengwei Ding wrote:

quoted

can anyone confirm that this "--date" option is working for git
annotate cmd.

This is by design:

  $ git show 31653c1abc1ac80206db9efca56ff1969150d8fe
  Author: Eugene Letuchy [off-list ref]
  Date:   Fri Feb 20 14:51:11 2009 -0800
  [...]
      git annotate ignores the date format specifiers and continues to
      uses the ISO format, as before.
  [...]
  +       if (cmd_is_annotate) {
                  output_option |= OUTPUT_ANNOTATE_COMPAT;
  +               blame_date_mode = DATE_ISO8601;
  +       } else {
  +               blame_date_mode = revs.date_mode;
  +       }

The annotate command is a historical artifact, and will remain frozen in
time in terms of output format and features. If you want to use newer
features, use "git blame". If you really need the annotate output format
with newer blame features, use "git blame -c".

Having said that, this would be really easy to support, and I don't
think would have any negative compatibility consequences, as long as we
don't support blame.date. But I don't think we're breaking anybody
relying on "git annotate --date=whatever" being silently ignored, as
that option has never done anything useful.

The patch would look like this:

diff --git a/builtin/blame.c b/builtin/blame.c
index 26a5d42..274a98d 100644
--- a/builtin/blame.c
+++ b/builtin/blame.c

@@ -2333,7 +2333,10 @@ int cmd_blame(int argc, const char **argv, const char *prefix)
 
 	git_config(git_blame_config, NULL);
 	init_revisions(&revs, NULL);
-	revs.date_mode = blame_date_mode;
+	if (cmd_is_annotate)
+		revs.date_mode = DATE_ISO8601;
+	else
+		revs.date_mode = blame_date_mode;
 	DIFF_OPT_SET(&revs.diffopt, ALLOW_TEXTCONV);
 
 	save_commit_buffer = 0;

@@ -2368,13 +2371,10 @@ parse_done:
 	if (revs_file && read_ancestry(revs_file))
 		die_errno("reading graft file '%s' failed", revs_file);
 
-	if (cmd_is_annotate) {
+	if (cmd_is_annotate)
 		output_option |= OUTPUT_ANNOTATE_COMPAT;
-		blame_date_mode = DATE_ISO8601;
-	} else {
-		blame_date_mode = revs.date_mode;
-	}
 
+	blame_date_mode = revs.date_mode;
 	/* The maximum width used to show the dates */
 	switch (blame_date_mode) {
 	case DATE_RFC2822:

Jeff King wrote:

Having said that, this would be really easy to support, and I don't
think would have any negative compatibility consequences, as long as we
don't support blame.date. But I don't think we're breaking anybody
relying on "git annotate --date=whatever" being silently ignored, as
that option has never done anything useful.

The patch would look like this:

Looks obviously good to me.  Chengwei (and anyone else), would you be
interested in moving this forward by adding tests and perhaps
documentation?

Thanks.