* 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: [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
* [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
* [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
* 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
* 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: [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 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 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] 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
* [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
* 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
* 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
* 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: how to add an empty initial commit
From: Sean Estabrooks @ 2009-08-30 1:39 UTC (permalink / raw)
To: bill lam; +Cc: git
In-Reply-To: <20090830005224.GC10952@debian.b2j>
On Sun, 30 Aug 2009 08:52:24 +0800
bill lam <cbill.lam@gmail.com> wrote:
> I want to insert an empty initial commit so that I can rebase and edit
> files in the real initial commit. There is a --root option in
> git-rebase but I can not find example of how to use it.
Bill,
This sounds like a hard way to go about things. Instead, you can edit
the files as you wish, "git add" the new edits, and then use
"git commit --amend" to alter the initial commit. Don't think rebase
would help in the situation you describe.
Sean
^ permalink raw reply
* git-svn messing up merge commits on dcommit
From: Björn Steinbrink @ 2009-08-30 1:32 UTC (permalink / raw)
To: Eric Wong; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 1485 bytes --]
Hi Eric,
I have two "test cases" here (attached), which I actually wrote months
ago, but forgot to sent, as I wanted to clean them up/turn them into
something suitable for the test suite, but honestly, I'll probably never
get around to do that, so here they are, as they are. They show git-svn
messing up merge commits when dcommitting a branch that is not
up-to-date WRT the svn repo.
The basic history for both cases (before dcommit) is:
C---D (master)
/ /
/---E (side)
/
A---B (trunk)
\
X (revision in SVN, not yet fetched)
So the dcommit (which would send C and D to the svn repo) needs to
"rebase" C and D.
In the first test case, this rebasing causes conflicts, and leads to a
linearized history:
E (side)
/
A---B---X---C' (trunk)
\
D (master)
The merge is broken apart. This is probably expected, but I thought I'd
tell anyway.
The second test case is a bit more interesting, there are no conflicts
between the local commits to be dcommitted and the new commit X in the
svn repo. In this case, git-svn manages to dcommit the merge commit just
fine, keeping the history correct, but it messes the merge commit's
commit message up. So the history becomes:
A---B---X---C'--D' (trunk) (master)
\ /
--------E (side)
But D' has the same commit message as C/C', not the one from D.
I hope that makes any sense to you (or you can figure it out from the
testing scripts).
Björn
[-- Attachment #2: test --]
[-- Type: text/plain, Size: 582 bytes --]
#!/bin/sh
mkdir git-svn-test
cd git-svn-test
SVN="file://$PWD/svnrepo"
svnadmin create svnrepo
svn co "$SVN" co
cd co
svn mkdir trunk tags branches
svn ci -m init
echo 123 > trunk/foo
svn add trunk/foo
svn ci -m "SVN 1"
cd ..
git svn clone -s "$SVN" git
cd co
echo 456 >> trunk/foo
svn ci -m "SVN 2"
cd ..
cd git
git checkout -b side
echo 123 >> foo
git add foo
git commit -m "On side"
git checkout master
echo 123 > foo3
git add foo3
git commit -m "On master"
git merge --no-ff side
gitk --all&
git svn dcommit
echo resolved > foo
git add -u
git rebase --continue
gitk --all
[-- Attachment #3: test2 --]
[-- Type: text/plain, Size: 532 bytes --]
#!/bin/sh
mkdir git-svn-test
cd git-svn-test
SVN="file://$PWD/svnrepo"
svnadmin create svnrepo
svn co "$SVN" co
cd co
svn mkdir trunk tags branches
svn ci -m init
echo 123 > trunk/foo
svn add trunk/foo
svn ci -m "SVN 1"
cd ..
git svn clone -s "$SVN" git
cd co
echo 456 >> trunk/foo
svn ci -m "SVN 2"
cd ..
cd git
git checkout -b side
echo 123 >> foo2
git add foo2
git commit -m "On side"
git checkout master
echo 123 > foo3
git add foo3
git commit -m "On master"
git merge --no-ff side
gitk --all&
git svn dcommit
gitk --all&
^ permalink raw reply
* how to add an empty initial commit
From: bill lam @ 2009-08-30 0:52 UTC (permalink / raw)
To: git
I want to insert an empty initial commit so that I can rebase and edit
files in the real initial commit. There is a --root option in
git-rebase but I can not find example of how to use it.
I googled some said it needs to create a new branch, I tried but it
failed to merge.
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
^ permalink raw reply
* Re: How does git follow branch history across a merge commit?
From: Steven E. Harris @ 2009-08-30 0:29 UTC (permalink / raw)
To: git
In-Reply-To: <7vy6p38p4j.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> *1* If you do not know what a merge simplification is, refer to e.g.
> http://gitster.livejournal.com/35628.html and notice there is a place
> where we follow "a parent that is the same as the merge result".
I read this article today with great interest. Had I known of it
beforehand, it would have changed some of my flawed assumptions evident
in my post. Thanks for writing that. I'll be looking into the rest of
the articles there to learn more.
--
Steven E. Harris
^ permalink raw reply
* Re: [BUG] git stash refuses to save after "add -N"
From: Junio C Hamano @ 2009-08-29 22:34 UTC (permalink / raw)
To: Jeff King; +Cc: Yann Dirson, git
In-Reply-To: <20090828190531.GB11488@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> - inserted as blank files, then you may be a bit surprised by the fact
> that it looks like you added a blank version, but at least you will
> still see a diff against the working tree file, alerting you to the
> fact that maybe they weren't entirely ready for commit.
>
> So I think of the three, the last one is the least surprising. The other
> option is to die and force the user to resolve the issue, which is what
> we do now. It does actually tell you the problem "bar: not added yet",
> though we could perhaps improve on that message a bit.
I am slightly in favor of leaving the things as they are, as the error
message is quite clear.
The third option would probably loo like this, which is not too bad,
though.
builtin-commit.c | 2 +-
builtin-write-tree.c | 3 +++
cache-tree.c | 29 ++++++++++++++---------------
cache-tree.h | 4 +++-
git-stash.sh | 2 +-
merge-recursive.c | 2 +-
test-dump-cache-tree.c | 2 +-
7 files changed, 24 insertions(+), 20 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 200ffda..fc97d54 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -595,7 +595,7 @@ static int prepare_to_commit(const char *index_file, const char *prefix,
if (!active_cache_tree)
active_cache_tree = cache_tree();
if (cache_tree_update(active_cache_tree,
- active_cache, active_nr, 0, 0) < 0) {
+ active_cache, active_nr, 0) < 0) {
error("Error building trees");
return 0;
}
diff --git a/builtin-write-tree.c b/builtin-write-tree.c
index b223af4..6fce25e 100644
--- a/builtin-write-tree.c
+++ b/builtin-write-tree.c
@@ -23,6 +23,9 @@ int cmd_write_tree(int argc, const char **argv, const char *unused_prefix)
struct option write_tree_options[] = {
OPT_BIT(0, "missing-ok", &flags, "allow missing objects",
WRITE_TREE_MISSING_OK),
+ OPT_BIT(0, "intent-as-empty", &flags,
+ "write intent-to-add entries as empty blobs",
+ WRITE_TREE_ADD_INTENT_AS_EMPTY),
{ OPTION_STRING, 0, "prefix", &prefix, "<prefix>/",
"write tree object for a subdirectory <prefix>" ,
PARSE_OPT_LITERAL_ARGHELP },
diff --git a/cache-tree.c b/cache-tree.c
index d917437..7377066 100644
--- a/cache-tree.c
+++ b/cache-tree.c
@@ -148,7 +148,7 @@ void cache_tree_invalidate_path(struct cache_tree *it, const char *path)
}
static int verify_cache(struct cache_entry **cache,
- int entries)
+ int entries, int flags)
{
int i, funny;
@@ -156,7 +156,9 @@ static int verify_cache(struct cache_entry **cache,
funny = 0;
for (i = 0; i < entries; i++) {
struct cache_entry *ce = cache[i];
- if (ce_stage(ce) || (ce->ce_flags & CE_INTENT_TO_ADD)) {
+ if (ce_stage(ce) ||
+ (!(flags & WRITE_TREE_ADD_INTENT_AS_EMPTY) &&
+ (ce->ce_flags & CE_INTENT_TO_ADD))) {
if (10 < ++funny) {
fprintf(stderr, "...\n");
break;
@@ -237,8 +239,7 @@ static int update_one(struct cache_tree *it,
int entries,
const char *base,
int baselen,
- int missing_ok,
- int dryrun)
+ int flags)
{
struct strbuf buffer;
int i;
@@ -284,8 +285,7 @@ static int update_one(struct cache_tree *it,
cache + i, entries - i,
path,
baselen + sublen + 1,
- missing_ok,
- dryrun);
+ flags);
if (subcnt < 0)
return subcnt;
i += subcnt - 1;
@@ -328,7 +328,9 @@ static int update_one(struct cache_tree *it,
mode = ce->ce_mode;
entlen = pathlen - baselen;
}
- if (mode != S_IFGITLINK && !missing_ok && !has_sha1_file(sha1))
+ if (mode != S_IFGITLINK &&
+ !(flags & WRITE_TREE_MISSING_OK) &&
+ !has_sha1_file(sha1))
return error("invalid object %06o %s for '%.*s'",
mode, sha1_to_hex(sha1), entlen+baselen, path);
@@ -345,7 +347,7 @@ static int update_one(struct cache_tree *it,
#endif
}
- if (dryrun)
+ if (flags & WRITE_TREE_DRY_RUN)
hash_sha1_file(buffer.buf, buffer.len, tree_type, it->sha1);
else if (write_sha1_file(buffer.buf, buffer.len, tree_type, it->sha1)) {
strbuf_release(&buffer);
@@ -365,14 +367,13 @@ static int update_one(struct cache_tree *it,
int cache_tree_update(struct cache_tree *it,
struct cache_entry **cache,
int entries,
- int missing_ok,
- int dryrun)
+ int flags)
{
int i;
- i = verify_cache(cache, entries);
+ i = verify_cache(cache, entries, flags);
if (i)
return i;
- i = update_one(it, cache, entries, "", 0, missing_ok, dryrun);
+ i = update_one(it, cache, entries, "", 0, flags);
if (i < 0)
return i;
return 0;
@@ -565,11 +566,9 @@ int write_cache_as_tree(unsigned char *sha1, int flags, const char *prefix)
was_valid = cache_tree_fully_valid(active_cache_tree);
if (!was_valid) {
- int missing_ok = flags & WRITE_TREE_MISSING_OK;
-
if (cache_tree_update(active_cache_tree,
active_cache, active_nr,
- missing_ok, 0) < 0)
+ flags) < 0)
return WRITE_TREE_UNMERGED_INDEX;
if (0 <= newfd) {
if (!write_cache(newfd, active_cache, active_nr) &&
diff --git a/cache-tree.h b/cache-tree.h
index 3df641f..4ee03bb 100644
--- a/cache-tree.h
+++ b/cache-tree.h
@@ -29,11 +29,13 @@ void cache_tree_write(struct strbuf *, struct cache_tree *root);
struct cache_tree *cache_tree_read(const char *buffer, unsigned long size);
int cache_tree_fully_valid(struct cache_tree *);
-int cache_tree_update(struct cache_tree *, struct cache_entry **, int, int, int);
+int cache_tree_update(struct cache_tree *, struct cache_entry **, int, int);
/* bitmasks to write_cache_as_tree flags */
#define WRITE_TREE_MISSING_OK 1
#define WRITE_TREE_IGNORE_CACHE_TREE 2
+#define WRITE_TREE_ADD_INTENT_AS_EMPTY 4
+#define WRITE_TREE_DRY_RUN 8
/* error return codes */
#define WRITE_TREE_UNREADABLE_INDEX (-1)
diff --git a/git-stash.sh b/git-stash.sh
index d61c9d0..735e511 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -63,7 +63,7 @@ create_stash () {
msg=$(printf '%s: %s' "$branch" "$head")
# state of the index
- i_tree=$(git write-tree) &&
+ i_tree=$(git write-tree --intent-as-empty) &&
i_commit=$(printf 'index on %s\n' "$msg" |
git commit-tree $i_tree -p $b_commit) ||
die "Cannot save the current index state"
diff --git a/merge-recursive.c b/merge-recursive.c
index 10d7913..dea5400 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -211,7 +211,7 @@ struct tree *write_tree_from_memory(struct merge_options *o)
if (!cache_tree_fully_valid(active_cache_tree) &&
cache_tree_update(active_cache_tree,
- active_cache, active_nr, 0, 0) < 0)
+ active_cache, active_nr, 0) < 0)
die("error building trees");
result = lookup_tree(active_cache_tree->sha1);
diff --git a/test-dump-cache-tree.c b/test-dump-cache-tree.c
index 1f73f1e..a6ffdf3 100644
--- a/test-dump-cache-tree.c
+++ b/test-dump-cache-tree.c
@@ -59,6 +59,6 @@ int main(int ac, char **av)
struct cache_tree *another = cache_tree();
if (read_cache() < 0)
die("unable to read index file");
- cache_tree_update(another, active_cache, active_nr, 0, 1);
+ cache_tree_update(another, active_cache, active_nr, WRITE_TREE_DRY_RUN);
return dump_cache_tree(active_cache_tree, another, "");
}
^ permalink raw reply related
* Re: [PATCH] Allow testing of _relative family of time formatting and parsing functions
From: Junio C Hamano @ 2009-08-29 21:46 UTC (permalink / raw)
To: Alex Riesen; +Cc: Jeff King, Nicolas Pitre, David Reiss, git
In-Reply-To: <20090828205232.GD9233@blimp.localdomain>
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? Is this intended as a serious submission
for inclusion? I am having a hrad time to guess, especially you did not
sign this off, nor Cc'ed me.
^ permalink raw reply
* Re: git-svn intermittent issues with absent_file
From: Ealdwulf Wuffinga @ 2009-08-29 21:35 UTC (permalink / raw)
To: Matthias Andree; +Cc: Eric Wong, git
In-Reply-To: <op.uzc46sm43myrm3@balu.cs.uni-paderborn.de>
On Fri, Aug 28, 2009 at 9:14 AM, Matthias
Andree<matthias.andree@uni-paderborn.de> wrote:
> So, the common idea set is apparently down to (a) intermittent server issues
> (I've asked for the relevant log excerpts) and (b) Cygwin issues, and we
> should keep in mind (c) git-svn, or svn bindings/libraries, losing the
> causes error conditions from (a) or (b) and git-svn just reporting later
> symptoms (absent files). More on the other experiments once I get around to
> them.
Won't help if it's a server issue, but if your suspicion towards
git-svn (or anything else you have the source for) increases, it may
be worth trying bbchop:
http://github.com/Ealdwulf/bbchop
That is like git-bisect, except it can cope with intermittent bugs.
Ealdwulf
^ permalink raw reply
* Re: vc in emacs problem with git
From: Junio C Hamano @ 2009-08-29 18:41 UTC (permalink / raw)
To: Rustom Mody; +Cc: help-gnu-emacs, Git Mailing List
In-Reply-To: <f46c52560908270914o7027dc0bo873544dc0687cc48@mail.gmail.com>
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?
^ permalink raw reply
* Re: vc in emacs problem with git
From: Rustom Mody @ 2009-08-29 14:37 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <f46c52560908270914o7027dc0bo873544dc0687cc48@mail.gmail.com>
On Thu, Aug 27, 2009 at 9:44 PM, Rustom Mody<rustompmody@gmail.com> wrote:
> 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?
Answering my own question:
Short answer: vc-git.el from git breaks vc in emacs
Long answer: see emacs mailing list discussion
http://groups.google.com/group/gnu.emacs.help/browse_thread/thread/657d9c58baed7b0f#
^ permalink raw reply
* Re: git-bz: command line integration for bugzilla
From: Owen Taylor @ 2009-08-29 10:51 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3fxbbkpq5.fsf@localhost.localdomain>
On Sat, 2009-08-29 at 01:07 -0700, Jakub Narebski wrote:
> Owen Taylor <otaylor@redhat.com> writes:
>
> > Was filling out the Git user's survey today, and noticed that my git-bz
> > tool wasn't on the long list of "Git interfaces, implementations,
> > frontends and tools"
>
> Well, you can always add it in "Other (please specify)" in survey
Certainly. It was not meant as a real complaint - git has a large and
varied ecosystem.
> > - but then again, I've never really advertised it
> > beyond GNOME IRC. So, I was reminded to mention it here...
>
> Could you please add (short) information about this tool to Git Wiki:
> http://git.or.cz/gitwiki/InterfacesFrontendsAndTools
One step ahead of you there, added:
http://git.or.cz/gitwiki/InterfacesFrontendsAndTools#git-bz
yesterday.
- Owen
^ permalink raw reply
* [PATCH] UI consistency: allow --force for where -f means force
From: René Scharfe @ 2009-08-29 9:05 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
git branch, checkout, clean, mv and tag all have an option -f to override
certain checks. This patch makes them accept the long option --force as
a synonym.
While we're at it, document that checkout support --quiet as synonym for
its short option -q.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
Documentation/git-branch.txt | 1 +
Documentation/git-checkout.txt | 2 ++
Documentation/git-clean.txt | 1 +
Documentation/git-mv.txt | 1 +
Documentation/git-tag.txt | 1 +
builtin-branch.c | 2 +-
builtin-checkout.c | 2 +-
builtin-clean.c | 2 +-
builtin-mv.c | 2 +-
builtin-tag.c | 2 +-
10 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 9998887..aad71dc 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -76,6 +76,7 @@ OPTIONS
based sha1 expressions such as "<branchname>@\{yesterday}".
-f::
+--force::
Reset <branchname> to <startpoint> if <branchname> exists
already. Without `-f` 'git-branch' refuses to change an existing branch.
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index ad4b31e..b1314b5 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -45,9 +45,11 @@ file can be discarded to recreate the original conflicted merge result.
OPTIONS
-------
-q::
+--quiet::
Quiet, suppress feedback messages.
-f::
+--force::
When switching branches, proceed even if the index or the
working tree differs from HEAD. This is used to throw away
local changes.
diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt
index ae8938b..9d291bd 100644
--- a/Documentation/git-clean.txt
+++ b/Documentation/git-clean.txt
@@ -32,6 +32,7 @@ OPTIONS
if you really want to remove such a directory.
-f::
+--force::
If the git configuration specifies clean.requireForce as true,
'git-clean' will refuse to run unless given -f or -n.
diff --git a/Documentation/git-mv.txt b/Documentation/git-mv.txt
index 9c56602..bdcb585 100644
--- a/Documentation/git-mv.txt
+++ b/Documentation/git-mv.txt
@@ -28,6 +28,7 @@ committed.
OPTIONS
-------
-f::
+--force::
Force renaming or moving of a file even if the target exists
-k::
Skip move or rename actions which would lead to an error
diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index 5113eae..299b04f 100644
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -51,6 +51,7 @@ OPTIONS
Make a GPG-signed tag, using the given key
-f::
+--force::
Replace an existing tag with the given name (instead of failing)
-d::
diff --git a/builtin-branch.c b/builtin-branch.c
index 1a03d5f..9f57992 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -586,7 +586,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
OPT_BIT('m', NULL, &rename, "move/rename a branch and its reflog", 1),
OPT_BIT('M', NULL, &rename, "move/rename a branch, even if target exists", 2),
OPT_BOOLEAN('l', NULL, &reflog, "create the branch's reflog"),
- OPT_BOOLEAN('f', NULL, &force_create, "force creation (when already exists)"),
+ OPT_BOOLEAN('f', "force", &force_create, "force creation (when already exists)"),
{
OPTION_CALLBACK, 0, "no-merged", &merge_filter_ref,
"commit", "print only not merged branches",
diff --git a/builtin-checkout.c b/builtin-checkout.c
index c6d6ac9..36e2116 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -584,7 +584,7 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
2),
OPT_SET_INT('3', "theirs", &opts.writeout_stage, "stage",
3),
- OPT_BOOLEAN('f', NULL, &opts.force, "force"),
+ OPT_BOOLEAN('f', "force", &opts.force, "force"),
OPT_BOOLEAN('m', "merge", &opts.merge, "merge"),
OPT_STRING(0, "conflict", &conflict_style, "style",
"conflict style (merge or diff3)"),
diff --git a/builtin-clean.c b/builtin-clean.c
index 05c763c..28cdcd0 100644
--- a/builtin-clean.c
+++ b/builtin-clean.c
@@ -41,7 +41,7 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
struct option options[] = {
OPT__QUIET(&quiet),
OPT__DRY_RUN(&show_only),
- OPT_BOOLEAN('f', NULL, &force, "force"),
+ OPT_BOOLEAN('f', "force", &force, "force"),
OPT_BOOLEAN('d', NULL, &remove_directories,
"remove whole directories"),
OPT_BOOLEAN('x', NULL, &ignored, "remove ignored files, too"),
diff --git a/builtin-mv.c b/builtin-mv.c
index b592c36..1b20028 100644
--- a/builtin-mv.c
+++ b/builtin-mv.c
@@ -53,7 +53,7 @@ int cmd_mv(int argc, const char **argv, const char *prefix)
int verbose = 0, show_only = 0, force = 0, ignore_errors = 0;
struct option builtin_mv_options[] = {
OPT__DRY_RUN(&show_only),
- OPT_BOOLEAN('f', NULL, &force, "force move/rename even if target exists"),
+ OPT_BOOLEAN('f', "force", &force, "force move/rename even if target exists"),
OPT_BOOLEAN('k', NULL, &ignore_errors, "skip move/rename errors"),
OPT_END(),
};
diff --git a/builtin-tag.c b/builtin-tag.c
index a51a6d1..c479018 100644
--- a/builtin-tag.c
+++ b/builtin-tag.c
@@ -390,7 +390,7 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
OPT_BOOLEAN('s', NULL, &sign, "annotated and GPG-signed tag"),
OPT_STRING('u', NULL, &keyid, "key-id",
"use another key to sign the tag"),
- OPT_BOOLEAN('f', NULL, &force, "replace the tag if exists"),
+ OPT_BOOLEAN('f', "force", &force, "replace the tag if exists"),
OPT_GROUP("Tag listing options"),
{
--
1.6.4.1
^ permalink raw reply related
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