Re: orthogonal cases of log --date option

Jeff King [off-list ref] writes:

Because from the user's perspective --foo={bar,baz,bleep} is about
selecting exactly one of {bar,baz,bleep}.

I do not feel very strongly about this either way, and without any prior
end user "Huh?" input, I would probably have argued like you myself, but
I saw the original message from Miles about giving more than one --date
and getting perplexed to see that it did not work, so...

I am not likely to use --tz=Indian/Christmas myself; GMT and local might
however be useful in some situations, though.

On Fri, Mar 6, 2009 at 1:50 AM, Junio C Hamano [off-list ref] wrote:

Jeff King [off-list ref] writes:

quoted

Because from the user's perspective --foo={bar,baz,bleep} is about
selecting exactly one of {bar,baz,bleep}.

I do not feel very strongly about this either way, and without any prior
end user "Huh?" input, I would probably have argued like you myself, but
I saw the original message from Miles about giving more than one --date
and getting perplexed to see that it did not work, so...

I am not likely to use --tz=Indian/Christmas myself; GMT and local might
however be useful in some situations, though.

So I don't mind picking this up, but I'd like some guidance. There are
two issues:

1) The CLI. You and Jeff don't seem to have an agreement here, but
frankly, this is the easy part.

2) The internal implementation. Your implementation (enum -> bitfield)
is clever, but Jeff seems to prefer what I suggested (going to a
struct). The latter is quite a bit more work.

If we only care about fixing the original issue, I'll just pickup your
patch, make sure it compiles, and add some tests. I certainly don't
want to do more work than is needed, unless there's  a good reason to
do so.

j.

Jay Soffian [off-list ref] writes:

On Fri, Mar 6, 2009 at 1:50 AM, Junio C Hamano [off-list ref] wrote:

quoted

Jeff King [off-list ref] writes:

quoted

Because from the user's perspective --foo={bar,baz,bleep} is about
selecting exactly one of {bar,baz,bleep}.

I do not feel very strongly about this either way, and without any prior
end user "Huh?" input, I would probably have argued like you myself, but
I saw the original message from Miles about giving more than one --date
and getting perplexed to see that it did not work, so...

I am not likely to use --tz=Indian/Christmas myself; GMT and local might
however be useful in some situations, though.

So I don't mind picking this up, but I'd like some guidance. There are
two issues:

1) The CLI. You and Jeff don't seem to have an agreement here, but
frankly, this is the easy part.

2) The internal implementation. Your implementation (enum -> bitfield)
is clever, but Jeff seems to prefer what I suggested (going to a
struct). The latter is quite a bit more work.

Is it?  Isn't it just the matter of doing something like this?

	struct date_mode {
        	enum {
                DATE_NORMAL = 0,
                DATE_RELATIVE,
                ...
                DATE_RAW
                } format;
                enum {
                DATE_ORIGINAL = 0,
                DATE_LOCAL
                /* perhaps ",DATE_GMT" later... */
                } tz_offset;
	};

	/* In revision.c::handle_revision_opt() */
        ...
	} else if (!strcmp(arg, "--date=local")) {
		revs->date_mode.format = DATE_NORMAL;
        	revs->date_mode.tz_offset = DATE_LOCAL;
	} else if (!prefixcmp(arg, "--date=")) {
        	revs->date_mode.format = parse_date_format(arg + 7);
	} else if (!strcmp(arg, "--tz=local")) {
        	revs->date_mode.tz_offset = DATE_LOCAL;
	}
	...

        /* In date.c::show_date() */
	...
        const char *show_date(unsigned long time, int tz, struct date_mode *mode_)
	{
        	int mode = mode_->format;

		if (mode_->tz_offset == DATE_LOCAL)
			tz = local_tzoffset(time);

		...
		/* and remove the existing
                if (mode == DATE_LOCAL)
                	tz = local_tzoffset(time);
		   that appears later in the code
		*/
	...

On Fri, Mar 6, 2009 at 3:02 AM, Junio C Hamano [off-list ref] wrote:

Is it?  Isn't it just the matter of doing something like this?

       struct date_mode {
               enum {
               DATE_NORMAL = 0,
               DATE_RELATIVE,
               ...
               DATE_RAW
               } format;
               enum {
               DATE_ORIGINAL = 0,
               DATE_LOCAL
               /* perhaps ",DATE_GMT" later... */
               } tz_offset;
       };

       /* In revision.c::handle_revision_opt() */
       ...
       } else if (!strcmp(arg, "--date=local")) {
               revs->date_mode.format = DATE_NORMAL;
               revs->date_mode.tz_offset = DATE_LOCAL;
       } else if (!prefixcmp(arg, "--date=")) {
               revs->date_mode.format = parse_date_format(arg + 7);
       } else if (!strcmp(arg, "--tz=local")) {
               revs->date_mode.tz_offset = DATE_LOCAL;
       }
       ...

       /* In date.c::show_date() */
       ...
       const char *show_date(unsigned long time, int tz, struct date_mode *mode_)
       {
               int mode = mode_->format;

               if (mode_->tz_offset == DATE_LOCAL)
                       tz = local_tzoffset(time);

               ...
               /* and remove the existing
               if (mode == DATE_LOCAL)
                       tz = local_tzoffset(time);
                  that appears later in the code
               */
       ...

Yeah, that part is easy. I wasn't sure the best way to handle places
where a constant date_mode is used e.g.:

pp_user_info(NULL, CMIT_FMT_EMAIL, &sb, committer, DATE_RFC2822,
		     encoding);

I had started on:

static const struct date_mode date_rfc2822 = {DATE_RFC2822, DATE_ORIGINAL};
...
pp_user_info(NULL, CMIT_FMT_EMAIL, &sb, committer, &date_rfc2822,
		     encoding);

But I imagine there's maybe a better way to do that.

j.

On Thu, Mar 05, 2009 at 10:50:42PM -0800, Junio C Hamano wrote:

quoted

Because from the user's perspective --foo={bar,baz,bleep} is about
selecting exactly one of {bar,baz,bleep}.

I do not feel very strongly about this either way, and without any prior
end user "Huh?" input, I would probably have argued like you myself, but
I saw the original message from Miles about giving more than one --date
and getting perplexed to see that it did not work, so...

Interesting. I saw the original message from Miles as "I tried to use
more than one --date, but that seems wrong to me because these concepts
are orthogonal".  But I do recognize that it is somewhat a matter of
perception and style.

Anyway, as our one user in this thread, he has said the separate option
is more clear. So I think we should go with that.

-Peff

On Fri, Mar 06, 2009 at 01:58:36AM -0500, Jay Soffian wrote:

1) The CLI. You and Jeff don't seem to have an agreement here, but
frankly, this is the easy part.

2) The internal implementation. Your implementation (enum -> bitfield)
is clever, but Jeff seems to prefer what I suggested (going to a
struct). The latter is quite a bit more work.

My argument for (2), btw, is that the code is easier to read and more
maintainable if it follows the structure of the CLI. But I don't think
it's as important as getting the CLI right.

-Peff