* Re: Generating patches/Cherry Picking for a large number of commits
From: Jeff King @ 2009-08-28 21:54 UTC (permalink / raw)
To: Alydis; +Cc: git
In-Reply-To: <ae09c2a40908281250r42275a3o96825b89e725bace@mail.gmail.com>
On Fri, Aug 28, 2009 at 02:50:53PM -0500, Alydis wrote:
> While I have your attention, however, I noticed that git am <path>
> will apply the list patches generated by format-patch. The
> documentation said something about mbox/maildir directories, which I
> actually am not that familiar with. Is it safe to say that git am
> <path> will read the path and apply patches in numerical order? Does
> it allow skipping?
It will apply the patches in the order given on the command line. When
your shell expands the "patches/*" glob, it will do so in lexically
sorted order. Meaning "0001" comes before "0002", etc, which is the
reason that format-patch zero-pads the filenames.
You can edit or delete the patches in your patch directory before
applying, and they should apply the same (unless you create a patch that
cannot actually be applied).
-Peff
^ permalink raw reply
* Re: Using git to track my PhD thesis, couple of questions
From: david @ 2009-08-28 21:44 UTC (permalink / raw)
To: demerphq; +Cc: seanh, git
In-Reply-To: <9b18b3110908280912o271dc095o67bc82b31e91680e@mail.gmail.com>
On Fri, 28 Aug 2009, demerphq wrote:
> 2009/8/28 seanh <seanh.nospam@gmail.com>:
>> On Fri, Aug 28, 2009 at 12:21:42AM +0200, demerphq wrote:
>>> As you can generate the PDF's from the latex then just hack gitweb to
>>> let them download it from there.
>>
>> Unfortunately gitweb is written in Perl. But I know what you mean, it
>> should in theory be possible for them to click on a 'Get PDF' link for a
>> particular revision that causes the PDF to be built and returned to
>> their browser.
>
> What is unfortunate about that? Perl is a duct tape/swiss-army-knife
> of the internet. Hacking gitweb to generate PDF's on the fly from
> latex documents should be a fairly trivial hack, even if you aren't a
> Perl hacker.
I have a situation where I need to generae pdf's from files that are under
git. I have a git repository on by webserver that I push to and have a
trigger that regenerates the pdfs any time there is a push.
David Lang
> See:
>
> http://search.cpan.org/~andrewf/LaTeX-Driver-0.08/lib/LaTeX/Driver.pm
>
> for just one of many Perl modules to interface with with LaTeX.
>
> Good luck.
>
> Yves
>
>
^ permalink raw reply
* Re: Using git to track my PhD thesis, couple of questions
From: david @ 2009-08-28 21:42 UTC (permalink / raw)
To: Matthieu Moy; +Cc: seanh, git
In-Reply-To: <vpqpragt5bo.fsf@bauges.imag.fr>
On Fri, 28 Aug 2009, Matthieu Moy wrote:
> seanh <seanh.nospam@gmail.com> writes:
>
>> In response to Matthieu and Paolo, I'm not sure I understand the git
>> internals involved in the discussion around merge --squash, I had a
>> feeling this would produce a 'merge' that git in some sense would 'not
>> know about',
>
> Yes, that's it. Git does a merge, and immediately forgets it was a
> merge. The consequence is when you merge again later, Git will not be
> able to use the merge information to be clever about merging. Somehow,
> Git will be as bad as SVN for merging if you don't know what you're
> doing ;-).
I thought that was what rere did?
David Lang
^ permalink raw reply
* [PATCH 2/2] Allow testing of _relative family of time formatting and parsing functions
From: Alex Riesen @ 2009-08-28 21:05 UTC (permalink / raw)
To: git; +Cc: Jeff King, Nicolas Pitre, David Reiss, Junio C Hamano
In-Reply-To: <20090828210404.GA11867@blimp.localdomain>
To complement the testability of approxidate.
---
test-date.c | 17 +++++++++++++++++
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/test-date.c b/test-date.c
index 62e8f23..dcc7973 100644
--- a/test-date.c
+++ b/test-date.c
@@ -4,6 +4,17 @@ int main(int argc, char **argv)
{
int i;
+ 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 +26,12 @@ 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\n", argv[i], ctime(&t));
+
+ printf("relative: %s, out of %s\n",
+ show_date_relative(t, 0, &when), ctime(&t));
}
return 0;
}
--
1.6.4.1.263.g468a
^ permalink raw reply related
* [PATCH 1/2] Add date formatting and parsing functions relative to a given time
From: Alex Riesen @ 2009-08-28 21:04 UTC (permalink / raw)
To: git; +Cc: Jeff King, Nicolas Pitre, David Reiss, Junio C Hamano
The main purpose is to allow predictable testing of the code.
---
Rebased on current master.
cache.h | 2 +
date.c | 150 ++++++++++++++++++++++++++++++++++++--------------------------
2 files changed, 89 insertions(+), 63 deletions(-)
diff --git a/cache.h b/cache.h
index dd7f71e..3fb0166 100644
--- a/cache.h
+++ b/cache.h
@@ -731,9 +731,11 @@ 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);
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..0840e77 100644
--- a/date.c
+++ b/date.c
@@ -84,6 +84,67 @@ static int local_tzoffset(unsigned long time)
return offset * eastwest;
}
+const char *show_date_relative(unsigned long time, int tz, const struct timeval *now)
+{
+ static char timebuf[100 /* TODO: can be optimized */];
+ unsigned long diff;
+ 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;
+
+}
+
const char *show_date(unsigned long time, int tz, enum date_mode mode)
{
struct tm *tm;
@@ -95,63 +156,9 @@ 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);
}
if (mode == DATE_LOCAL)
@@ -866,19 +873,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 approximation(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 +900,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 approximation(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 approximation(date, &tv);
+}
+
--
1.6.4.1.263.g468a
^ permalink raw reply related
* Re: [PATCH] Allow testing of _relative family of time formatting and parsing functions
From: Alex Riesen @ 2009-08-28 20:54 UTC (permalink / raw)
To: Jeff King; +Cc: Nicolas Pitre, David Reiss, git
In-Reply-To: <20090828205232.GD9233@blimp.localdomain>
Alex Riesen, Fri, Aug 28, 2009 22:52:32 +0200:
> According to Wikipedia, absolutely nothing of note happened
> at the day 10 January, 1990.
1 Jan. 1990, not 10.
^ permalink raw reply
* [PATCH] Allow testing of _relative family of time formatting and parsing functions
From: Alex Riesen @ 2009-08-28 20:52 UTC (permalink / raw)
To: Jeff King; +Cc: Nicolas Pitre, David Reiss, git
In-Reply-To: <20090828193302.GB9233@blimp.localdomain>
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
$
According to Wikipedia, absolutely nothing of note happened
at the day 10 January, 1990.
test-date.c | 17 +++++++++++++++++
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/test-date.c b/test-date.c
index 62e8f23..dcc7973 100644
--- a/test-date.c
+++ b/test-date.c
@@ -4,6 +4,17 @@ int main(int argc, char **argv)
{
int i;
+ 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 +26,12 @@ 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\n", argv[i], ctime(&t));
+
+ printf("relative: %s, out of %s\n",
+ show_date_relative(t, 0, &when), ctime(&t));
}
return 0;
}
--
1.6.4.1.263.g468a
^ permalink raw reply related
* Re: [PATCH v4] import-tars: Allow per-tar author and commit message.
From: Junio C Hamano @ 2009-08-28 20:50 UTC (permalink / raw)
To: Peter Krefting; +Cc: git
In-Reply-To: <20090828185652.448AD189B7B@perkele>
Peter Krefting <peter@softwolves.pp.se> writes:
> + my $commit_msg = "Imported from $tar_file.";
> + my $this_committer_name = $committer_name;
> + my $this_committer_email = $committer_email;
> + my $this_author_name = $author_name;
> + my $this_author_email = $author_email;
> + if ($metaext ne '')
> + {
> + # Optionally read a commit message from <filename.tar>.msg
> + # Add a line on the form "Committer: name <e-mail>" to override
> + # the committer and "Author: name <e-mail>" to override the
> + # author for this tar ball.
> + if (open MSG, '<', "${tar_file}.${metaext}")
> + {
> + my $header_done = 0;
> + $commit_msg = '';
> + while (<MSG>)
> + {
> + if (!$header_done && /^Committer:\s+([^<>]*)\s+<(.*)>\s*$/i)
> + {
> + $this_committer_name = $1;
> + $this_committer_email = $2;
> + }
> + elsif (!$header_done && /^Author:\s+([^<>]*)\s+<(.*)>\s*$/i)
> + {
> + $this_author_name = $1;
> + $this_author_email = $2;
> + }
> + else
> + {
> + $commit_msg .= $_;
> + $header_done = 1;
> + }
> + }
> + close MSG;
> + }
> + }
> +
I think people would expect that if they put a blank line after the header
part, it would be stripped away, because a format that has a list of
colon-separated key-value pairs, followed by a blank line, and then
followed by the body of the message is so familiar.
While you are at it, can you also fix the style? Existing code in
import-tars.perl looks like this:
if ($typeflag == 2) { # symbolic link
print FI "data ", length($linkname), "\n", $linkname;
$mode = 0120000;
} else {
print FI "data $size\n";
while ($size > 0 && read(I, $_, 512) == 512) {
print FI substr($_, 0, $size);
$size -= 512;
}
}
i.e. opening brace comes at the end of the line of "if" and "else";
closing brace comes on the same line immediately before "else".
^ permalink raw reply
* Re: Generating patches/Cherry Picking for a large number of commits
From: Jakub Narebski @ 2009-08-28 20:34 UTC (permalink / raw)
To: Alydis; +Cc: Jeff King, git
In-Reply-To: <ae09c2a40908281250r42275a3o96825b89e725bace@mail.gmail.com>
[Alydis, please do not toppost]
Alydis <alydis@august8.net> writes:
> On Fri, Aug 28, 2009 at 2:45 PM, Jeff King<peff@peff.net> wrote:
>> On Fri, Aug 28, 2009 at 02:26:43PM -0500, Alydis wrote:
>>
>>> I've tried something along these lines:
>>>
[...]
>>> git format-patch -o patches v2.6.21..v2.6.30 arch/powerpc/boot
>>> git am -3 patches/*
>>>
>>> But, to my dismay, format-patch here tears apart the commits and
>>> applies ONLY the hunks that apply to the arch/powerpc/boot directory.
>>> What I'd much rather do is obtain a list of commits that apply to
>>> arch/powerpc/boot; but, then apply the entire patch.
>>
>> By default, format-patch (and log, gitk, etc) when given a path limiter
>> will also limit the diff shown. You can override it with --full-diff.
>
> Ack! Embarrassing RTFM.
>
> While I have your attention, however, I noticed that git am <path>
> will apply the list patches generated by format-patch. The
> documentation said something about mbox/maildir directories, which I
> actually am not that familiar with. Is it safe to say that git am
> <path> will read the path and apply patches in numerical order?
git-format-patch | git-am pipeline has to work correctly, as it
originally was the way (modulo extra options) git-rebase was
implemented. So yes, "git am <dir>" should understand and apply in
correct order result of "git format-patch -o <dir> <revspec>".
> Does it allow skipping?
There is "git am -i".
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Round-down years in "years+months" relative date view
From: Nicolas Pitre @ 2009-08-28 20:01 UTC (permalink / raw)
To: Alex Riesen; +Cc: Jeff King, David Reiss, git
In-Reply-To: <20090828194913.GC9233@blimp.localdomain>
On Fri, 28 Aug 2009, Alex Riesen wrote:
> Nicolas Pitre, Fri, Aug 28, 2009 21:27:53 +0200:
> > On Fri, 28 Aug 2009, Alex Riesen wrote:
> > > And shouldn't a linker complain regarding duplicated symbols, unless
> > > the other (library) symbol is defined as a weak symbol, allowing
> > > overriding it with another symbol of stronger linkage?
> >
> > Normally a linker would search for new objects to link only when there
> > are still symbols to resolve. If the library is well architected (mind
> > you I don't know if that is the case on Windows or OS X) you should find
> > many small object files in a library, so to have only related functions
> > together in a single object for only the needed code to be linked in the
> > final binary. Hence the printf symbol should be in a separate object
> > file than gettimeofday, etc.
> >
> > Only if the library's object file containing gettimeofday also contains
> > another symbol pulled by the linker will you see a duplicated symbol
> > error. But this is still a possibility. So your proposal is probably
> > cleaner.
>
> Is it so for dynamic linking as well? Like in libc.so?
Yes. The linker still links against stubs in that case.
Nicolas
^ permalink raw reply
* Re: Generating patches/Cherry Picking for a large number of commits
From: Alydis @ 2009-08-28 19:50 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20090828194556.GA13302@coredump.intra.peff.net>
Ack! Embarrassing RTFM.
While I have your attention, however, I noticed that git am <path>
will apply the list patches generated by format-patch. The
documentation said something about mbox/maildir directories, which I
actually am not that familiar with. Is it safe to say that git am
<path> will read the path and apply patches in numerical order? Does
it allow skipping?
Thanks again,
Tommy Wang
On Fri, Aug 28, 2009 at 2:45 PM, Jeff King<peff@peff.net> wrote:
> On Fri, Aug 28, 2009 at 02:26:43PM -0500, Alydis wrote:
>
>> I've tried something along these lines:
>>
>> git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
>> cd linux-2.6
>> git checkout -b mybranch v2.6.21
>> git format-patch -o patches v2.6.21..v2.6.30 arch/powerpc/boot
>> git am -3 patches/*
>>
>> But, to my dismay, format-patch here tears apart the commits and
>> applies ONLY the hunks that apply to the arch/powerpc/boot directory.
>> What I'd much rather do is obtain a list of commits that apply to
>> arch/powerpc/boot; but, then apply the entire patch.
>
> By default, format-patch (and log, gitk, etc) when given a path limiter
> will also limit the diff shown. You can override it with --full-diff.
>
> -Peff
>
^ permalink raw reply
* Re: [PATCH] Round-down years in "years+months" relative date view
From: Alex Riesen @ 2009-08-28 19:49 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jeff King, David Reiss, git
In-Reply-To: <alpine.LFD.2.00.0908281516440.6044@xanadu.home>
Nicolas Pitre, Fri, Aug 28, 2009 21:27:53 +0200:
> On Fri, 28 Aug 2009, Alex Riesen wrote:
> > And shouldn't a linker complain regarding duplicated symbols, unless
> > the other (library) symbol is defined as a weak symbol, allowing
> > overriding it with another symbol of stronger linkage?
>
> Normally a linker would search for new objects to link only when there
> are still symbols to resolve. If the library is well architected (mind
> you I don't know if that is the case on Windows or OS X) you should find
> many small object files in a library, so to have only related functions
> together in a single object for only the needed code to be linked in the
> final binary. Hence the printf symbol should be in a separate object
> file than gettimeofday, etc.
>
> Only if the library's object file containing gettimeofday also contains
> another symbol pulled by the linker will you see a duplicated symbol
> error. But this is still a possibility. So your proposal is probably
> cleaner.
Is it so for dynamic linking as well? Like in libc.so?
^ permalink raw reply
* Re: Generating patches/Cherry Picking for a large number of commits
From: Jeff King @ 2009-08-28 19:45 UTC (permalink / raw)
To: Alydis; +Cc: git
In-Reply-To: <ae09c2a40908281226r744141bm3a5bf4161ddab3e7@mail.gmail.com>
On Fri, Aug 28, 2009 at 02:26:43PM -0500, Alydis wrote:
> I've tried something along these lines:
>
> git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
> cd linux-2.6
> git checkout -b mybranch v2.6.21
> git format-patch -o patches v2.6.21..v2.6.30 arch/powerpc/boot
> git am -3 patches/*
>
> But, to my dismay, format-patch here tears apart the commits and
> applies ONLY the hunks that apply to the arch/powerpc/boot directory.
> What I'd much rather do is obtain a list of commits that apply to
> arch/powerpc/boot; but, then apply the entire patch.
By default, format-patch (and log, gitk, etc) when given a path limiter
will also limit the diff shown. You can override it with --full-diff.
-Peff
^ permalink raw reply
* Re: [PATCH] Round-down years in "years+months" relative date view
From: Alex Riesen @ 2009-08-28 19:33 UTC (permalink / raw)
To: Jeff King; +Cc: Nicolas Pitre, David Reiss, git
In-Reply-To: <81b0412b0908281220o1c378d5dn6ed52c8d55a9cdec@mail.gmail.com>
From fe67532bdf095dc9ebc0c7dd67be384e807a197c Mon Sep 17 00:00:00 2001
From: Alex Riesen <raa.lkml@gmail.com>
Date: Fri, 28 Aug 2009 20:59:59 +0200
Subject: [PATCH] Add date formatting functions with current time explicitely formatted
It should allow safe testing of this part of the code.
---
Alex Riesen, Fri, Aug 28, 2009 21:20:50 +0200:
> On Fri, Aug 28, 2009 at 21:15, Jeff King<peff@peff.net> wrote:
> > On Fri, Aug 28, 2009 at 09:03:19PM +0200, Alex Riesen wrote:
> >
> >> +unsigned long approxidate(const char *date)
> >> +{
> >> + struct timeval tv;
> >> + gettimeofday(&tv, NULL);
> >> + return approxidate_relative(date, &tv);
> >> +}
> >
> > This now always calls gettimeofday, whereas the original approxidate
> > only did if parse_date failed.
>
> Oh, bugger...
>
Rather like this, I mean :)
cache.h | 2 +
date.c | 150 ++++++++++++++++++++++++++++++++++++--------------------------
2 files changed, 89 insertions(+), 63 deletions(-)
diff --git a/cache.h b/cache.h
index dd7f71e..3fb0166 100644
--- a/cache.h
+++ b/cache.h
@@ -731,9 +731,11 @@ 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);
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 409a17d..171e68f 100644
--- a/date.c
+++ b/date.c
@@ -84,6 +84,67 @@ static int local_tzoffset(unsigned long time)
return offset * eastwest;
}
+const char *show_date_relative(unsigned long time, int tz, const struct timeval *now)
+{
+ static char timebuf[100 /* TODO: can be optimized */];
+ unsigned long diff;
+ 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 + 183) / 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;
+
+}
+
const char *show_date(unsigned long time, int tz, enum date_mode mode)
{
struct tm *tm;
@@ -95,63 +156,9 @@ 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 + 183) / 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);
}
if (mode == DATE_LOCAL)
@@ -866,19 +873,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 approximation(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 +900,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 approximation(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 approximation(date, &tv);
+}
+
--
1.6.4.1.261.gf9874
^ permalink raw reply related
* Re: [PATCH] Round-down years in "years+months" relative date view
From: Nicolas Pitre @ 2009-08-28 19:27 UTC (permalink / raw)
To: Alex Riesen; +Cc: Jeff King, David Reiss, git
In-Reply-To: <81b0412b0908281208h20aa6e81od3d6567fdffa0dec@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1618 bytes --]
On Fri, 28 Aug 2009, Alex Riesen wrote:
> On Fri, Aug 28, 2009 at 21:00, Nicolas Pitre<nico@cam.org> wrote:
> >> >> Microsoft's compiler and libraries? MacOSX?
> >> >
> >> > Are you saying you know those to be platforms with problems, or are you
> >> > asking whether those platforms will have problems?
> >>
> >> Both: MS never had weak/vague linkage, but I don't know about MacOSX.
> >
> > This is not about weak or vague linkage. This is plain basic linker
> > feature where no library object needs to be linked if there is no symbol
> > to resolve.
>
> Maybe I missed something, but wasn't the idea to overwrite gettimeofday
> with a public gettimeofday, defined in one of the object files?
Yes, in test-date.o.
> And shouldn't a linker complain regarding duplicated symbols, unless
> the other (library) symbol is defined as a weak symbol, allowing
> overriding it with another symbol of stronger linkage?
Normally a linker would search for new objects to link only when there
are still symbols to resolve. If the library is well architected (mind
you I don't know if that is the case on Windows or OS X) you should find
many small object files in a library, so to have only related functions
together in a single object for only the needed code to be linked in the
final binary. Hence the printf symbol should be in a separate object
file than gettimeofday, etc.
Only if the library's object file containing gettimeofday also contains
another symbol pulled by the linker will you see a duplicated symbol
error. But this is still a possibility. So your proposal is probably
cleaner.
Nicolas
^ permalink raw reply
* Generating patches/Cherry Picking for a large number of commits
From: Alydis @ 2009-08-28 19:26 UTC (permalink / raw)
To: git
Hi,
Newly converted git user here. I've stopped working with Subversion
ever since working with the Linux kernel has introduced me to git, and
never looked back!
I am currently working on a project in which I'm trying to backport
the powerpc boot-wrapper and device tree handling from Linux 2.6.30
into Linux 2.6.21. We have some third party vendor code that is not
ready for the (new) completely fair scheduler just yet. Yet, our BSP
relies on cuImage and the DTS files.
The approach I'm taking is to try to cherry-pick any commits between
v2.6.21 and v2.6.30 on the Linux kernel git repository that touch any
file in the arch/powerpc/boot directory into a v2.6.21 branch (and
pray that the conflicts are manageable).
I've tried something along these lines:
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
cd linux-2.6
git checkout -b mybranch v2.6.21
git format-patch -o patches v2.6.21..v2.6.30 arch/powerpc/boot
git am -3 patches/*
But, to my dismay, format-patch here tears apart the commits and
applies ONLY the hunks that apply to the arch/powerpc/boot directory.
What I'd much rather do is obtain a list of commits that apply to
arch/powerpc/boot; but, then apply the entire patch.
I'm a bit lost at how to proceed at this point? Do I need to write my
own script that uses git-log to grab the commit hashes that I want,
then call format-patch (or diff/apply/etc) individually on each of
them? I realize I'll have to handle patch numbering myself, if I were
to do that (luckily, I believe format-patch allows you to specify the
starting number). I also know at some point, I'll have to drill down
into individual commits and do some more detailed cherry picking to
form the desired patch series. This script seems like a good deal of
work for me... so before I go off and start it, I was wondering if the
git gurus have any clever solutions for me?
Thanks,
Tommy Wang
^ permalink raw reply
* Re: [BUG] git stash refuses to save after "add -N"
From: Jeff King @ 2009-08-28 19:22 UTC (permalink / raw)
To: Yann Dirson; +Cc: git
In-Reply-To: <20090828190531.GB11488@coredump.intra.peff.net>
On Fri, Aug 28, 2009 at 03:05:31PM -0400, Jeff King wrote:
> For the index case, we unfortunately cannot represent the situation in
> the index using a tree, which means we cannot have a stash that doesn't
> lose information. So we have to choose either dropping those index
> entries, inserting them as blank files, or inserting them with
> working-tree contents.
Actually, you _could_ try representing the information by shoe-horning
it into the tree. For example, by allocating a bit of the mode as
"intent-to-add". That seems pretty ugly to me, though.
You could also try to stick the information in the stash's commit
message and recreate it during "stash apply". But again, that feels kind
of ugly.
-Peff
^ permalink raw reply
* Re: [PATCH] Round-down years in "years+months" relative date view
From: Alex Riesen @ 2009-08-28 19:20 UTC (permalink / raw)
To: Jeff King; +Cc: Nicolas Pitre, David Reiss, git
In-Reply-To: <20090828191521.GA12292@coredump.intra.peff.net>
On Fri, Aug 28, 2009 at 21:15, Jeff King<peff@peff.net> wrote:
> On Fri, Aug 28, 2009 at 09:03:19PM +0200, Alex Riesen wrote:
>
>> +unsigned long approxidate(const char *date)
>> +{
>> + struct timeval tv;
>> + gettimeofday(&tv, NULL);
>> + return approxidate_relative(date, &tv);
>> +}
>
> This now always calls gettimeofday, whereas the original approxidate
> only did if parse_date failed.
Oh, bugger...
> On the other hand, refactoring the relative date code into its own
> function is probably a good thing in the long run.
Exactly.
^ permalink raw reply
* [PATCH] git submodule add: make the <path> parameter optional
From: Jens Lehmann @ 2009-08-28 19:19 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Junio C Hamano, git
When <path> is not given, use the "humanish" part of the source repository
instead.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
With this patch, git submodule add behaves like git clone in this respect.
Documentation/git-submodule.txt | 8 ++++++--
git-submodule.sh | 7 ++++++-
t/t7400-submodule-basic.sh | 16 ++++++++++++++++
3 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index 5ccdd18..4ef70c4 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -10,7 +10,7 @@ SYNOPSIS
--------
[verse]
'git submodule' [--quiet] add [-b branch]
- [--reference <repository>] [--] <repository> <path>
+ [--reference <repository>] [--] <repository> [<path>]
'git submodule' [--quiet] status [--cached] [--recursive] [--] [<path>...]
'git submodule' [--quiet] init [--] [<path>...]
'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--rebase]
@@ -69,7 +69,11 @@ add::
to the changeset to be committed next to the current
project: the current project is termed the "superproject".
+
-This requires two arguments: <repository> and <path>.
+This requires at least one argument: <repository>. The optional
+argument <path> is the relative location for the cloned submodule
+to exist in the superproject. If <path> is not given, the
+"humanish" part of the source repository is used ("repo" for
+"/path/to/repo.git" and "foo" for "host.xz:foo/.git").
+
<repository> is the URL of the new submodule's origin repository.
This may be either an absolute URL, or (if it begins with ./
diff --git a/git-submodule.sh b/git-submodule.sh
index bfbd36b..0c617eb 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -5,7 +5,7 @@
# Copyright (c) 2007 Lars Hjemli
dashless=$(basename "$0" | sed -e 's/-/ /')
-USAGE="[--quiet] add [-b branch] [--reference <repository>] [--] <repository> <path>
+USAGE="[--quiet] add [-b branch] [--reference <repository>] [--] <repository> [<path>]
or: $dashless [--quiet] status [--cached] [--recursive] [--] [<path>...]
or: $dashless [--quiet] init [--] [<path>...]
or: $dashless [--quiet] update [--init] [-N|--no-fetch] [--rebase] [--reference <repository>] [--merge] [--recursive] [--] [<path>...]
@@ -160,6 +160,11 @@ cmd_add()
repo=$1
path=$2
+ if test -z "$path"; then
+ path=$(echo "$repo" |
+ sed -e 's|/$||' -e 's|:*/*\.git$||' -e 's|.*[/:]||g')
+ fi
+
if test -z "$repo" -o -z "$path"; then
usage
fi
diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
index 0f2ccc6..a0cc99a 100755
--- a/t/t7400-submodule-basic.sh
+++ b/t/t7400-submodule-basic.sh
@@ -306,4 +306,20 @@ test_expect_success 'submodule <invalid-path> warns' '
'
+test_expect_success 'add submodules without specifying an explicit path' '
+ mkdir repo &&
+ cd repo &&
+ git init &&
+ echo r >r &&
+ git add r &&
+ git commit -m "repo commit 1" &&
+ cd .. &&
+ git clone --bare repo/ bare.git &&
+ cd addtest &&
+ git submodule add "$submodurl/repo" &&
+ git config -f .gitmodules submodule.repo.path repo &&
+ git submodule add "$submodurl/bare.git" &&
+ git config -f .gitmodules submodule.bare.path bare
+'
+
test_done
--
1.6.4.1.246.g7bae7.dirty
^ permalink raw reply related
* Re: gittogether '09
From: Shawn O. Pearce @ 2009-08-28 19:17 UTC (permalink / raw)
To: Brandon Casey; +Cc: Git Mailing List
In-Reply-To: <B4HB1FEv7c_CIWG-9fK8wLMj4F7i2ueS_jaxoD63gy5Bh46mgkoxGg@cipher.nrlssc.navy.mil>
Brandon Casey <brandon.casey.ctr@nrlssc.navy.mil> wrote:
>
> I haven't heard much about this in a while.
> Is it still going to happen?
Yes. I need to get started on this, its about that time. :-)
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Round-down years in "years+months" relative date view
From: Jeff King @ 2009-08-28 19:15 UTC (permalink / raw)
To: Alex Riesen; +Cc: Nicolas Pitre, David Reiss, git
In-Reply-To: <20090828190319.GA9233@blimp.localdomain>
On Fri, Aug 28, 2009 at 09:03:19PM +0200, Alex Riesen wrote:
> +unsigned long approxidate(const char *date)
> +{
> + struct timeval tv;
> + gettimeofday(&tv, NULL);
> + return approxidate_relative(date, &tv);
> +}
This now always calls gettimeofday, whereas the original approxidate
only did if parse_date failed.
I think you could also make this patch much smaller by just wrapping the
whole function and using a '0' sentinel for "you need to fill in the
time." Like:
---
diff --git a/date.c b/date.c
index 409a17d..b084d19 100644
--- a/date.c
+++ b/date.c
@@ -86,6 +86,14 @@ static int local_tzoffset(unsigned long time)
const char *show_date(unsigned long time, int tz, enum date_mode mode)
{
+ struct timeval now;
+ now.tv_sec = 0;
+ show_date_at_time(time, tz, mode, &now);
+}
+
+const char *show_date_at_time(unsigned long time, int tz, enum date_mode mode,
+ struct timeval now)
+{
struct tm *tm;
static char timebuf[200];
@@ -96,8 +104,8 @@ 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)
+ gettimeofday(&now, NULL);
if (now.tv_sec < time)
return "in the future";
diff = now.tv_sec - time;
On the other hand, refactoring the relative date code into its own
function is probably a good thing in the long run.
-Peff
^ permalink raw reply related
* Re: [PATCH] Round-down years in "years+months" relative date view
From: Alex Riesen @ 2009-08-28 19:08 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jeff King, David Reiss, git
In-Reply-To: <alpine.LFD.2.00.0908281458370.6044@xanadu.home>
On Fri, Aug 28, 2009 at 21:00, Nicolas Pitre<nico@cam.org> wrote:
>> >> Microsoft's compiler and libraries? MacOSX?
>> >
>> > Are you saying you know those to be platforms with problems, or are you
>> > asking whether those platforms will have problems?
>>
>> Both: MS never had weak/vague linkage, but I don't know about MacOSX.
>
> This is not about weak or vague linkage. This is plain basic linker
> feature where no library object needs to be linked if there is no symbol
> to resolve.
Maybe I missed something, but wasn't the idea to overwrite gettimeofday
with a public gettimeofday, defined in one of the object files?
And shouldn't a linker complain regarding duplicated symbols, unless
the other (library) symbol is defined as a weak symbol, allowing
overriding it with another symbol of stronger linkage?
>> I suspect them to have the same deficiency, but I'd be glad to be wrong.
>
> Are you able to test it?
>
Only the MS, but it is not interesting.
^ permalink raw reply
* Re: [RFC PATCH] upload-pack: expand capability advertises additional refs
From: Junio C Hamano @ 2009-08-28 19:07 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: git, Nicolas Pitre, Julian Phillips, Daniel Barkalow,
Johannes Schindelin
In-Reply-To: <20090828173007.GX1033@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> static void upload_pack(void)
> {
> + git_config(upload_pack_config, NULL);
> + if (!configured_advertise)
> + push_advertise("refs/*");
> +
> + head_ref(scan_ref, NULL);
> + for_each_ref(scan_ref, NULL);
> +
> reset_timeout();
> - head_ref(send_ref, NULL);
> - for_each_ref(send_ref, NULL);
> - packet_flush(1);
> + send_refs();
> receive_needs();
> if (want_obj.nr) {
> get_common_commits();
> @@ -652,6 +764,7 @@ int main(int argc, char **argv)
>
> git_extract_argv0_path(argv[0]);
> read_replace_refs = 0;
> + push_advertise("HEAD");
>
> for (i = 1; i < argc; i++) {
> char *arg = argv[i];
> @@ -667,6 +780,10 @@ int main(int argc, char **argv)
> daemon_mode = 1;
> continue;
> }
> + if (!prefixcmp(arg, "--expand=")) {
> + push_advertise(arg + 9);
> + continue;
> + }
> if (!strcmp(arg, "--")) {
> i++;
> break;
This arrangement of push_advertise() calls are rather curious. I think
your design guidelines are:
- We do want to advertise HEAD, so it can (and should) be unconditional;
- We may want to restrict with configuration, or use "refs/*" as the
fallback default;
- We may want to (extend|replace) advertised set configured in the
configuration file.
I would naively expect the above to be implemented in this order:
- In main, first thing is to do the git_config() bit; if to_advertise is
non-empty after git_config() returns, we have seen upload.advertise.
Otherwise we haven't. Push "refs/*" in the latter case.
- Then, parse the command line. Do we see "--expand="? If so:
. When handling the first "--expand=", clear to_advertise list. This
step is optional---necessary only if we want to make config variable
override-able ;-);
. Then, push the pattern in.
- And finally push "HEAD" in unconditionally.
Which would mean a few things:
- Your version always extends what is read from the configuration with
--expand=, but I think replacing would be the right thing to do.
- configured_advertise global variable can go.
- Instead, to implement "--expand= replaces", we need a local variable in
main() to remember if we already cleared to_advertise of the patterns
read from the configuration file, and use it in the part that parses
"--expand=".
But I may not be thinking clearly; I was up all night because I couldn't
sleep under loud noises of fire-fighting helicopters...
^ permalink raw reply
* Re: [BUG] git stash refuses to save after "add -N"
From: Jeff King @ 2009-08-28 19:05 UTC (permalink / raw)
To: Yann Dirson; +Cc: git
In-Reply-To: <54e098c45bffbf870bdfcee26b9ddecc.squirrel@intranet.linagora.com>
On Fri, Aug 28, 2009 at 01:02:23PM +0200, Yann Dirson wrote:
> $ echo foo > bar
> $ git add -N bar
> $ ./git --exec-path=$PWD stash save
> bar: not added yet
> fatal: git-write-tree: error building trees
> Cannot save the current index state
>
> Maybe it would require some magic in git-stash to detect/save/restore that
> particular state, or "just" to cause "add -N" to insert an empty file
> instead ?
Yes, there needs to be some magic in git-stash to handle this. There are
actually two calls to write-tree: one to save the index and one to save
the working tree. I think the working tree one should be OK, because we
"git add -u" right beforehand, which means "intent-to-add" files will
be saved properly.
For the index case, we unfortunately cannot represent the situation in
the index using a tree, which means we cannot have a stash that doesn't
lose information. So we have to choose either dropping those index
entries, inserting them as blank files, or inserting them with
working-tree contents.
When you apply the stash, if they were:
- dropped, then you may be surprised to find that those files are now
untracked
- inserted as working-tree content, then you may not realize that you
had not _actually_ added that content to the index earlier, and just
commit it
- 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 think that
would require a new 'ls-files' flag to list intent-to-add files.
-Peff
^ permalink raw reply
* Re: [PATCH] Round-down years in "years+months" relative date view
From: Alex Riesen @ 2009-08-28 19:03 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jeff King, David Reiss, git
In-Reply-To: <alpine.LFD.2.00.0908281307510.6044@xanadu.home>
>From b51bc56816490c71cd37f52be73a06cef6b9bf14 Mon Sep 17 00:00:00 2001
From: Alex Riesen <raa.lkml@gmail.com>
Date: Fri, 28 Aug 2009 20:59:59 +0200
Subject: [PATCH] Add date formatting functions with current time explicitely formatted
It should allow safe testing of this part of the code.
---
Nicolas Pitre, Fri, Aug 28, 2009 19:28:34 +0200:
> On Fri, 28 Aug 2009, Jeff King wrote:
> > On Fri, Aug 28, 2009 at 09:58:27AM +0200, Alex Riesen wrote:
> >
> > > > I couldn't find any tests related to relative date processing, so it
> > > > would be really nice to have some. But I'm not sure of the best way to
> > > > do it without dealing with race conditions. Annoyingly, show_date calls
> > > > gettimeofday at a pretty low level, so there isn't a way of
> > > > instrumenting it short of LD_PRELOAD trickery (which is probably not
> > > > very portable).
> > >
> > > Maybe better prepare the _test_ so that it uses current time and time
> > > arithmetics then put yet another cludge in operational code? Especially
> > > when we already have a greate number of GIT_ environment variables,
> > > documented nowhere, with effects not immediately obvious:
> >
> > But that's the point: you can't do that without a race condition. Your
> > test gets a sense of the current time, then runs git, which checks the
> > current time again. How many seconds elapsed between the two checks?
> >
> > I guess it is good enough for testing large time spans, but I was hoping
> > for a comprehensive time test.
>
> I agree with your concern. This is why I created the --index-version
> switch to pack-objects.
>
This is what I mean with "supplying current time":
cache.h | 2 +
date.c | 130 ++++++++++++++++++++++++++++++++++----------------------------
2 files changed, 73 insertions(+), 59 deletions(-)
diff --git a/cache.h b/cache.h
index dd7f71e..3fb0166 100644
--- a/cache.h
+++ b/cache.h
@@ -731,9 +731,11 @@ 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);
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 409a17d..08b4b49 100644
--- a/date.c
+++ b/date.c
@@ -84,6 +84,67 @@ static int local_tzoffset(unsigned long time)
return offset * eastwest;
}
+const char *show_date_relative(unsigned long time, int tz, const struct timeval *now)
+{
+ static char timebuf[100 /* TODO: can be optimized */];
+ unsigned long diff;
+ 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 + 183) / 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;
+
+}
+
const char *show_date(unsigned long time, int tz, enum date_mode mode)
{
struct tm *tm;
@@ -95,63 +156,9 @@ 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 + 183) / 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);
}
if (mode == DATE_LOCAL)
@@ -866,19 +873,17 @@ static const char *approxidate_digit(const char *date, struct tm *tm, int *num)
return end;
}
-unsigned long approxidate(const char *date)
+unsigned long approxidate_relative(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 +904,10 @@ unsigned long approxidate(const char *date)
tm.tm_year--;
return mktime(&tm);
}
+
+unsigned long approxidate(const char *date)
+{
+ struct timeval tv;
+ gettimeofday(&tv, NULL);
+ return approxidate_relative(date, &tv);
+}
--
1.6.4.1.261.gf9874
^ 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