- 14 11月, 2008 1 次提交
-
-
由 Linus Torvalds 提交于
The date/time parsing code was confused if the input time HH:MM:SS is followed by fractional seconds. Since we do not record anything finer grained than seconds, we could just drop fractional part, but there is a twist. We have taught people that not just spaces but dot can be used as word separators when spelling things like: $ git log --since 2.days $ git show @{12:34:56.7.days.ago} and we shouldn't mistake "7" in the latter example as a fraction and discard it. The rules are: - valid days of month/mday are always single or double digits. - valid years are either two or four digits No, we don't support the year 600 _anyway_, since our encoding is based on the UNIX epoch, and the day we worry about the year 10,000 is far away and we can raise the limit to five digits when we get closer. - Other numbers (eg "600 days ago") can have any number of digits, but they cannot start with a zero. Again, the only exception is for two-digit numbers, since that is fairly common for dates ("Dec 01" is not unheard of) So that means that any milli- or micro-second would be thrown out just because the number of digits shows that it cannot be an interesting date. A milli- or micro-second can obviously be a perfectly fine number according to the rules above, as long as it doesn't start with a '0'. So if we have 12:34:56.123 then that '123' gets parsed as a number, and we remember it. But because it's bigger than 31, we'll never use it as such _unless_ there is something after it to trigger that use. So you can say "12:34:56.123.days.ago", and because of the "days", that 123 will actually be meaninful now. Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 23 6月, 2008 1 次提交
-
-
由 Johannes Sixt 提交于
We will use it from the MinGW port's gettimeofday() substitution. Signed-off-by: NJohannes Sixt <johannes.sixt@telecom.at>
-
- 18 6月, 2008 1 次提交
-
-
由 Olivier Marin 提交于
Commit af66366a introduced the keyword "never" to be used with approxidate() but defined it with a fixed date without taking care of timezone. As a result approxidate() will return a timestamp in the future with a negative timezone. With this patch, approxidate("never") always return 0 whatever your timezone is. Signed-off-by: NOlivier Marin <dkr@freesurf.fr> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 26 2月, 2008 1 次提交
-
-
由 Steven Drake 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 30 9月, 2007 1 次提交
-
-
由 Andy Parkins 提交于
Factor out the code to parse --date=<format> parameter to revision walkers into a separate function, parse_date_format(). This function is passed a string and converts it to an enum date_format: - "relative" => DATE_RELATIVE - "iso8601" or "iso" => DATE_ISO8601 - "rfc2822" => DATE_RFC2822 - "short" => DATE_SHORT - "local" => DATE_LOCAL - "default" => DATE_NORMAL In the event that none of these strings is found, the function die()s. Signed-off-by: NAndy Parkins <andyparkins@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 25 7月, 2007 1 次提交
-
-
由 Johannes Schindelin 提交于
If you want to keep the reflogs around for a really long time, you should be able to say so: $ git config gc.reflogExpire never Now it works, too. Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 14 7月, 2007 2 次提交
-
-
由 Junio C Hamano 提交于
These days, show_date() takes a date_mode parameter to specify the output format, and a separate specialized function for dates in E-mails does not make much sense anymore. This retires show_rfc2822_date() function and make it just another date output format. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Robin Rosenberg 提交于
Support output of full ISO 8601 style dates in e.g. git log and other places that use interpolation for formatting. Signed-off-by: NRobin Rosenberg <robin.rosenberg@dewire.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 07 6月, 2007 2 次提交
-
-
由 Junio C Hamano 提交于
This uses "git-apply --whitespace=strip" to fix whitespace errors that have crept in to our source files over time. There are a few files that need to have trailing whitespaces (most notably, test vectors). The results still passes the test, and build result in Documentation/ area is unchanged. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Johannes Sixt 提交于
Tests with git-filter-branch on a repository that was converted from CVS and that has commits reaching back to 1999 revealed that it is necessary to parse dates before 2000/01/01 when they are specified as seconds since 1970/01/01. There is now still a limit, 100000000, which is 1973/03/03 09:46:40 UTC, in order to allow that dates are represented as 8 digits. Signed-off-by: NJohannes Sixt <johannes.sixt@telecom.at> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 26 4月, 2007 1 次提交
-
-
由 Junio C Hamano 提交于
This adds --date={local,relative,default} option to log family of commands, to allow displaying timestamps in user's local timezone, relative time, or the default format. Existing --relative-date option is a synonym of --date=relative; we could probably deprecate it in the long run. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 28 2月, 2007 1 次提交
-
-
由 Johannes Schindelin 提交于
Now, show_date() can print three different kinds of dates: normal, relative and short (%Y-%m-%s) dates. To achieve this, the "int relative" was changed to "enum date_mode mode", which has three states: DATE_NORMAL, DATE_RELATIVE and DATE_SHORT. Since existing users of show_date() only call it with relative_date being either 0 or 1, and DATE_NORMAL and DATE_RELATIVE having these values, no behaviour is changed. Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 21 1月, 2007 1 次提交
-
-
由 Johannes Schindelin 提交于
We pass a timestamp (i.e. number of seconds elapsed since Jan 1 1970, 00:00:00 GMT) to the function. So there is no need to "fix" the timestamp according to the timezone. Signed-off-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de>
-
- 21 12月, 2006 1 次提交
-
-
由 Junio C Hamano 提交于
This is a mechanical clean-up of the way *.c files include system header files. (1) sources under compat/, platform sha-1 implementations, and xdelta code are exempt from the following rules; (2) the first #include must be "git-compat-util.h" or one of our own header file that includes it first (e.g. config.h, builtin.h, pkt-line.h); (3) system headers that are included in "git-compat-util.h" need not be included in individual C source files. (4) "git-compat-util.h" does not have to include subsystem specific header files (e.g. expat.h). Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 30 9月, 2006 1 次提交
-
-
由 Linus Torvalds 提交于
It just simplifies the whole thing to say "hour = (hour % 12) + X" where X is 12 for PM and 0 for AM. It also fixes the "exact date" parsing, which didn't parse AM at all, and as such would do the same "12:30 AM" means "12:30 24-hour-format" bug. Of course, I hope that no exact dates use AM/PM anyway, but since we support the PM format, let's just get it right. Signed-off-by: NLinus Torvalds <torvalds@osdl.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 29 9月, 2006 2 次提交
-
-
由 Linus Torvalds 提交于
You can now say "5:35 PM yesterday", and approxidate() gets the right answer. Signed-off-by: NLinus Torvalds <torvalds@osdl.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Linus Torvalds 提交于
Our approxidate cannot handle simple times like "5 PM yesterday", and to fix that, we will need to add some logic for number handling. This just splits that out into a function of its own (the same way the _real_ date parsing works). Signed-off-by: NLinus Torvalds <torvalds@osdl.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 27 8月, 2006 1 次提交
-
-
由 Linus Torvalds 提交于
I noticed that I was looking at the kernel gitweb output at some point rather than just do "git log", simply because I liked seeing the simplified date-format, ie the "5 days ago" rather than a full date. This adds infrastructure to do that for "git log" too. It does NOT add the actual flag to enable it, though, so right now this patch is a no-op, but it should now be easy to add a command line flag (and possibly a config file option) to just turn on the "relative" date format. The exact cut-off points when it switches from days to weeks etc are totally arbitrary, but are picked somewhat to avoid the "1 weeks ago" thing (by making it show "10 days ago" rather than "1 week", or "70 minutes ago" rather than "1 hour ago"). [jc: with minor fix and tweak around "month" and "week" area.] Signed-off-by: NLinus Torvalds <torvalds@osdl.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 24 8月, 2006 1 次提交
-
-
由 Pierre Habouzit 提交于
date.c::approxidate_alpha() counts the number of alphabets while moving the pointer but does not use the count. Signed-off-by: NPierre Habouzit <madcoder@debian.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 09 6月, 2006 1 次提交
-
-
由 Paul Eggert 提交于
When match_digit() guesses a four-digit string to tell if it is a year or a timezone, it did not consider that some real-world places have UTC offsets equal to +1400. $ date; TZ=UTC0 date; TZ=Pacific/Kiritimati date Wed Jun 7 23:25:42 PDT 2006 Thu Jun 8 06:25:42 UTC 2006 Thu Jun 8 20:25:42 LINT 2006 Signed-off-by: NPaul Eggert <eggert@CS.UCLA.EDU> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 01 5月, 2006 1 次提交
-
-
由 Junio C Hamano 提交于
Still Work-in-progress git fmt-patch (should it be known as format-patch-ng?) is matched with the fix made by Huw Davies in 262a6ef7 commit to use RFC2822 date format. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 06 4月, 2006 1 次提交
-
-
由 Junio C Hamano 提交于
This does three things, only applies to cases where the user manually tries to override the author/commit time by environment variables, with non-ISO, non-2822 format date-string: - Refuses to use the interpretation to put the date in the future; recent kernel history has a commit made with 10/03/2006 which is recorded as October 3rd. - Adds '.' as the possible year-month-date separator. We learned from our European friends on the #git channel that dd.mm.yyyy is the norm there. - When the separator is '.', we prefer dd.mm.yyyy over mm.dd.yyyy; otherwise mm/dd/yy[yy] takes precedence over dd/mm/yy[yy]. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 05 4月, 2006 1 次提交
-
-
由 Junio C Hamano 提交于
The comment associated with the date parsing code for three numbers separated with slashes or dashes implied we wanted to interpret using this order: yyyy-mm-dd yyyy-dd-mm mm-dd-yy dd-mm-yy However, the actual code had the last two wrong, and making it prefer dd-mm-yy format over mm-dd-yy. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 10 3月, 2006 1 次提交
-
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 06 1月, 2006 1 次提交
-
-
由 Linus Torvalds 提交于
Stupid me. If approxidate ends up with a month that is ahead of the current month, it decrements the year to last year. Which is correct, and means that "last december" does the right thing. HOWEVER. It should only do so if the year is the same as the current year. Without this fix, "5 days ago" ends up being in 2004, because it first decrements five days, getting us to December 2005 (correct), but then it also ends up decrementing the year once more to turn that December into "last year" (incorrect, since it already _was_ last year). Duh. Pass me a donut. Signed-off-by: NLinus Torvalds <torvalds@osdl.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 29 12月, 2005 1 次提交
-
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 19 11月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
On Fri, 18 Nov 2005, David Roundy wrote: > > Don't forget "high noon"! (and perhaps "tea time"?) :) Done. [torvalds@g5 git]$ ./test-date "now" "midnight" "high noon" "tea-time" now -> bad -> Wed Dec 31 16:00:00 1969 now -> Fri Nov 18 08:50:54 2005 midnight -> bad -> Wed Dec 31 16:00:00 1969 midnight -> Fri Nov 18 00:00:00 2005 high noon -> bad -> Wed Dec 31 16:00:00 1969 high noon -> Thu Nov 17 12:00:00 2005 tea-time -> bad -> Wed Dec 31 16:00:00 1969 tea-time -> Thu Nov 17 17:00:00 2005 Thanks for pointing out tea-time. This is also written to easily extended to allow people to add their own important dates like Christmas and their own birthdays. Signed-off-by: NLinus Torvalds <torvalds@osdl.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 18 11月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
This allows people to use syntax like "last thursday" for the approxidate. (Or, indeed, more complex "three thursdays ago", but I suspect that would be pretty unusual). NOTE! The parsing is strictly sequential, so if you do "one day before last thursday" it will _not_ do what you think it does. It will take the current time, subtract one day, and then go back to the thursday before that. So to get what you want, you'd have to write it the other way around: "last thursday and one day before" which is insane (it's usually the same as "last wednesday" _except_ if today is Thursday, in which case "last wednesday" is yesterday, and "last thursday and one day before" is eight days ago). Similarly, "last thursday one month ago" will first go back to last thursday, and then go back one month from there, not the other way around. I doubt anybody would ever use insane dates like that, but I thought I'd point out that the approxidate parsing is not exactly "standard English". Side note 2: if you want to avoid spaces (because of quoting issues), you can use any non-alphanumberic character instead. So git log --since=2.days.ago works without any quotes. Signed-off-by: NLinus Torvalds <torvalds@osdl.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 17 11月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
Ok. This is the insane patch to do this. It really isn't very careful, and the reason I call it "approxidate()" will become obvious when you look at the code. It is very liberal in what it accepts, to the point where sometimes the results may not make a whole lot of sense. It accepts "last week" as a date string, by virtue of "last" parsing as the number 1, and it totally ignoring superfluous fluff like "ago", so "last week" ends up being exactly the same thing as "1 week ago". Fine so far. It has strange side effects: "last december" will actually parse as "Dec 1", which actually _does_ turn out right, because it will then notice that it's not December yet, so it will decide that you must be talking about a date last year. So it actually gets it right, but it's kind of for the "wrong" reasons. It also accepts the numbers 1..10 in string format ("one" .. "ten"), so you can do "ten weeks ago" or "ten hours ago" and it will do the right thing. But it will do some really strange thigns too: the string "this will last forever", will not recognize anyting but "last", which is recognized as "1", which since it doesn't understand anything else it will think is the day of the month. So if you do gitk --since="this will last forever" the date will actually parse as the first day of the current month. And it will parse the string "now" as "now", but only because it doesn't understand it at all, and it makes everything relative to "now". Similarly, it doesn't actually parse the "ago" or "from now", so "2 weeks ago" is exactly the same as "2 weeks from now". It's the current date minus 14 days. But hey, it's probably better (and certainly faster) than depending on GNU date. So now you can portably do things like gitk --since="two weeks and three days ago" git log --since="July 5" git-whatchanged --since="10 hours ago" git log --since="last october" and it will actually do exactly what you thought it would do (I think). It will count 17 days backwards, and it will do so even if you don't have GNU date installed. (I don't do "last monday" or similar yet, but I can extend it to that too if people want). It was kind of fun trying to write code that uses such totally relaxed "understanding" of dates yet tries to get it right for the trivial cases. The result should be mixed with a few strange preprocessor tricks, and be submitted for the IOCCC ;) Feel free to try it out, and see how many strange dates it gets right. Or wrong. And if you find some interesting (and valid - not "interesting" as in "strange", but "interesting" as in "I'd be interested in actually doing this) thing it gets wrong - usually by not understanding it and silently just doing some strange things - please holler. Now, as usual this certainly hasn't been getting a lot of testing. But my code always works, no? Linus Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 15 10月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
Do our own ctype.h, just to get the sane semantics: we want locale-independence, _and_ we want the right signed behaviour. Plus we only use a very small subset of ctype.h anyway (isspace, isalpha, isdigit and isalnum). Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 22 9月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
We generate the ASCII representation of our internal date representation ("seconds since 1970, UTC + timezone information") in two different places. One of them uses the stupid and obvious way to make sure that it gets the sexagecimal representation right for negative timezones even if they might not be exact hours, and the other one depends on the modulus operator always matching the sign of argument. Hey, the clever one works. And C90 even specifies that behaviour. But I had to think about it for a while when I was re-visiting this area, and even if I didn't have to, it's kind of strange to have two different ways to print out the same data format. So use a common helper for this. And select the stupid and straighforward way. Signed-off-by: NLinus Torvalds <torvalds@osdl.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 21 9月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
Right now we don't return any error value at all from parse_date(), and if we can't parse it, we just silently leave the result buffer unchanged. That's fine for the current user, which will always default to the current date, but it's a crappy interface, and we might well be better off with an error message rather than just the default date. So let's change the thing to return a negative value if an error occurs, and the length of the result otherwise (snprintf behaviour: if the buffer is too small, it returns how big it _would_ have been). [ I started looking at this in case we could support date-based revision names. Looks ugly. Would have to parse relative dates.. ] Signed-off-by: NLinus Torvalds <torvalds@osdl.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 13 7月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
This is part of breaking up the tag ID patch by Eric Biederman.
-
- 26 6月, 2005 1 次提交
-
-
由 Junio C Hamano 提交于
Usually all of the match_xxx routines in date.c fill tm structure assuming that the parsed string talks about local time, and parse_date routine compensates for it by adjusting the value with tz offset parsed out separately. However, this logic does not work well when we feed GIT raw commit timestamp to it, because what match_digits gets is already in GMT. A good testcase is: $ make test-date $ ./test-date 'Fri Jun 24 16:55:27 2005 -0700' '1119657327 -0700' These two timestamps represent the same time, but the second one without the fix this commit introduces gives you 7 hours off. Signed-off-by: NJunio C Hamano <junkio@cox.net> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 23 5月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
Add <limits.h> to the include files handled by "cache.h", and remove extraneous #include directives from various .c files. The rule is that "cache.h" gets all the basic stuff, so that we'll have as few system dependencies as possible.
-
- 21 5月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
Fix various things that sparse complains about: - use NULL instead of 0 - make sure we declare everything properly, or mark it static - use proper function declarations ("fn(void)" instead of "fn()") Sparse is always right.
-
- 19 5月, 2005 1 次提交
-
-
由 Nicolas Pitre 提交于
Signed-off-by: NNicolas Pitre <nico@cam.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 07 5月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
Kind of like ctime(), but not as broken.
-
- 02 5月, 2005 2 次提交
-
-
由 Linus Torvalds 提交于
And be a bitmore careful about matching: if we don't recognize a word or a number, we skip the whole thing, rather than trying the next character in that word/number. Finally: since ctime() adds the final '\n', don't add another one in test-date.
-
由 Linus Torvalds 提交于
(and some added checks for truly non-sensical stuff)
-