* Re: git clone http://git.savannah.gnu.org/cgit/xboard.git segfaults
From: Tay Ray Chuan @ 2009-08-29 0:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Ali Polatel, git
In-Reply-To: <20090826131235.GF16486@harikalardiyari>
Hi,
2009/8/26 Ali Polatel <polatel@gmail.com>:
> It works, I don't get any segfaults after applying this patch.
Junio, I hope you don't mind me asking but why hasn't this patch been
accepted? It addresses a pretty severe problem, and the sooner users
have it the better.
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: How does git follow branch history across a merge commit?
From: Junio C Hamano @ 2009-08-29 0:01 UTC (permalink / raw)
To: Steven E. Harris; +Cc: git
In-Reply-To: <831vmv5wh7.fsf@torus.sehlabs.com>
"Steven E. Harris" <seh@panix.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> If you merge competition into your master, the resulting commit will
>> have your master as its first parent. If check out competition and
>> merge master in your example, the resulting merge will have
>> compatition as the first parent.
>
> I see, having run a few more experiments to confirm this.
>
> I missed the point that merge commits are not "predecessor neutral";
> they apparently have a bias indicating "/this branch/ received content
> from /that branch/ (or /those branches/)".
We are in principle pretty much neutral, but in certain places you
obviously cannot avoid tiebreaking. A commit object has to record parents
in a bytestream in its representation, and inevitably one parent must come
before another one.
You also must give your users some way to refer to each of its parents, so
naturally we count from one, and call them $it^ (== $it^1), $it^2, etc.
We do not have "$it^?" that lets you pick its parents at random, as we
haven't found a good use case for such a feature.
One place we tiebreak favoring earlier parents over later ones, even
though there is no logical reason to do so, is merge simplification [*1*].
When more than one parents have the same tree, with respect to pathspec
given, while traversing the history, we pick the earliest one, because
that is just as good as choosing one at random, and would give us a
reproducible result. For a similar reason, when blame follows a merge
from identical parents, it assigns blame to earlier parents.
And at the end-user workflow level, people tend to think "I merge others
work into mine", so the log family of commands have --first-parent option
to follow only that ancestry, but that logic kicks in only while browsing,
not while building histories.
[Footnote]
*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".
^ permalink raw reply
* Re: How does git follow branch history across a merge commit?
From: Steven E. Harris @ 2009-08-28 23:50 UTC (permalink / raw)
To: git
In-Reply-To: <7vmy5jbjkr.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> If you merge competition into your master, the resulting commit will
> have your master as its first parent. If check out competition and
> merge master in your example, the resulting merge will have
> compatition as the first parent.
I see, having run a few more experiments to confirm this.
I missed the point that merge commits are not "predecessor neutral";
they apparently have a bias indicating "/this branch/ received content
from /that branch/ (or /those branches/)".
To try to recreate my confusing scenario, I tried this:
,----
| git checkout competition
| git merge master
| # This fast-forwarded "competition" be equivalent to "master".
| git checkout 'HEAD^'
| # This wound up again at "master"'s predecessor, not "competition"'s.
`----
It seems that since fast-forward merges don't produce a commit, the
merge record remains in place recording that branch "competition" came
into branch "master". Even though we're checked out to branch
"competition" here, following its history back in time requires some
manual intervention. Do you concur, or is my example perhaps flawed?
--
Steven E. Harris
^ permalink raw reply
* Re: How does git follow branch history across a merge commit?
From: Junio C Hamano @ 2009-08-28 23:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steven E. Harris, git
In-Reply-To: <7vskfbcy9n.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> "Steven E. Harris" <seh@panix.com> writes:
>
>> Was it just luck that "HEAD^" referred to the predecessor that came from
>> branch "master" rather than branch "competition"?
>
> Yes, if you want the second parent you would say HEAD^2.
Ahh, I misread your question. No, it is not luck. If you merge
competition into your master, the resulting commit will have your master
as its first parent. If check out competition and merge master in your
example, the resulting merge will have compatition as the first parent.
^ permalink raw reply
* Re: How does git follow branch history across a merge commit?
From: Junio C Hamano @ 2009-08-28 23:30 UTC (permalink / raw)
To: Steven E. Harris; +Cc: git
In-Reply-To: <8363c75zug.fsf@torus.sehlabs.com>
"Steven E. Harris" <seh@panix.com> writes:
> Was it just luck that "HEAD^" referred to the predecessor that came from
> branch "master" rather than branch "competition"?
Yes, if you want the second parent you would say HEAD^2.
^ permalink raw reply
* How does git follow branch history across a merge commit?
From: Steven E. Harris @ 2009-08-28 22:37 UTC (permalink / raw)
To: git
This question concerns git's representation of merge commits.
I understand that branches in git are references to commit vertices in a
graph, that each of these vertices have zero or more reference edges to
a parent (predecessor) vertex, and that merges create vertices with at
least two parents. Walking back in time from a branch head involves
traversing parent edges.
But what happens when such traversal reaches a merge commit? If one asks
git to move back, say, in time by a few days, or so many predecessors,
how does it know (or choose) which way to go upon reaching a merge
commit?
I set up an experiment with two competing branches that require merging
back together:
,----
| mkdir gitexp && cd gitexp && git init
| $EDITOR file1.txt
| git add file1.txt
| git commit -m'Initial impound.'
| $EDITOR file1.txt
| git commit -a -m'Added a second line.'
|
| git checkout -b competition
| $EDITOR file1.txt
| git commit -a -m'Extended second line.'
|
| git checkout master
| $EDITOR file1.txt
| git commit -a -m'Added third line.'
|
| git checkout competition
| $EDITOR file1.txt
| git commit -a -m'Edited second line.'
| $EDITOR file1.txt
| git commit -a -m'Added an alternate third line.'
|
| git checkout master
| git merge competition
| # Edit to resolve conflict:
| $EDITOR file1.txt
| git commit -a
|
| git checkout 'HEAD^'
| # At this point, git picked the predecessor along branch "master".
`----
Was it just luck that "HEAD^" referred to the predecessor that came from
branch "master" rather than branch "competition"?
--
Steven E. Harris
^ permalink raw reply
* Re: Generating patches/Cherry Picking for a large number of commits
From: Junio C Hamano @ 2009-08-28 22:35 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Alydis, Jeff King, git
In-Reply-To: <m3k50nllt6.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> 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>".
You are not making any sense. rebase is done using --stdout and does not
rely on the intermediate files nor ordering of their names.
^ permalink raw reply
* [PATCH master] t/test-lib.sh: provide a shell implementation of the 'yes' utility
From: Brandon Casey @ 2009-08-28 22:32 UTC (permalink / raw)
To: gitster; +Cc: git, Brandon Casey
In-Reply-To: <tK_IWVRokJuwYhAJ3h5cvYFUGHzmrYoRPbMxLQUdj2eLINK_28NnVA@cipher.nrlssc.navy.mil>
From: Brandon Casey <drafnel@gmail.com>
Some platforms (IRIX 6.5, Solaris 7) do not provide the 'yes' utility.
Currently, some tests, including t7610 and t9001, try to call this program.
Due to the way the tests are structured, the tests still pass even though
this program is missing. Rather than succeeding by chance, let's provide
an implementation of the simple 'yes' utility in shell for all platforms to
use.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
t/test-lib.sh | 15 +++++++++++++++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index a5b8d03..f2ca536 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -685,6 +685,21 @@ do
esac
done
+# Provide an implementation of the 'yes' utility
+yes () {
+ if test $# = 0
+ then
+ y=y
+ else
+ y="$*"
+ fi
+
+ while echo "$y"
+ do
+ :
+ done
+}
+
# Fix some commands on Windows
case $(uname -s) in
*MINGW*)
--
1.6.4
^ permalink raw reply related
* Re: Generating patches/Cherry Picking for a large number of commits
From: Junio C Hamano @ 2009-08-28 22:31 UTC (permalink / raw)
To: Alydis; +Cc: Jeff King, git
In-Reply-To: <ae09c2a40908281250r42275a3o96825b89e725bace@mail.gmail.com>
Alydis <alydis@august8.net> writes:
> 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?
If you say "git am <directory>/*", like you have in your original message
shown *below* (sheesh, why am I responding to somebody who top-posts?),
you let your shell perform a numerical sort, so you would be Ok.
>>> git format-patch -o patches v2.6.21..v2.6.30 arch/powerpc/boot
>>> git am -3 patches/*
I do not think the above format-patch, even with --full-diff, is
necessarily a good idea nor would work in general.
Often, when a series is concocted, you would see this pattern:
* Early parts of the patch series to lay groundwork by introducing non
platform specific infrastructure; and then
* Later parts of the series utilizes the infrastructure to implement the
feature for particular platforms.
Obviously you are interested only for powerpc parts in the latter category
and would want to omit anything irrelevant to powerpc. But you do want to
include all of the former class, even if they do not touch anything inside
the powerpc area.
^ permalink raw reply
* Re: Using git to track my PhD thesis, couple of questions
From: demerphq @ 2009-08-28 22:16 UTC (permalink / raw)
To: david; +Cc: seanh, git
In-Reply-To: <alpine.DEB.2.00.0908281443070.28411@asgard.lang.hm>
2009/8/28 <david@lang.hm>:
> 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.
Actually this discussion makes me think that there is room for a hack
to gitweb to provide extensible and pluggable renderers of the files
in a repository. Such a framework would for instance provide for
syntax highlighting, PDF generation from latex files, etc.
Hypothetically it wouldnt be too hard to do. A Win32 (dare I say)
registry of file extensions/shebang lines would be linked into a set
of renderer plugin's, which in turn would automatically add the
required links to render the file as needed. Quite doable actually.
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* Re: [PATCH] Round-down years in "years+months" relative date view
From: A Large Angry SCM @ 2009-08-28 22:01 UTC (permalink / raw)
To: Jeff King; +Cc: Alex Riesen, David Reiss, git
In-Reply-To: <20090828171552.GA6821@coredump.intra.peff.net>
Jeff King wrote:
> On Fri, Aug 28, 2009 at 07:00:59PM +0200, Alex Riesen wrote:
>
>> On Fri, Aug 28, 2009 at 17:02, Jeff King<peff@peff.net> wrote:
>>> 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?
>> How _many_ do you need?
>
> I don't understand what you're trying to say. My point is that if you
> are checking results to a one-second precision, you need to know whether
> zero seconds elapsed, or one second, or two seconds, or whatever to get
> a consistent result.
To no-one in particular, Gitzilla mumbles "To do this right(tm) would
probably require LD_PRELOAD magic with a environment variable invocation.
^ permalink raw reply
* 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
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