* Re: What's cooking in git.git (Aug 2009, #05; Wed, 26)
From: Daniel Barkalow @ 2009-08-30 1:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfxbeb0mt.fsf@alter.siamese.dyndns.org>
On Wed, 26 Aug 2009, Junio C Hamano wrote:
> * db/vcs-helper (2009-08-09) 17 commits
> - Allow helpers to request marks for fast-import
> - Allow helpers to report in "list" command that the ref is unchanged
> - Add support for "import" helper command
> - transport-helper_init(): fix a memory leak in error path
> - Add a config option for remotes to specify a foreign vcs
> - Allow programs to not depend on remotes having urls
> - Allow fetch to modify refs
> - Use a function to determine whether a remote is valid
> - Use a clearer style to issue commands to remote helpers
> (merged to 'next' on 2009-08-07 at f3533ba)
> + Makefile: install hardlinks for git-remote-<scheme> supported by libcurl if possible
> + Makefile: do not link three copies of git-remote-* programs
> + Makefile: git-http-fetch does not need expat
> (merged to 'next' on 2009-08-06 at 15da79d)
> + http-fetch: Fix Makefile dependancies
> + Add transport native helper executables to .gitignore
> (merged to 'next' on 2009-08-05 at 33d491e)
> + git-http-fetch: not a builtin
> + Use an external program to implement fetching with curl
> + Add support for external programs for handling native fetches
> (this branch is used by jh/cvs-helper.)
>
> There was a discussion that suggests that the use of colon ':' before vcs
> helper name needs to be corrected. Nothing happened since.
I believe the outcome of that discussion was:
- We want to keep supporting using regular location URLs that are URLs of
git repositories (e.g., http://git.savannah.gnu.org/cgit/xboard.git),
and we probably want to do it with a helper which runs when
run_command() is given "remote-<scheme>". I think installing hardlinks
in EXECPATH ended up being the best implementation here. This is
currently a special case, because these URLs have push handled
internally (or, rather, with internal code calling a different external
program), but I think we want to make it no longer special at all, so
that people can install the handling for access to native repos via
dumb filesystem-like protocols separately. This is in next.
- We want to support a separate "vcs" option for cases where repositories
in the foreign system need to be addressed through the combination of a
bunch of options, which will be read from the configuration by the
helper. The helper which gets run is "remote-<value of vcs option>".
This is in pu.
- We want to support URLs of some sort leading to using helpers
appropriate for foreign systems that use URLs and are most conveniently
located this way. We didn't come to any concensus on what this should
do, but we also haven't had any helpers proposed yet that would use it,
and the series doesn't include any code that would lead to running a
helper other than in one of the above two cases. (jh's cvs helper
clearly wants "cvsroot" and "cvsmodule" options, and my p4 helper wants
"port" and "codeline" options; SVN is the big use cases for URLs, but
nobody's tackled that as a helper)
So I think this issue is squarely in "future work" anyway, and the current
part of the series should be able to move forward, unless I've missed some
other issue.
Of course, there are a bunch of things that are beyond the present
contents of the series, but I think there's nothing wrong in the series as
it is, and it's worthwhile without any further patches.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: What's cooking in git.git (Aug 2009, #05; Wed, 26)
From: Junio C Hamano @ 2009-08-30 4:06 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <alpine.LNX.2.00.0908292116060.28290@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
>> There was a discussion that suggests that the use of colon ':' before vcs
>> helper name needs to be corrected. Nothing happened since.
>
> I believe the outcome of that discussion was:
>
> - We want to keep supporting using regular location URLs that are URLs of
> git repositories (e.g., http://git.savannah.gnu.org/cgit/xboard.git),
> and we probably want to do it with a helper which runs when
> run_command() is given "remote-<scheme>". I think installing hardlinks
> in EXECPATH ended up being the best implementation here.
That is different from what I recall.
I think you said <scheme> in the above to mean that in the general URL
syntax, <scheme> refers to the token before the colon, and you would be
feeding the rest (i.e. after the colon, and for many <scheme>'s it
typically begins with //) to the scheme.
A flaw with this that was pointed out was that this conflicts with the
scp-like syntax. A remote.$name.url of foo:bar/baz could name
$HOME/bar/baz on host foo (perhaps a nickname in .ssh/config), or the
source "foo" helper recognizes with the name bar/baz.
If I recall correctly, suggestions made later in the discussion were to
use either <helper>+ or <helper>:: as the prefix to avoid this issue, and
use it to choose remote-<helper> (and I think I probably would vote for
double-colon, if only to avoid confusion with our own earlier misdesigned
syntax git+ssh://), so the canonical syntax would be:
<helper>::<whatever is fed to the helper, typicall a URL>
while we would support obvious short-hands for transports we traditionally
supported without explicit "<helper>::" prefix when we choose to eject it
from "built-in" set of transports.
E.g. http://git.savannah.gnu.org/cgit/xboard.git would be handled by curl
based walker, so if you spell it in the very canonical form, the url would
be curl::http://git.savannah.gnu.org/cgit/xboard.git, but nobody has to
use it. Instead, the transport dispatcher internally recognizes http://
and picks the curl based walker helper, which is remote-curl without any
extra hardlinks.
And from my point of view, this is what is blocking the series; and there
still is no -rc0 yet (I've been hoping to do a 1.6.5 mid September before
I leave for Japan for about a week), because I think it is pointless to do
a new release without "the ejection of curl from builtin".
> - We want to support a separate "vcs" option for cases where repositories
> in the foreign system need to be addressed through the combination of a
> bunch of options, which will be read from the configuration by the
> helper. The helper which gets run is "remote-<value of vcs option>".
> This is in pu.
After you explained this in the thread (I think for the second time), I
see no problem with this, except that I think to support this we should
notice and raise an error when we see a remote has both vcs and url,
because the only reason we would want to say "vcs", if I recall your
explanation correctly, is that such a transport does not have the concept
of URL, i.e. a well defined single string that identifies the repository.
^ permalink raw reply
* Anyone meet DNS fail translate repo.or.cz
From: Frank Li @ 2009-08-30 4:20 UTC (permalink / raw)
To: git
ALL:
I can't access repo.or.cz from yesterday.
DNS can't translate repo.or.cz.
Even
http://www.dnswatch.info/dns/dnslookup?la=en&host=repo.or.cz&type=A
It also can't recognize repo.or.cz.
Anyone meet the same problem?
best regards
Frank Li
^ permalink raw reply
* [ANNOUNCE] GIT 1.6.4.2
From: Junio C Hamano @ 2009-08-30 6:30 UTC (permalink / raw)
To: git
The latest maintenance release GIT 1.6.4.2 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.6.4.2.tar.{gz,bz2} (source tarball)
git-htmldocs-1.6.4.2.tar.{gz,bz2} (preformatted docs)
git-manpages-1.6.4.2.tar.{gz,bz2} (preformatted docs)
The RPM binary packages for a few architectures are found in:
RPMS/$arch/git-*-1.6.4.2-1.fc9.$arch.rpm (RPM)
GIT v1.6.4.2 Release Notes
==========================
Fixes since v1.6.4.1
--------------------
* --date=relative output between 1 and 5 years ago rounded the number of
years when saying X years Y months ago, instead of rounding it down.
* "git add -p" did not handle changes in executable bits correctly
(a regression around 1.6.3).
* "git apply" did not honor GNU diff's convention to mark the creation/deletion
event with UNIX epoch timestamp on missing side.
* "git checkout" incorrectly removed files in a directory pointed by a
symbolic link during a branch switch that replaces a directory with
a symbolic link.
* "git clean -d -f" happily descended into a subdirectory that is managed by a
separate git repository. It now requires two -f options for safety.
* "git fetch/push" over http transports had two rather grave bugs.
* "git format-patch --cover-letter" did not prepare the cover letter file
for use with non-ASCII strings when there are the series contributors with
non-ASCII names.
* "git pull origin branch" and "git fetch origin && git merge origin/branch"
left different merge messages in the resulting commit.
Other minor documentation updates are included.
^ permalink raw reply
* Re: [PATCH] Allow testing of _relative family of time formatting and parsing functions
From: Alex Riesen @ 2009-08-30 7:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Nicolas Pitre, David Reiss, git
In-Reply-To: <7vk50mz41e.fsf@alter.siamese.dyndns.org>
On Sat, Aug 29, 2009 at 23:46, Junio C Hamano<gitster@pobox.com> wrote:
> Alex Riesen <raa.lkml@gmail.com> writes:
>> To complement the testability of approxidate.
>> ---
>> Alex Riesen, Fri, Aug 28, 2009 21:33:02 +0200:
>>>
>>> It should allow safe testing of this part of the code.
>>
>> And this should really allow testing of it:
>>
>> $ ./test-date '10.days.ago'
>> 10.days.ago -> bad -> Thu Jan 1 01:00:00 1970
>> 10.days.ago -> Tue Aug 18 22:50:20 2009
>>
>> relative: 10.days.ago -> Fri Dec 22 12:00:00 1989
>>
>> relative: 10 days ago, out of Fri Dec 22 12:00:00 1989
>>
>> $
>
> What are these blank lines for?
ctime(3) artifact (it adds a \n in the output buffer), which I missed.
> Is this intended as a serious submission for inclusion?
Not yet. AFAICS, test-date is never used in our test suite.
> I am having a hrad time to guess, especially you did not
> sign this off, nor Cc'ed me.
Right, that's because I'm not sure myself. Frankly, I'm not
convinced we have to test every single thing. In my experience,
the bigger a test suite, the less are people inclined to use it
(including setting up automatic test runs).
Jeff, Nicolas? Is this test enough? Are there any other code
paths you want to include in the test?
And sorry for having you missed in Cc:, that wasn't intended.
^ permalink raw reply
* Re: [PATCH 1/2] Add date formatting and parsing functions relative to a given time
From: Jeff King @ 2009-08-30 7:36 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Nicolas Pitre, David Reiss, Junio C Hamano
In-Reply-To: <20090828210404.GA11867@blimp.localdomain>
On Fri, Aug 28, 2009 at 11:04:04PM +0200, Alex Riesen wrote:
> +const char *show_date_relative(unsigned long time, int tz, const struct timeval *now)
> +{
> + static char timebuf[100 /* TODO: can be optimized */];
This was 200 in the original version. I doubt that it makes a
difference, but I think in a refactoring patch I think it is best to
simply reorganize and make no other changes.
> +static unsigned long approximation(const char *date, const struct timeval *tv)
I know it's static, but this is a terribly undescriptive function name.
Approximation of what? Can we call it approxidate_internal or
something?
-Peff
^ permalink raw reply
* Re: [PATCH 1/2] Add date formatting and parsing functions relative to a given time
From: Alex Riesen @ 2009-08-30 7:51 UTC (permalink / raw)
To: Jeff King; +Cc: git, Nicolas Pitre, David Reiss, Junio C Hamano
In-Reply-To: <20090830073619.GA14217@coredump.intra.peff.net>
On Sun, Aug 30, 2009 at 09:36, Jeff King<peff@peff.net> wrote:
> On Fri, Aug 28, 2009 at 11:04:04PM +0200, Alex Riesen wrote:
>
>> +const char *show_date_relative(unsigned long time, int tz, const struct timeval *now)
>> +{
>> + static char timebuf[100 /* TODO: can be optimized */];
>
> This was 200 in the original version. I doubt that it makes a
> difference, but I think in a refactoring patch I think it is best to
> simply reorganize and make no other changes.
Yes, I just noticed that 200 was much too much, made the note
to fix it sometime and forgot the note in the final submission.
>> +static unsigned long approximation(const char *date, const struct timeval *tv)
>
> I know it's static, but this is a terribly undescriptive function name.
> Approximation of what? Can we call it approxidate_internal or
> something?
Been there, tried that. Didn't like it, because it didn't feel enough
approxidate (the original) anymore. Not even internally, because
of missing parse_date. My other attempts were guessdate and
approxidate_bottom_half (but only very shortly).
The "approximation", if you consider the functions arguments,
seems to me the closest to what the function _is_. OTOH,
maybe I should have used a verb...
^ permalink raw reply
* Re: [PATCH] Allow testing of _relative family of time formatting and parsing functions
From: Jeff King @ 2009-08-30 7:51 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, Nicolas Pitre, David Reiss, git
In-Reply-To: <81b0412b0908300025r4eeee84fyf0bfc3b2e940ff37@mail.gmail.com>
On Sun, Aug 30, 2009 at 09:25:11AM +0200, Alex Riesen wrote:
> > Is this intended as a serious submission for inclusion?
>
> Not yet. AFAICS, test-date is never used in our test suite.
No, it isn't, but I think the point of this is to change that.
So it is useless without an extra patch to the test suite. I'll try to
put something together.
> Right, that's because I'm not sure myself. Frankly, I'm not
> convinced we have to test every single thing. In my experience,
> the bigger a test suite, the less are people inclined to use it
> (including setting up automatic test runs).
>
> Jeff, Nicolas? Is this test enough? Are there any other code
> paths you want to include in the test?
I think this is a useful addition to the test suite. The bug David fixed
was obvious, but it sat for a year because of poor test coverage. Linus
fixed several approxidate bugs recently. The approxidate code is
notoriously temperamental, so it is a good thing to be checking for
regressions.
And I don't think our test suite is nearly big enough to start worrying
about getting people not to use it. Without CVS and SVN tests, I can run
it on 3-year-old hardware in less than a minute. Either you bother to
run it or not, but I doubt that adding one new test script is going to
break the bank.
-Peff
^ permalink raw reply
* Re: [PATCH] Allow testing of _relative family of time formatting and parsing functions
From: Alex Riesen @ 2009-08-30 8:10 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Nicolas Pitre, David Reiss, git
In-Reply-To: <20090830075140.GB14217@coredump.intra.peff.net>
On Sun, Aug 30, 2009 at 09:51, Jeff King<peff@peff.net> wrote:
> On Sun, Aug 30, 2009 at 09:25:11AM +0200, Alex Riesen wrote:
>
>> > Is this intended as a serious submission for inclusion?
>>
>> Not yet. AFAICS, test-date is never used in our test suite.
>
> No, it isn't, but I think the point of this is to change that.
> So it is useless without an extra patch to the test suite. I'll try to
> put something together.
Thanks :)
^ permalink raw reply
* Re: vc in emacs problem with git
From: Rustom Mody @ 2009-08-30 8:54 UTC (permalink / raw)
To: help-gnu-emacs, Git Mailing List
In-Reply-To: <7viqg65up7.fsf@alter.siamese.dyndns.org>
On Sun, Aug 30, 2009 at 12:11 AM, Junio C Hamano<gitster@pobox.com> wrote:
> Rustom Mody <rustompmody@gmail.com> writes:
>
>> Just updating my own question:
>> when I do a C-x v v (vc-next-action)
>> which is supposed to be the most basic operation for checking in a file I get
>>
>> Wrong type argument: stringp, nil
>>
>> So vc can be assumed to be a broken I guess?
>
> Have you checked contrib/emacs/README?
> --
Sorry Junio I should have checked.
Actually I had earlier checked.
Then I tried many emacs-git options, none of which worked.
Then I upgraded my emacs to 23 in which the vc is upgraded for dvses like git.
Time passed and I forgot what I had found, made worse by the fact that
sometimes I'm on windows and sometimes on linux and the 'working'
status of different things is quite different.
However the point is that I was not loading the older vc-git.el at
all. emacs was getting the wrong one.
It may be better if vc were hardened so that it gets its own vc-*.els
in preference to random stuff lying on the load-path.
^ permalink raw reply
* [PATCH 1/2] Add date formatting and parsing functions relative to a given time
From: Alex Riesen @ 2009-08-30 9:13 UTC (permalink / raw)
To: git; +Cc: Jeff King, Nicolas Pitre, David Reiss, Junio C Hamano
In-Reply-To: <81b0412b0908300025r4eeee84fyf0bfc3b2e940ff37@mail.gmail.com>
The main purpose is to allow predictable testing of the code.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
Have show_date_relative supplied the output buffer. As it is a new
interface, it can as well be a little bit more generic than its sole
caller. test-date.c is updated and shall follow in a moment.
And, after a while thinking, I am convinced that Jeff has a point
and used a more "internal" name for approxidate's recent "bottom half".
cache.h | 5 ++
date.c | 152 +++++++++++++++++++++++++++++++++++++--------------------------
2 files changed, 94 insertions(+), 63 deletions(-)
diff --git a/cache.h b/cache.h
index dd7f71e..1586f33 100644
--- a/cache.h
+++ b/cache.h
@@ -731,9 +731,14 @@ enum date_mode {
};
const char *show_date(unsigned long time, int timezone, enum date_mode mode);
+const char *show_date_relative(unsigned long time, int tz,
+ const struct timeval *now,
+ char *timebuf,
+ size_t timebuf_size);
int parse_date(const char *date, char *buf, int bufsize);
void datestamp(char *buf, int bufsize);
unsigned long approxidate(const char *);
+unsigned long approxidate_relative(const char *date, const struct timeval *now);
enum date_mode parse_date_format(const char *format);
#define IDENT_WARN_ON_NO_NAME 1
diff --git a/date.c b/date.c
index f011692..0b0f7a7 100644
--- a/date.c
+++ b/date.c
@@ -84,6 +84,68 @@ static int local_tzoffset(unsigned long time)
return offset * eastwest;
}
+const char *show_date_relative(unsigned long time, int tz,
+ const struct timeval *now,
+ char *timebuf,
+ size_t timebuf_size)
+{
+ unsigned long diff;
+ if (now->tv_sec < time)
+ return "in the future";
+ diff = now->tv_sec - time;
+ if (diff < 90) {
+ snprintf(timebuf, timebuf_size, "%lu seconds ago", diff);
+ return timebuf;
+ }
+ /* Turn it into minutes */
+ diff = (diff + 30) / 60;
+ if (diff < 90) {
+ snprintf(timebuf, timebuf_size, "%lu minutes ago", diff);
+ return timebuf;
+ }
+ /* Turn it into hours */
+ diff = (diff + 30) / 60;
+ if (diff < 36) {
+ snprintf(timebuf, timebuf_size, "%lu hours ago", diff);
+ return timebuf;
+ }
+ /* We deal with number of days from here on */
+ diff = (diff + 12) / 24;
+ if (diff < 14) {
+ snprintf(timebuf, timebuf_size, "%lu days ago", diff);
+ return timebuf;
+ }
+ /* Say weeks for the past 10 weeks or so */
+ if (diff < 70) {
+ snprintf(timebuf, timebuf_size, "%lu weeks ago", (diff + 3) / 7);
+ return timebuf;
+ }
+ /* Say months for the past 12 months or so */
+ if (diff < 360) {
+ snprintf(timebuf, timebuf_size, "%lu months ago", (diff + 15) / 30);
+ return timebuf;
+ }
+ /* Give years and months for 5 years or so */
+ if (diff < 1825) {
+ unsigned long years = diff / 365;
+ unsigned long months = (diff % 365 + 15) / 30;
+ int n;
+ n = snprintf(timebuf, timebuf_size, "%lu year%s",
+ years, (years > 1 ? "s" : ""));
+ if (months)
+ snprintf(timebuf + n, timebuf_size - n,
+ ", %lu month%s ago",
+ months, (months > 1 ? "s" : ""));
+ else
+ snprintf(timebuf + n, timebuf_size - n,
+ " ago");
+ return timebuf;
+ }
+ /* Otherwise, just years. Centuries is probably overkill. */
+ snprintf(timebuf, timebuf_size, "%lu years ago", (diff + 183) / 365);
+ return timebuf;
+}
+
const char *show_date(unsigned long time, int tz, enum date_mode mode)
{
struct tm *tm;
@@ -95,63 +157,10 @@ const char *show_date(unsigned long time, int tz, enum date_mode mode)
}
if (mode == DATE_RELATIVE) {
- unsigned long diff;
struct timeval now;
gettimeofday(&now, NULL);
- if (now.tv_sec < time)
- return "in the future";
- diff = now.tv_sec - time;
- if (diff < 90) {
- snprintf(timebuf, sizeof(timebuf), "%lu seconds ago", diff);
- return timebuf;
- }
- /* Turn it into minutes */
- diff = (diff + 30) / 60;
- if (diff < 90) {
- snprintf(timebuf, sizeof(timebuf), "%lu minutes ago", diff);
- return timebuf;
- }
- /* Turn it into hours */
- diff = (diff + 30) / 60;
- if (diff < 36) {
- snprintf(timebuf, sizeof(timebuf), "%lu hours ago", diff);
- return timebuf;
- }
- /* We deal with number of days from here on */
- diff = (diff + 12) / 24;
- if (diff < 14) {
- snprintf(timebuf, sizeof(timebuf), "%lu days ago", diff);
- return timebuf;
- }
- /* Say weeks for the past 10 weeks or so */
- if (diff < 70) {
- snprintf(timebuf, sizeof(timebuf), "%lu weeks ago", (diff + 3) / 7);
- return timebuf;
- }
- /* Say months for the past 12 months or so */
- if (diff < 360) {
- snprintf(timebuf, sizeof(timebuf), "%lu months ago", (diff + 15) / 30);
- return timebuf;
- }
- /* Give years and months for 5 years or so */
- if (diff < 1825) {
- unsigned long years = diff / 365;
- unsigned long months = (diff % 365 + 15) / 30;
- int n;
- n = snprintf(timebuf, sizeof(timebuf), "%lu year%s",
- years, (years > 1 ? "s" : ""));
- if (months)
- snprintf(timebuf + n, sizeof(timebuf) - n,
- ", %lu month%s ago",
- months, (months > 1 ? "s" : ""));
- else
- snprintf(timebuf + n, sizeof(timebuf) - n,
- " ago");
- return timebuf;
- }
- /* Otherwise, just years. Centuries is probably overkill. */
- snprintf(timebuf, sizeof(timebuf), "%lu years ago", (diff + 183) / 365);
- return timebuf;
+ return show_date_relative(time, tz, &now,
+ timebuf, sizeof(timebuf));
}
if (mode == DATE_LOCAL)
@@ -866,19 +875,13 @@ static const char *approxidate_digit(const char *date, struct tm *tm, int *num)
return end;
}
-unsigned long approxidate(const char *date)
+static unsigned long approxidate_str(const char *date, const struct timeval *tv)
{
int number = 0;
struct tm tm, now;
- struct timeval tv;
time_t time_sec;
- char buffer[50];
- if (parse_date(date, buffer, sizeof(buffer)) > 0)
- return strtoul(buffer, NULL, 10);
-
- gettimeofday(&tv, NULL);
- time_sec = tv.tv_sec;
+ time_sec = tv->tv_sec;
localtime_r(&time_sec, &tm);
now = tm;
for (;;) {
@@ -899,3 +902,26 @@ unsigned long approxidate(const char *date)
tm.tm_year--;
return mktime(&tm);
}
+
+unsigned long approxidate_relative(const char *date, const struct timeval *tv)
+{
+ char buffer[50];
+
+ if (parse_date(date, buffer, sizeof(buffer)) > 0)
+ return strtoul(buffer, NULL, 10);
+
+ return approxidate_str(date, tv);
+}
+
+unsigned long approxidate(const char *date)
+{
+ struct timeval tv;
+ char buffer[50];
+
+ if (parse_date(date, buffer, sizeof(buffer)) > 0)
+ return strtoul(buffer, NULL, 10);
+
+ gettimeofday(&tv, NULL);
+ return approxidate_str(date, &tv);
+}
+
--
1.6.4.1.294.g16262
^ permalink raw reply related
* [PATCH 2/2] Allow testing of _relative family of time formatting and parsing functions
From: Alex Riesen @ 2009-08-30 9:15 UTC (permalink / raw)
To: git; +Cc: Jeff King, Nicolas Pitre, David Reiss, Junio C Hamano
In-Reply-To: <20090830091346.GA14928@blimp.localdomain>
To complement the testability of approxidate.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
Alex Riesen, Sun, Aug 30, 2009 11:13:46 +0200:
> test-date.c is updated and shall follow in a moment.
here it goes.
test-date.c | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/test-date.c b/test-date.c
index 62e8f23..4cb146d 100644
--- a/test-date.c
+++ b/test-date.c
@@ -4,6 +4,19 @@ int main(int argc, char **argv)
{
int i;
+ /* see date.c, function show_date_relative */
+ char timebuf[(sizeof(long) * 5 / 2 + sizeof(" minutes ago,")) * 2];
+ struct tm tm;
+ struct timeval when = {0, 0};
+ tm.tm_sec = 0;
+ tm.tm_min = 0;
+ tm.tm_hour = 12;
+ tm.tm_mday = 1;
+ tm.tm_mon = 0 /* January */;
+ tm.tm_year = 90 /* 1990 */ ;
+ tm.tm_isdst = -1;
+ when.tv_sec = mktime(&tm);
+
for (i = 1; i < argc; i++) {
char result[100];
time_t t;
@@ -15,6 +28,13 @@ int main(int argc, char **argv)
t = approxidate(argv[i]);
printf("%s -> %s\n", argv[i], ctime(&t));
+
+ t = approxidate_relative(argv[i], &when);
+ printf("relative: %s -> %s", argv[i], ctime(&t));
+
+ printf("relative: %s, out of %s",
+ show_date_relative(t, 0, &when, timebuf,sizeof(timebuf)),
+ ctime(&t));
}
return 0;
}
--
1.6.4.1.294.g16262
^ permalink raw reply related
* Re: [PATCH 1/2] Add date formatting and parsing functions relative to a given time
From: Jeff King @ 2009-08-30 9:15 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Nicolas Pitre, David Reiss, Junio C Hamano
In-Reply-To: <20090830091346.GA14928@blimp.localdomain>
On Sun, Aug 30, 2009 at 11:13:46AM +0200, Alex Riesen wrote:
> Have show_date_relative supplied the output buffer. As it is a new
> interface, it can as well be a little bit more generic than its sole
> caller. test-date.c is updated and shall follow in a moment.
FYI, I am munging test-date to match the test script I am writing, so
don't bother with that patch.
-Peff
^ permalink raw reply
* Re: [PATCH 1/2] Add date formatting and parsing functions relative to a given time
From: Jeff King @ 2009-08-30 9:36 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Nicolas Pitre, David Reiss, Junio C Hamano
In-Reply-To: <20090830091557.GA28531@coredump.intra.peff.net>
On Sun, Aug 30, 2009 at 05:15:57AM -0400, Jeff King wrote:
> FYI, I am munging test-date to match the test script I am writing, so
> don't bother with that patch.
Here is what my patch is looking like. Please give any comments, and
then I will resubmit in a form that will be simpler for Junio, which
should be a series with:
- your patch to refactor date.c
- this patch (this version uses the original interface to
show_relative; I will tweak to match the new patch you just sent)
- another patch to go on top of lt/approxidate to test recent fixes
from Linus
---
diff --git a/t/t0006-date.sh b/t/t0006-date.sh
new file mode 100755
index 0000000..4beb44b
--- /dev/null
+++ b/t/t0006-date.sh
@@ -0,0 +1,71 @@
+#!/bin/sh
+
+test_description='test date parsing and printing'
+. ./test-lib.sh
+
+# arbitrary reference time: 2009-08-30 19:20:00
+TEST_DATE_NOW=1251660000; export TEST_DATE_NOW
+
+check_show() {
+ t=$(($TEST_DATE_NOW - $1))
+ echo "$t -> $2" >expect
+ test_expect_success "relative date ($2)" "
+ test-date show $t >actual &&
+ test_cmp expect actual
+ "
+}
+
+check_show 5 '5 seconds ago'
+check_show 300 '5 minutes ago'
+check_show 18000 '5 hours ago'
+check_show 432000 '5 days ago'
+check_show 1728000 '3 weeks ago'
+check_show 13000000 '5 months ago'
+check_show 37500000 '1 year, 2 months ago'
+check_show 55188000 '1 year, 9 months ago'
+check_show 630000000 '20 years ago'
+
+check_parse() {
+ echo "$1 -> $2" >expect
+ test_expect_success "parse date ($1)" "
+ test-date parse '$1' >actual &&
+ test_cmp expect actual
+ "
+}
+
+check_parse 2008 bad
+check_parse 2008-02 bad
+check_parse 2008-02-14 '2008-02-14 00:00:00 +0000'
+check_parse '2008-02-14 20:30:45' '2008-02-14 20:30:45 +0000'
+
+check_approxidate() {
+ echo "$1 -> $2 +0000" >expect
+ test_expect_success "parse approxidate ($1)" "
+ test-date approxidate '$1' >actual &&
+ test_cmp expect actual
+ "
+}
+
+check_approxidate now '2009-08-30 19:20:00'
+check_approxidate '5 seconds ago' '2009-08-30 19:19:55'
+check_approxidate 5.seconds.ago '2009-08-30 19:19:55'
+check_approxidate 10.minutes.ago '2009-08-30 19:10:00'
+check_approxidate yesterday '2009-08-29 19:20:00'
+check_approxidate 3.days.ago '2009-08-27 19:20:00'
+check_approxidate 3.weeks.ago '2009-08-09 19:20:00'
+check_approxidate 3.months.ago '2009-05-30 19:20:00'
+check_approxidate 2.years.3.months.ago '2007-05-30 19:20:00'
+
+check_approxidate '6am yesterday' '2009-08-29 06:00:00'
+check_approxidate '6pm yesterday' '2009-08-29 18:00:00'
+check_approxidate '3:00' '2009-08-30 03:00:00'
+check_approxidate '15:00' '2009-08-30 15:00:00'
+check_approxidate 'noon today' '2009-08-30 12:00:00'
+check_approxidate 'noon yesterday' '2009-08-29 12:00:00'
+
+check_approxidate 'last tuesday' '2009-08-25 19:20:00'
+check_approxidate 'July 5th' '2009-07-05 19:20:00'
+check_approxidate '06/05/2009' '2009-06-05 00:00:00'
+check_approxidate '06.05.2009' '2009-05-06 00:00:00'
+
+test_done
diff --git a/test-date.c b/test-date.c
index 62e8f23..8d263a3 100644
--- a/test-date.c
+++ b/test-date.c
@@ -1,20 +1,63 @@
#include "cache.h"
-int main(int argc, char **argv)
+static const char *usage_msg = "\n"
+" test-date show [time_t]...\n"
+" test-date parse [date]...\n"
+" test-date approxidate [date]...\n";
+
+static void show_dates(char **argv, struct timeval *now)
{
- int i;
+ for (; *argv; argv++) {
+ time_t t = atoi(*argv);
+ printf("%s -> %s\n", *argv, show_date_relative(t, 0, now));
+ }
+}
- for (i = 1; i < argc; i++) {
+static void parse_dates(char **argv, struct timeval *now)
+{
+ for (; *argv; argv++) {
char result[100];
time_t t;
- memcpy(result, "bad", 4);
- parse_date(argv[i], result, sizeof(result));
+ parse_date(*argv, result, sizeof(result));
t = strtoul(result, NULL, 0);
- printf("%s -> %s -> %s", argv[i], result, ctime(&t));
+ printf("%s -> %s\n", *argv,
+ t ? show_date(t, 0, DATE_ISO8601) : "bad");
+ }
+}
+
+static void parse_approxidate(char **argv, struct timeval *now)
+{
+ for (; *argv; argv++) {
+ time_t t;
+ t = approxidate_relative(*argv, now);
+ printf("%s -> %s\n", *argv, show_date(t, 0, DATE_ISO8601));
+ }
+}
- t = approxidate(argv[i]);
- printf("%s -> %s\n", argv[i], ctime(&t));
+int main(int argc, char **argv)
+{
+ struct timeval now;
+ const char *x;
+
+ x = getenv("TEST_DATE_NOW");
+ if (x) {
+ now.tv_sec = atoi(x);
+ now.tv_usec = 0;
}
+ else
+ gettimeofday(&now, NULL);
+
+ argv++;
+ if (!*argv)
+ usage(usage_msg);
+ if (!strcmp(*argv, "show"))
+ show_dates(argv+1, &now);
+ else if (!strcmp(*argv, "parse"))
+ parse_dates(argv+1, &now);
+ else if (!strcmp(*argv, "approxidate"))
+ parse_approxidate(argv+1, &now);
+ else
+ usage(usage_msg);
return 0;
}
^ permalink raw reply related
* Re: [BUG] git stash refuses to save after "add -N"
From: Jeff King @ 2009-08-30 9:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Yann Dirson, git
In-Reply-To: <7vmy5ixn96.fsf@alter.siamese.dyndns.org>
On Sat, Aug 29, 2009 at 03:34:45PM -0700, Junio C Hamano wrote:
> I am slightly in favor of leaving the things as they are, as the error
> message is quite clear.
Hmm. Thinking about it a bit more, I think "add as empty content" is
probably the best. It scares me a little because it is losing
information during the stash, but consider it from the user's
perspective.
Their work-in-progress is being interrupted, so they need to stash. They
try "git stash" and the current version comes back with an error. Now
what? If they know what to do, they can manually "git rm --cached" each
of the offending files (and I say manually because there isn't a
parseable list of them anywhere). But they probably don't know what to
do, which means trying to find the information in the documentation.
And all of this while they are trying to quickly switch contexts to
whatever it was that caused them to stash in the first place. So I
expect the most useful thing would be a "git stash -f" that adds them as
empty. And it's reasonably safe, because we're not losing information in
the transition from index to stash tree without the user first having
been notified.
On the other hand, it may be sufficient to just do the transformation
with a "-f", which will save users even more time, and we can put a note
in the documentation about how stash interacts with -N. I don't know
whether people will actually care or not (and your patch already does
the unconditional form, so it's less work :) ).
-Peff
^ permalink raw reply
* Re: [PATCH 1/2] Add date formatting and parsing functions relative to a given time
From: Alex Riesen @ 2009-08-30 9:56 UTC (permalink / raw)
To: Jeff King; +Cc: git, Nicolas Pitre, David Reiss, Junio C Hamano
In-Reply-To: <20090830093642.GA30922@coredump.intra.peff.net>
On Sun, Aug 30, 2009 at 11:36, Jeff King<peff@peff.net> wrote:
> On Sun, Aug 30, 2009 at 05:15:57AM -0400, Jeff King wrote:
>
>> FYI, I am munging test-date to match the test script I am writing, so
>> don't bother with that patch.
>
> Here is what my patch is looking like. Please give any comments, and
> then I will resubmit in a form that will be simpler for Junio, which
> should be a series with:
>
> - your patch to refactor date.c
> - this patch (this version uses the original interface to
> show_relative; I will tweak to match the new patch you just sent)
Yes, I think this is the only comment I can make.
> +# arbitrary reference time: 2009-08-30 19:20:00
The world changed since 1980 :) There is already three things
happened at the day (http://en.wikipedia.org/wiki/August_2009),
and it is not evening yet (well, here in Europe)
> +check_show 5 '5 seconds ago'
> +check_show 300 '5 minutes ago'
> +check_show 18000 '5 hours ago'
> +check_show 432000 '5 days ago'
> +check_show 1728000 '3 weeks ago'
> +check_show 13000000 '5 months ago'
> +check_show 37500000 '1 year, 2 months ago'
> +check_show 55188000 '1 year, 9 months ago'
> +check_show 630000000 '20 years ago'
check_show 630000000 '20.years.ago'?
(Arbitrary, non-whitespace delimiters, which was an
advertised feature, to make shell's life easier)
^ permalink raw reply
* Re: [PATCH 1/2] Add date formatting and parsing functions relative to a given time
From: Jeff King @ 2009-08-30 10:08 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Nicolas Pitre, David Reiss, Junio C Hamano
In-Reply-To: <81b0412b0908300256l13d308d9oc30172a20a9f6108@mail.gmail.com>
On Sun, Aug 30, 2009 at 11:56:37AM +0200, Alex Riesen wrote:
> > +check_show 5 '5 seconds ago'
> > +check_show 300 '5 minutes ago'
> > +check_show 18000 '5 hours ago'
> > +check_show 432000 '5 days ago'
> > +check_show 1728000 '3 weeks ago'
> > +check_show 13000000 '5 months ago'
> > +check_show 37500000 '1 year, 2 months ago'
> > +check_show 55188000 '1 year, 9 months ago'
> > +check_show 630000000 '20 years ago'
>
> check_show 630000000 '20.years.ago'?
> (Arbitrary, non-whitespace delimiters, which was an
> advertised feature, to make shell's life easier)
This part is about checking what show_date produces (the first number is
an offset from now in seconds, and the second is what we expect), so it
always has spaces.
See the check_approxidate section further down for an example of parsing
what you are talking about.
-Peff
^ permalink raw reply
* Re: Anyone meet DNS fail translate repo.or.cz
From: Erik Faye-Lund @ 2009-08-30 10:39 UTC (permalink / raw)
To: Frank Li; +Cc: git
In-Reply-To: <1976ea660908292120r7e7ec941he7573671251451f5@mail.gmail.com>
On Sun, Aug 30, 2009 at 6:20 AM, Frank Li<lznuaa@gmail.com> wrote:
> ALL:
> I can't access repo.or.cz from yesterday.
> DNS can't translate repo.or.cz.
> Even
> http://www.dnswatch.info/dns/dnslookup?la=en&host=repo.or.cz&type=A
>
> It also can't recognize repo.or.cz.
>
> Anyone meet the same problem?
Yeah, I've been seeing the same problem here.
--
Erik "kusma" Faye-Lund
kusmabite@gmail.com
(+47) 986 59 656
^ permalink raw reply
* Re: Anyone meet DNS fail translate repo.or.cz
From: Mikael Magnusson @ 2009-08-30 10:50 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: Frank Li, git
In-Reply-To: <40aa078e0908300339j74e9c542x3436ec2e58e4b874@mail.gmail.com>
2009/8/30 Erik Faye-Lund <kusmabite@googlemail.com>:
> On Sun, Aug 30, 2009 at 6:20 AM, Frank Li<lznuaa@gmail.com> wrote:
>> ALL:
>> I can't access repo.or.cz from yesterday.
>> DNS can't translate repo.or.cz.
>> Even
>> http://www.dnswatch.info/dns/dnslookup?la=en&host=repo.or.cz&type=A
>>
>> It also can't recognize repo.or.cz.
>>
>> Anyone meet the same problem?
>
> Yeah, I've been seeing the same problem here.
The IP for both repo.or.cz and git.or.cz is 62.24.64.27
If you add this to /etc/hosts you can still access both fine.
62.24.64.27 repo.or.cz git.or.cz
--
Mikael Magnusson
^ permalink raw reply
* Re: [PATCH 1/2] Add date formatting and parsing functions relative to a given time
From: Alex Riesen @ 2009-08-30 11:17 UTC (permalink / raw)
To: Jeff King; +Cc: git, Nicolas Pitre, David Reiss, Junio C Hamano
In-Reply-To: <20090830100826.GA31543@coredump.intra.peff.net>
On Sun, Aug 30, 2009 at 12:08, Jeff King<peff@peff.net> wrote:
> On Sun, Aug 30, 2009 at 11:56:37AM +0200, Alex Riesen wrote:
>>
>> check_show 630000000 '20.years.ago'?
>> (Arbitrary, non-whitespace delimiters, which was an
>> advertised feature, to make shell's life easier)
>
> This part is about checking what show_date produces (the first number is
> an offset from now in seconds, and the second is what we expect), so it
> always has spaces.
>
> See the check_approxidate section further down for an example of parsing
> what you are talking about.
Ah, I see
^ permalink raw reply
* [PATCH] git.el: Make it easy to add unmerged files
From: Martin Nordholts @ 2009-08-30 14:35 UTC (permalink / raw)
To: git, Junio C Hamano, julliard
It is nice and easy to git-add ignored and unknown files in a
git-status buffer. Make it equally easy to add unmerged files which is
a common use case.
Signed-off-by: Martin Nordholts <martinn@src.gnome.org>
---
contrib/emacs/git.el | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index 8c70ad8..3af5d00 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -1046,7 +1046,7 @@ The FILES list must be sorted."
(defun git-add-file ()
"Add marked file(s) to the index cache."
(interactive)
- (let ((files (git-get-filenames (git-marked-files-state 'unknown
'ignored))))
+ (let ((files (git-get-filenames (git-marked-files-state 'unknown
'ignored 'unmerged))))
;; FIXME: add support for directories
(unless files
(push (file-relative-name (read-file-name "File to add: " nil
nil t)) files))
--
1.6.2.5
^ permalink raw reply related
* Strangeness with git log --follow
From: Brenton Fletcher @ 2009-08-30 14:31 UTC (permalink / raw)
To: git
I'm using git log --follow -p <filename> to list all the commits
affecting a certain file. My problem is that git log --follow --topo-
order returns fewer commits than git log --follow --date-order (or
default). The docs for git log and git-rev-list don't seem to indicate
whay this is happening.
The repo I'm working with is http://github.com/bloopletech/keycontrol/tree/master
and the file is original/C/kc.c on the master branch; I'm using git
v1.6.4.2
Am I misunderstanding what's going on here? --topo-order is kind of
doing that I want since it's generating a nice series of commits that
diff against each other nicely, whereas running without topo-order is
returning the commits in a sequence which means thay don't properly
diff against each other. I like the results I'm getting from --topo-
order, but I need results in date order, which is not assured AFAIK
with topo-order.
If someone could enlighten me as to what's going on, thanks!
-Brenton Fletcher
^ permalink raw reply
* [PATCH] git.el: Make it easy to add unmerged files
From: Martin Nordholts @ 2009-08-30 14:55 UTC (permalink / raw)
To: git, Junio C Hamano, julliard
(Resending as I managed to mangle the previous patch despite trying not to...)
It is nice and easy to git-add ignored and unknown files in a
git-status buffer. Make it equally easy to add unmerged files which is
a common use case.
Signed-off-by: Martin Nordholts <martinn@src.gnome.org>
---
contrib/emacs/git.el | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index 8c70ad8..3af5d00 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -1046,7 +1046,7 @@ The FILES list must be sorted."
(defun git-add-file ()
"Add marked file(s) to the index cache."
(interactive)
- (let ((files (git-get-filenames (git-marked-files-state 'unknown 'ignored))))
+ (let ((files (git-get-filenames (git-marked-files-state 'unknown 'ignored 'unmerged))))
;; FIXME: add support for directories
(unless files
(push (file-relative-name (read-file-name "File to add: " nil nil t)) files))
--
1.6.2.5
^ permalink raw reply related
* Re: [PATCH] git.el: Make it easy to add unmerged files
From: Alexandre Julliard @ 2009-08-30 15:58 UTC (permalink / raw)
To: Martin Nordholts; +Cc: git, Junio C Hamano
In-Reply-To: <4A9A92F4.2090209@chromecode.com>
Martin Nordholts <martin@chromecode.com> writes:
> (Resending as I managed to mangle the previous patch despite trying not to...)
>
> It is nice and easy to git-add ignored and unknown files in a
> git-status buffer. Make it equally easy to add unmerged files which is
> a common use case.
That's not quite what adding a file means in git.el, unmerged files are
considered added already, and marking them resolved is done through the
git-resolve-file command. Of course that was implemented before git
overloaded the meaning of git-add to mean git-update-index, so maybe we
should follow the trend and use git-add-file for all index updates. In
that case git-resolve-file should probably be removed.
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply
* Re: git-diff: must --exit-code work with --ignore* options?
From: Jim Meyering @ 2009-08-30 16:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git list
In-Reply-To: <7v7i087twu.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Jim Meyering <jim@meyering.net> writes:
>> Junio C Hamano wrote:
>>> Jim Meyering <jim@meyering.net> writes:
>>>>
>>>> # do this in an empty directory
>>>> $ git init -q; echo>k; git add .; git commit -q -m. .; echo \ >k
>>>> $ git diff --ignore-space-at-eol --quiet || echo bad
>>>> bad
>>>
>>> I am slightly torn about this, in that I can picture myself saying that
>>> this is unintuitive on some different days, but not today ;-)
>>
>> Thanks for the quick reply. Here's why I noticed:
>> ...
>
> It seems that today is already "some different day" ;-) We could do
> something like this patch.
>
> While in the longer term I think it may make the world a better place by
> being more consistent with what users expect, I am not sure at what
> revision boundary we should introduce such a semantic change.
>
> We could always declare this a bug and apply the "fix" at any time. It's
> all perception ;-).
>
> -- >8 --
> Subject: [PATCH] diff --quiet: special case "ignore whitespace" options
>
> The option "QUIET" primarily meant "find if we have _any_ difference as
> quick as possible and report", which means we often do not even have to
> look at blobs if we know the trees are different by looking at the higher
> level (e.g. "diff-tree A B"). As a side effect, because there is no point
> showing one change that we happened to have found first, it also enables
> NO_OUTPUT and EXIT_WITH_STATUS options, making the end result look quiet.
>
> Traditionally, the --ignore-whitespace* options have merely meant to tell
> the diff output routine that some class of differences are not worth
> showing in the textual diff output, so that the end user has easier time
> to review the remaining (presumably more meaningful) changes. These
> options never affected the outcome of the command, given as the exit
> status when the --exit-code option was in effect (either directly or
> indirectly).
>
> These two classes of options are incompatible. When you have only
> whitespace changes, you would expect:
>
> git diff -b --quiet
>
> to report that there is _no_ change. This is unfortunately not the case,
> however, if there are differences to be reported if the command was run
> without --quiet; there _is_ a change, and the command still exits with
> non-zero status.
>
> And that is wrong.
>
> Change the semantics of --ignore-whitespace* options to mean more than
> "omit showing the difference in text". When these options are used, the
> internal "quick" optimization is turned off, and the status reported with
> the --exit-code option will now match if any the textual diff output is
> actually produced.
>
> Also rename the internal option "QUIET" to "QUICK" to better reflect what
> its true purpose is.
Thanks again.
If there's anything I can to do help (add a test?), let me know.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox