Re: git stash list shows timestamp in stead of "stash number", when setting date = local for log in config

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Sep 15, 2009 at 04:56:41PM +0200, Alf Kristian Støyle wrote:

> Hi. Searched the lists, but haven't found anyone reporting this problem.
> 
> When doing a "git stash list" I get this strange stash record:
> stash@{Tue Sep 15 16:28:12 2009}: WIP on master: 2262276 ...
> 
> I have a global config setting on log:
> 
> [log]
> date = local
> 
> If setting the date config to default or removing the setting, the
> stash record looks correct:
> stash@{0}: WIP on master: 2262276 ...
> 
> I might be missing something here, but I do find this a bit strange.
> Is this a bug or a feature, and is there a setting I can use (for
> stash) to always show the latter line? I kind of like having local
> timestamps in log.

It's both. :) The stash is just a reflog, which is basically a linear
list of events that changed the ref. So "git stash list" is really just
"git reflog show stash".

When we show reflogs, we usually just number them sequentially, as that
is the way that people generally refer to them. But if you specify a
date format, then we figure you want to see the date (especially
--date=relative), so we show that.  But of course in your case, you have
set a config option that is about showing the date in general, so it
doesn't really imply the same "I want to see the date".

So I think it is a feature that is being turned on by a bug.

And I think the right solution is to differentiate between command-line
--date and config log.date. The other option would be for "git-stash" to
explicitly pass "--date=default" to turn off date-printing. But I think
this is a general problem with log.date and showing reflogs, not just
stash.

The patch below implements the former. The only downside I can think of
is if somebody is relying on "log.date" to set the output format for
reflogs, because they really like the date version better. In that case,
I think we should wait for them to complain (which I doubt will happen),
and then add a log.reflogDates config option to appease them.

Shawn, reflogs are your thing. Any comments?

diff --git a/log-tree.c b/log-tree.c
index 1c9eefe..1618f3c 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -390,7 +390,9 @@ void show_log(struct rev_info *opt)
 			 */
 			show_reflog_message(opt->reflog_info,
 				    opt->commit_format == CMIT_FMT_ONELINE,
-				    opt->date_mode);
+				    opt->date_mode_explicit ?
+					opt->date_mode :
+					DATE_NORMAL);
 			if (opt->commit_format == CMIT_FMT_ONELINE)
 				return;
 		}
diff --git a/revision.c b/revision.c
index 9eb7951..5988b6c 100644
--- a/revision.c
+++ b/revision.c
@@ -1159,8 +1159,10 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg
 		revs->simplify_history = 0;
 	} else if (!strcmp(arg, "--relative-date")) {
 		revs->date_mode = DATE_RELATIVE;
+		revs->date_mode_explicit = 1;
 	} else if (!strncmp(arg, "--date=", 7)) {
 		revs->date_mode = parse_date_format(arg + 7);
+		revs->date_mode_explicit = 1;
 	} else if (!strcmp(arg, "--log-size")) {
 		revs->show_log_size = 1;
 	}
diff --git a/revision.h b/revision.h
index 9d0dddb..b6421a6 100644
--- a/revision.h
+++ b/revision.h
@@ -81,7 +81,8 @@ struct rev_info {
 			show_merge:1,
 			abbrev_commit:1,
 			use_terminator:1,
-			missing_newline:1;
+			missing_newline:1,
+			date_mode_explicit:1;
 	enum date_mode date_mode;
 
 	unsigned int	abbrev;
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]