git annotate with date option not working?

DISCUSSION Chengwei Ding 5 participants 9 messages Jun 15, 2016

lore

Share & tools

lore

Chengwei Ding

author

2016-06-15 22:51 UTC #0 lore raw

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

Jeff King

2016-06-15 22:51 UTC #1 lore raw

Quoted 2 lines · Chengwei Ding

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

This is by design:

  $ git show 31653c1abc1ac80206db9efca56ff1969150d8fe
  Author: Eugene Letuchy <[email protected]>
  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

Chengwei Ding

author

2016-06-15 22:51 UTC #2 lore raw

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

Quoted 27 lines · 在 Jun 1, 2011，18:16，Jeff King <[email protected]> 写道：

Quoted 2 lines · Chengwei Ding
can anyone confirm that this "--date" option is working for git annotate cmd.
This is by design:
 $ git show 31653c1abc1ac80206db9efca56ff1969150d8fe
 Author: Eugene Letuchy <[email protected]>
 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

Jeff King

2016-06-15 22:51 UTC #3 lore raw

In reply to Jeff King

Quoted 21 lines · Jeff King

Quoted 2 lines · Chengwei Ding

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

This is by design:

  $ git show 31653c1abc1ac80206db9efca56ff1969150d8fe
  Author: Eugene Letuchy <[email protected]>
  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;
  +       }

Quoted 4 lines

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:

builtin/blame.c +6 -6

index 26a5d42..274a98d 100644
@@ -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:

Jonathan Nieder

2016-06-15 22:51 UTC #4 lore raw

Quoted 7 lines · Jeff King

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.

Arnaud Lacurie

2016-06-15 22:51 UTC #5 lore raw

In reply to Chengwei Ding

Hi,

Quoted 2 lines

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

Signature · 1 line

Arnaud Lacurie

Chengwei Ding

author

2016-06-15 22:51 UTC #6 lore raw

Quoted 4 lines · Arnaud Lacurie

Hi,
Quoted 2 lines
can anyone confirm that this "--date" option is working for git annotate cmd.

Quoted 8 lines

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

Jakub Narebski

2016-06-15 22:51 UTC #7 lore raw

In reply to Chengwei Ding

Quoted 7 lines · Chengwei Ding

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?

Signature · 3 lines

Jakub Narebski
Poland
ShadeHawk on #git

Chengwei Ding

author

2016-06-15 22:51 UTC #8 lore raw

Quoted 5 lines · Jakub Narebski

Quoted 3 lines · Chengwei Ding
can anyone confirm that this "--date" option is working for git annotate cmd.

Quoted 9 lines

Quoted 4 lines
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