* [PATCH v2 1/4] Add date formatting and parsing functions relative to a given time
From: Jeff King @ 2009-08-31 2:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, git
In-Reply-To: <20090831022228.GA4833@coredump.intra.peff.net>
From: Alex Riesen <raa.lkml@gmail.com>
The main purpose is to allow predictable testing of the code.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
---
Same as previous 1/3, but rebased onto lt/approxidate topic. The merge
ended up as quite a mess because of textual differences, so I had to
fix up a fair bit by hand; Alex, please confirm that I didn't screw
anything up too badly right before putting your name at the top. ;)
cache.h | 5 ++
date.c | 150 ++++++++++++++++++++++++++++++++++++--------------------------
2 files changed, 92 insertions(+), 63 deletions(-)
diff --git a/cache.h b/cache.h
index 808daba..5fad24c 100644
--- a/cache.h
+++ b/cache.h
@@ -731,9 +731,14 @@ enum date_mode {
};
const char *show_date(unsigned long time, int timezone, enum date_mode mode);
+const char *show_date_relative(unsigned long time, int tz,
+ const struct timeval *now,
+ char *timebuf,
+ size_t timebuf_size);
int parse_date(const char *date, char *buf, int bufsize);
void datestamp(char *buf, int bufsize);
unsigned long approxidate(const char *);
+unsigned long approxidate_relative(const char *date, const struct timeval *now);
enum date_mode parse_date_format(const char *format);
#define IDENT_WARN_ON_NO_NAME 1
diff --git a/date.c b/date.c
index e848d96..8e57e5e 100644
--- a/date.c
+++ b/date.c
@@ -86,6 +86,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,
+ char *timebuf,
+ size_t timebuf_size)
+{
+ unsigned long diff;
+ if (now->tv_sec < time)
+ return "in the future";
+ diff = now->tv_sec - time;
+ if (diff < 90) {
+ snprintf(timebuf, timebuf_size, "%lu seconds ago", diff);
+ return timebuf;
+ }
+ /* Turn it into minutes */
+ diff = (diff + 30) / 60;
+ if (diff < 90) {
+ snprintf(timebuf, timebuf_size, "%lu minutes ago", diff);
+ return timebuf;
+ }
+ /* Turn it into hours */
+ diff = (diff + 30) / 60;
+ if (diff < 36) {
+ snprintf(timebuf, timebuf_size, "%lu hours ago", diff);
+ return timebuf;
+ }
+ /* We deal with number of days from here on */
+ diff = (diff + 12) / 24;
+ if (diff < 14) {
+ snprintf(timebuf, timebuf_size, "%lu days ago", diff);
+ return timebuf;
+ }
+ /* Say weeks for the past 10 weeks or so */
+ if (diff < 70) {
+ snprintf(timebuf, timebuf_size, "%lu weeks ago", (diff + 3) / 7);
+ return timebuf;
+ }
+ /* Say months for the past 12 months or so */
+ if (diff < 360) {
+ snprintf(timebuf, timebuf_size, "%lu months ago", (diff + 15) / 30);
+ return timebuf;
+ }
+ /* Give years and months for 5 years or so */
+ if (diff < 1825) {
+ unsigned long years = diff / 365;
+ unsigned long months = (diff % 365 + 15) / 30;
+ int n;
+ n = snprintf(timebuf, timebuf_size, "%lu year%s",
+ years, (years > 1 ? "s" : ""));
+ if (months)
+ snprintf(timebuf + n, timebuf_size - n,
+ ", %lu month%s ago",
+ months, (months > 1 ? "s" : ""));
+ else
+ snprintf(timebuf + n, timebuf_size - n, " ago");
+ return timebuf;
+ }
+ /* Otherwise, just years. Centuries is probably overkill. */
+ snprintf(timebuf, timebuf_size, "%lu years ago", (diff + 183) / 365);
+ return timebuf;
+}
+
const char *show_date(unsigned long time, int tz, enum date_mode mode)
{
struct tm *tm;
@@ -97,63 +158,10 @@ const char *show_date(unsigned long time, int tz, enum date_mode mode)
}
if (mode == DATE_RELATIVE) {
- unsigned long diff;
struct timeval now;
gettimeofday(&now, NULL);
- if (now.tv_sec < time)
- return "in the future";
- diff = now.tv_sec - time;
- if (diff < 90) {
- snprintf(timebuf, sizeof(timebuf), "%lu seconds ago", diff);
- return timebuf;
- }
- /* Turn it into minutes */
- diff = (diff + 30) / 60;
- if (diff < 90) {
- snprintf(timebuf, sizeof(timebuf), "%lu minutes ago", diff);
- return timebuf;
- }
- /* Turn it into hours */
- diff = (diff + 30) / 60;
- if (diff < 36) {
- snprintf(timebuf, sizeof(timebuf), "%lu hours ago", diff);
- return timebuf;
- }
- /* We deal with number of days from here on */
- diff = (diff + 12) / 24;
- if (diff < 14) {
- snprintf(timebuf, sizeof(timebuf), "%lu days ago", diff);
- return timebuf;
- }
- /* Say weeks for the past 10 weeks or so */
- if (diff < 70) {
- snprintf(timebuf, sizeof(timebuf), "%lu weeks ago", (diff + 3) / 7);
- return timebuf;
- }
- /* Say months for the past 12 months or so */
- if (diff < 360) {
- snprintf(timebuf, sizeof(timebuf), "%lu months ago", (diff + 15) / 30);
- return timebuf;
- }
- /* Give years and months for 5 years or so */
- if (diff < 1825) {
- unsigned long years = diff / 365;
- unsigned long months = (diff % 365 + 15) / 30;
- int n;
- n = snprintf(timebuf, sizeof(timebuf), "%lu year%s",
- years, (years > 1 ? "s" : ""));
- if (months)
- snprintf(timebuf + n, sizeof(timebuf) - n,
- ", %lu month%s ago",
- months, (months > 1 ? "s" : ""));
- else
- snprintf(timebuf + n, sizeof(timebuf) - n,
- " ago");
- return timebuf;
- }
- /* Otherwise, just years. Centuries is probably overkill. */
- snprintf(timebuf, sizeof(timebuf), "%lu years ago", (diff + 183) / 365);
- return timebuf;
+ return show_date_relative(time, tz, &now,
+ timebuf, sizeof(timebuf));
}
if (mode == DATE_LOCAL)
@@ -918,19 +926,13 @@ static void pending_number(struct tm *tm, int *num)
}
}
-unsigned long approxidate(const char *date)
+static unsigned long approxidate_str(const char *date, const struct timeval *tv)
{
int number = 0;
struct tm tm, now;
- struct timeval tv;
time_t time_sec;
- char buffer[50];
- if (parse_date(date, buffer, sizeof(buffer)) > 0)
- return strtoul(buffer, NULL, 10);
-
- gettimeofday(&tv, NULL);
- time_sec = tv.tv_sec;
+ time_sec = tv->tv_sec;
localtime_r(&time_sec, &tm);
now = tm;
@@ -954,3 +956,25 @@ unsigned long approxidate(const char *date)
pending_number(&tm, &number);
return update_tm(&tm, &now, 0);
}
+
+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, 0);
+
+ return approxidate_str(date, tv);
+}
+
+unsigned long approxidate(const char *date)
+{
+ struct timeval tv;
+ char buffer[50];
+
+ if (parse_date(date, buffer, sizeof(buffer)) > 0)
+ return strtoul(buffer, NULL, 0);
+
+ gettimeofday(&tv, NULL);
+ return approxidate_str(date, &tv);
+}
--
1.6.4.2.373.g5881fd
^ permalink raw reply related
* Re: [PATCH 1/3] Add date formatting and parsing functions relative to a given time
From: Jeff King @ 2009-08-31 2:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, git
In-Reply-To: <20090830215127.GA16303@coredump.intra.peff.net>
On Sun, Aug 30, 2009 at 05:51:27PM -0400, Jeff King wrote:
> I think the most sane thing is to rebase the whole series on top of
> lt/approxidate. Let me see what I can do.
And here it is. It was a little more complex than a simple rebase
because lt/approxidate actually introduced new bugs. :) Hopefully this
will be the last re-roll required.
The new series applies on top of lt/approxidate, and contains:
[1/4]: Add date formatting and parsing functions relative to a given time
[2/4]: refactor test-date interface
[3/4]: tests: add date printing and parsing tests
[4/4]: fix approxidate parsing of relative months and years
-Peff
^ permalink raw reply
* Re: Improve on 'approxidate'
From: Jeff King @ 2009-08-31 1:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <20090830223558.GA29807@coredump.intra.peff.net>
On Sun, Aug 30, 2009 at 06:35:58PM -0400, Jeff King wrote:
> > + tm.tm_year = -1;
> > + tm.tm_mon = -1;
> > + tm.tm_mday = -1;
>
> This breaks relative dates like "3.months.ago", because
> approxidate_alpha needs to see the "current" date in tm (and now it sees
> -1, subtracts from it, and assumes we are just crossing a year boundary
> because of the negative). 3.years.ago is also broken, but I don't think
> 3.days.ago is.
>
> Probably we just need to pass "now" to approxidate_alpha, and it needs
> to call update_tm under the case for "months" and "years" (and I haven't
> quite figured out why those are not part of the "tl" list).
> Unfortunately, I'm out of time to look at it more right now, but I'll
> take a look tonight or tomorrow if you don't beat me to it.
OK, I looked at it.
The fix is pretty straightforward. We _do_ already pass "now" to
approxidate_alpha, and it looks like you already fixed the "typelen"
array case (which handles seconds, minutes, hours, days, and weeks) by
calling update_tm. But all of those units are convertible to seconds,
and months and years are not, which explains why they are handled
separately.
So I think we can just "cheat" and call update_tm to fill in the fields
from "now" as we would for the other units, and then tweak the "struct
tm" as we did before. I.e.,:
diff --git a/date.c b/date.c
index 8e57e5e..e9ee4aa 100644
--- a/date.c
+++ b/date.c
@@ -857,7 +857,9 @@ static const char *approxidate_alpha(const char *date, struct tm *tm, struct tm
}
if (match_string(date, "months") >= 5) {
- int n = tm->tm_mon - *num;
+ int n;
+ update_tm(tm, now, 0); /* fill in date fields if needed */
+ n = tm->tm_mon - *num;
*num = 0;
while (n < 0) {
n += 12;
@@ -868,6 +870,7 @@ static const char *approxidate_alpha(const char *date, struct tm *tm, struct tm
}
if (match_string(date, "years") >= 4) {
+ update_tm(tm, now, 0); /* fill in date fields if needed */
tm->tm_year -= *num;
*num = 0;
return end;
I'll wrap this fix up in a commit message with tests and add it to the
"test approxidate" series I'm brewing.
-Peff
^ permalink raw reply related
* Re: git-svn messing up merge commits on dcommit
From: Eric Wong @ 2009-08-31 1:37 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: git
In-Reply-To: <20090830013225.GA6475@atjola.homenet>
Björn Steinbrink <B.Steinbrink@gmx.de> wrote:
> Hi Eric,
>
> I have two "test cases" here (attached), which I actually wrote months
> ago, but forgot to sent, as I wanted to clean them up/turn them into
> something suitable for the test suite, but honestly, I'll probably never
> get around to do that, so here they are, as they are. They show git-svn
> messing up merge commits when dcommitting a branch that is not
> up-to-date WRT the svn repo.
>
> The basic history for both cases (before dcommit) is:
>
> C---D (master)
> / /
> /---E (side)
> /
> A---B (trunk)
> \
> X (revision in SVN, not yet fetched)
>
> So the dcommit (which would send C and D to the svn repo) needs to
> "rebase" C and D.
>
> In the first test case, this rebasing causes conflicts, and leads to a
> linearized history:
>
> E (side)
> /
> A---B---X---C' (trunk)
> \
> D (master)
>
> The merge is broken apart. This is probably expected, but I thought I'd
> tell anyway.
As noted in the CAVEATS section of the manpage, pull/merge isn't
recommended with dcommit because it generates non-linear history.
Keep in mind this was written before SVN got merge tracking support, but
I haven't been particularly motivated to revisit the topic since then...
> I hope that makes any sense to you (or you can figure it out from the
> testing scripts).
Thanks for posting these, though. They do seem to be good test cases
for developing on and hopefully somebody with more interest in
this topic can pick up where we leave off.
On a side note, I have been meaning to refactor git svn and break it
apart into separate Perl modules for easier hacking for the longest time
now...
--
Eric Wong
^ permalink raw reply
* What your score?
From: Frederik Briggs @ 2009-08-31 2:18 UTC (permalink / raw)
To: git
You will never find such cheap pils anywhere! http://tsokq.naifliorh.com/
^ permalink raw reply
* Re: how to add an empty initial commit
From: bill lam @ 2009-08-31 0:06 UTC (permalink / raw)
To: Sean Estabrooks; +Cc: git
In-Reply-To: <BLU0-SMTP13B5A682834BA2E926F610AEF30@phx.gbl>
On Sat, 29 Aug 2009, Sean Estabrooks wrote:
> This sounds like a hard way to go about things. Instead, you can edit
> the files as you wish, "git add" the new edits, and then use
> "git commit --amend" to alter the initial commit. Don't think rebase
> would help in the situation you describe.
Sean,
Yes, you are correct. git-rebase does not help much. It has to initialise
another empty git repo and copy all commits to there.
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
^ permalink raw reply
* Re: [PATCH] Documentation/git-add.txt: Explain --patch option in layman terms
From: Junio C Hamano @ 2009-08-30 23:31 UTC (permalink / raw)
To: Jari Aalto; +Cc: git
In-Reply-To: <87ab1gaol2.fsf@jondo.cante.net>
Jari Aalto <jari.aalto@cante.net> writes:
> I think the convention used in git's manual pages deviate from the
> standard practise. We could make the git manual pages into line of:
>
> - write all the first level headings in all caps: "HEADING LIKE THIS"
> - write second level heading: start Upper-lower: "Heading like this"
>
> Cf. rsync(1), ssh(1) etc. many pages prior git's existense.
Having seen that nothing happened after a separate thread that was also on
the documentation consistency:
http://thread.gmane.org/gmane.comp.version-control.git/72163/focus=72213
I am having a hard time to decide how seriously I should take the above
comment from you.
Are you volunteering to coordinate such a change (in other words, you do
not necessarily have to do _all_ the work yourself, alone), or is it just
an idle speculation?
^ permalink raw reply
* Re: [PATCH] Documentation/git-add.txt: Explain --patch option in layman terms
From: Junio C Hamano @ 2009-08-30 23:20 UTC (permalink / raw)
To: Jari Aalto; +Cc: git, Junio C Hamano
In-Reply-To: <87ab1gaol2.fsf@jondo.cante.net>
Jari Aalto <jari.aalto@cante.net> writes:
> Your proposal that starts:
>
> ...but bypass the initial command menu
No, it doesn't..
Go re-read the message you are responding to, paying extra attention to
the parts you snipped from your quote, which was the important part you
should have read before you responded.
If you want to start the description with "What it does/what it is used
for", I think it is a good idea. I already made a suggestion for such an
improvement in my message you are responding to.
Now, what was that suggestion?
It is in the message your first response was a follow-up to. Again you
didn't quote the relevant part in that response, and perhaps that was
because you did not even read it before responding.
If you assume that the reader is not familiar with "add -i", then the
above is not descriptive enough, but "Run interactive patch command" is
not an improvement either. We would need a description of "what it is
used for" before "how it would look to you" (i.e.. my rewrite shown
above).
"What it is used for" would perhaps read like this.
Review the difference between the index and the work tree, and add
modified contents to the index interactively by choosing which
patch hunks to use.
This time I re-quoted things for you because your responses obviously were
written without reading or understanding them, but please be careful not
to make me do this. I do not have infinite time.
^ permalink raw reply
* Re: [PATCH] Documentation/git-add.txt: Explain --patch option in layman terms
From: Jari Aalto @ 2009-08-30 23:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, jari.aalto
In-Reply-To: <7vskf954sr.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Sections that are common in all manual pages (e.g. NAME, SYNOPSIS,
> DESCRIPTION, EXAMPLES, SEE ALSO) are often spelled in and referred to in
> caps.
Not just common ones. All sections that are top level heading are best
spelled out consistently. Examples can be found from the URL to
POSIX/Susv in my other post.
[I'll get back to the CAPS patch in anaother post if we can sort this out]
> See http://www.kernel.org/pub/software/scm/git/docs/git-add.html#_interactive_mode
> for what I mean.
I think the convention used in git's manual pages deviate from the
standard practise. We could make the git manual pages into line of:
- write all the first level headings in all caps: "HEADING LIKE THIS"
- write second level heading: start Upper-lower: "Heading like this"
Cf. rsync(1), ssh(1) etc. many pages prior git's existense.
>>> I personally think fixing misworded phrase "initial command loop" would be
>>> sufficient. It should read "initial command menu". Perhaps like this.
>>>
>>> Run ``add --interactive``, but bypass the initial command menu and
>>> directly jump to `patch` subcommand. See ``Interactive mode'' for
>>> details.
>>
>> It's still too technical. The 1st line should go right into business:
>>
>> Patch each file on command line interactively. This is this is
>> the same as ``add --interactive``, but bypass the initial
>> command menu and directly jump to `patch` subcommand. See
>> ``Interactive mode'' for details.
>
> I do not think it is better than the original.
Your proposal that starts:
...but bypass the initial command menu
Mine:
Patch each file on command line interactively
The first line should somehow strike immediately what the command does.
I would like to see a suggestion that has 'patch(ing)' somewhere at the
very first row. I hope we can find compromise.
Jari
^ permalink raw reply
* Re: Improve on 'approxidate'
From: Jeff King @ 2009-08-30 22:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <alpine.LFD.2.01.0908221438450.3158@localhost.localdomain>
On Sat, Aug 22, 2009 at 03:10:07PM -0700, Linus Torvalds wrote:
> unsigned long approxidate(const char *date)
> {
> int number = 0;
> @@ -881,21 +911,24 @@ unsigned long approxidate(const char *date)
> time_sec = tv.tv_sec;
> localtime_r(&time_sec, &tm);
> now = tm;
> +
> + tm.tm_year = -1;
> + tm.tm_mon = -1;
> + tm.tm_mday = -1;
This breaks relative dates like "3.months.ago", because
approxidate_alpha needs to see the "current" date in tm (and now it sees
-1, subtracts from it, and assumes we are just crossing a year boundary
because of the negative). 3.years.ago is also broken, but I don't think
3.days.ago is.
Probably we just need to pass "now" to approxidate_alpha, and it needs
to call update_tm under the case for "months" and "years" (and I haven't
quite figured out why those are not part of the "tl" list).
Unfortunately, I'm out of time to look at it more right now, but I'll
take a look tonight or tomorrow if you don't beat me to it.
-Peff
^ permalink raw reply
* A note from the maintainer: Follow-up questions (MaintNotes)
From: David Chanters @ 2009-08-30 22:19 UTC (permalink / raw)
To: git; +Cc: David Chanters
Hi,
[Please retain a Cc back to me as I am not currently subscribed to the
mailing list.]
I've recently been intrigued with workflows, and have read quite a bit
about them, including various references on git-scm.com,
gitworkflows(7), and the email "A note from the maintainer" which I
have some questions on. I'll paste random quotes from that and just
ask my question, I think, so apologies up front of it reads a little
disjointed.
I'd often wondered when I have read various posts of the git mailing
list on gmane, just how it is I am supposed to track:
dc/some-topic-feature
... Junio, are these topic branches ones you actively have somewhere
in your own private checkout? Yes, I appreciate that when I read a
given post to the mailing list, you or other people will sometimes
make reference to these topic branches, but what do I do if I am
interested in finding out about one of them? Indeed, perhaps even
before getting to that question, how do you go about creating and
maintaining these topic branches -- are you making heavy use of "git
am"?
I ask because of the following snippet from "MaintNotes":
The two branches "master" and "maint" are never rewound, and
"next" usually will not be either (this automatically means the
topics that have been merged into "next" are usually not
rebased, and you can find the tip of topic branches you are
interested in from the output of "git log next"). You should be
able to safely track them.
I am not sure if there's any real use-case for this, but I will ask
anyway: is the above saying that I am able to *checkout* one of these
topic-branches just from their presence in "next" alone? I appreciate
that the point is somewhat moot since the topic branch has already
been merged into "next", but I can surely see this as a really useful
way for people to manage topic-branches in a shared environment:
people can simply pick a topic branch out from the integrated one --
in this case "next". Or is this idea a complete waste of time?
To continue:
The "pu" (proposed updates) branch bundles all the remainder of
topic branches. The "pu" branch, and topic branches that are
only in "pu", are subject to rebasing in general. By the above
definition of how "next" works, you can tell that this branch
will contain quite experimental and obviously broken stuff.
I'm obviously missing something here -- but why is rebasing these
existing topic branches (I assume on top of "pu") more useful than
just merging them into "pu" -- like you do with "next"?
When a topic that was in "pu" proves to be in testable shape, it
graduates to "next". I do this with:
git checkout next
git merge that-topic-branch
Sometimes, an idea that looked promising turns out to be not so
good and the topic can be dropped from "pu" in such a case.
Ah -- so if I have this straight in my head -- you continually form
the local topic-branch on its own branch, and then just merge it into
"next" only when you know that topic branch is satisfactory? That
being the case -- again, I assume the use of "git am" for the topic
branch? If regular readers of the git mailing list wish to track this
topic branch, can they do so from you only until it's merged into
"next"?
And a related question: If you decide a given topic in pu is declared
to "be dropped", is this done by rebasing (as you mentioned earlier)
so as to remove any trace of the topic branch ever having been in
"pu", or am I reading too much into "dropping" here? :)
I hope these aren't too idiotic.
Thanks all in advance.
David
^ permalink raw reply
* Re: [PATCH] Documentation/git-add.txt: Explain --patch option in layman terms
From: Junio C Hamano @ 2009-08-30 22:13 UTC (permalink / raw)
To: Jari Aalto; +Cc: git
In-Reply-To: <87tyzp9da4.fsf@jondo.cante.net>
Jari Aalto <jari.aalto@cante.net> writes:
> It is not shouting, but standard practise to refer to manual page
> section in ALL CAPS, when they are top level headings, like in this
> case.
Why are you making excuses, ignoring the fact that you didn't have a
matching update to make the section also in caps in the patch?
Sections that are common in all manual pages (e.g. NAME, SYNOPSIS,
DESCRIPTION, EXAMPLES, SEE ALSO) are often spelled in and referred to in
caps. You do not have to explain that to me ;-)
If you wanted to add "Interactive mode" to that set of "common sections"
and spell it in caps, do so consistently.
See http://www.kernel.org/pub/software/scm/git/docs/git-add.html#_interactive_mode
for what I mean.
>> I personally think fixing misworded phrase "initial command loop" would be
>> sufficient. It should read "initial command menu". Perhaps like this.
>>
>> Run ``add --interactive``, but bypass the initial command menu and
>> directly jump to `patch` subcommand. See ``Interactive mode'' for
>> details.
>
> It's still too technical. The 1st line should go right into business:
>
> Patch each file on command line interactively. This is this is
> the same as ``add --interactive``, but bypass the initial
> command menu and directly jump to `patch` subcommand. See
> ``Interactive mode'' for details.
Even if we ignore the double "this is this is", I do not think it is
better than the original.
What does "Patch each file" mean? When read naively (and that is the
whole point of your "too technical" comment), a reader would expect there
will be changes made _to_ the work tree files.
If you want to start the description with "What it does/what it is used
for", I think it is a good idea. I already made a suggestion for such an
improvement in my message you are responding to.
If you want to make a counterproposal, at least please do that with a
counter-proposal that is better.
^ permalink raw reply
* Re: [PATCH] Documentation/git-add.txt: Explain --patch option in layman terms
From: Jari Aalto @ 2009-08-30 22:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vab1hdppb.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
>> + operation to a subset of the working tree. See section
>> + ``INTERACTIVE MODE'' for details.
>
> It is not justified with your commit log message, I do not see why you
> have to shout in all CAPS,
There are plenty of examples, that it's standard practise to refer top
level headings, in all caps, from:
POSIX/SusV guides for manual pages: "1.11 Utility Description Defaults"
http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap01.html#tag_01_11
Jari
^ permalink raw reply
* Re: [PATCH] Documentation/git-add.txt: Explain --patch option in layman terms
From: Jari Aalto @ 2009-08-30 21:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, jari.aalto
In-Reply-To: <7vab1hdppb.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Jari Aalto <jari.aalto@cante.net> writes:
>
>> Signed-off-by: Jari Aalto <jari.aalto@cante.net>
>> ---
>> Documentation/git-add.txt | 10 +++++-----
>> 1 files changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
>> index e67b7e8..71990c2 100644
>> --- a/Documentation/git-add.txt
>> +++ b/Documentation/git-add.txt
>> @@ -67,14 +67,14 @@ OPTIONS
>> --interactive::
>> Add modified contents in the working tree interactively to
>> the index. Optional path arguments may be supplied to limit
>> - operation to a subset of the working tree. See ``Interactive
>> - mode'' for details.
>> + operation to a subset of the working tree. See section
>> + ``INTERACTIVE MODE'' for details.
>
> It is not justified with your commit log message, I do not see why you
> have to shout in all CAPS, and there is no such section in the
> documentation. But the "Interactive mode" section exists and is referred
> to by the original.
It is not shouting, but standard practise to refer to manual page
section in ALL CAPS, when they are top level headings, like in this
case.
>> -p::
>> --patch::
>> - Similar to Interactive mode but the initial command loop is
>> - bypassed and the 'patch' subcommand is invoked using each of
>> - the specified filepatterns before exiting.
>> + Run interactive patch command for each file on command line.
>> + See section INTERACTIVE MODE and patch subcommand for more
>> + information.
>
> I personally think fixing misworded phrase "initial command loop" would be
> sufficient. It should read "initial command menu". Perhaps like this.
>
> Run ``add --interactive``, but bypass the initial command menu and
> directly jump to `patch` subcommand. See ``Interactive mode'' for
> details.
It's still too technical. The 1st line should go right into business:
Patch each file on command line interactively. This is this is
the same as ``add --interactive``, but bypass the initial
command menu and directly jump to `patch` subcommand. See
``Interactive mode'' for details.
Jari
^ permalink raw reply
* Re: [PATCH 1/3] Add date formatting and parsing functions relative to a given time
From: Jeff King @ 2009-08-30 21:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, git
In-Reply-To: <20090830214309.GA16119@coredump.intra.peff.net>
On Sun, Aug 30, 2009 at 05:43:09PM -0400, Jeff King wrote:
> From: Alex Riesen <raa.lkml@gmail.com>
>
> The main purpose is to allow predictable testing of the code.
>
> Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
Bleh. I just started working on a 4/3 that would test Linus' recent
approxidate changes, but then I realized that this massive date.c
refactoring conflicts with his changes.
I think the most sane thing is to rebase the whole series on top of
lt/approxidate. Let me see what I can do.
-Peff
^ permalink raw reply
* [PATCH 3/3] tests: add date printing and parsing tests
From: Jeff King @ 2009-08-30 21:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, git
In-Reply-To: <20090830093642.GA30922@coredump.intra.peff.net>
Until now, there was no coverage of relative date printing
or approxidate parsing routines (mainly because we had no
way of faking the "now" time for relative date calculations,
which made consistent testing impossible).
This new script tries to exercise the basic features of
show_date and approxidate. The only specific problem case
tested is showing relative year/month dates in the latter
half of a year, as fixed by 607a9e8.
Signed-off-by: Jeff King <peff@peff.net>
---
Like I said, this is really just to exercise the basic code paths.
But now that the infrastructure is there, we can add any corner cases
or verify new features or bug fixes as they come up. Patches welcome. :)
t/t0006-date.sh | 71 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 71 insertions(+), 0 deletions(-)
create mode 100755 t/t0006-date.sh
diff --git a/t/t0006-date.sh b/t/t0006-date.sh
new file mode 100755
index 0000000..4beb44b
--- /dev/null
+++ b/t/t0006-date.sh
@@ -0,0 +1,71 @@
+#!/bin/sh
+
+test_description='test date parsing and printing'
+. ./test-lib.sh
+
+# arbitrary reference time: 2009-08-30 19:20:00
+TEST_DATE_NOW=1251660000; export TEST_DATE_NOW
+
+check_show() {
+ t=$(($TEST_DATE_NOW - $1))
+ echo "$t -> $2" >expect
+ test_expect_success "relative date ($2)" "
+ test-date show $t >actual &&
+ test_cmp expect actual
+ "
+}
+
+check_show 5 '5 seconds ago'
+check_show 300 '5 minutes ago'
+check_show 18000 '5 hours ago'
+check_show 432000 '5 days ago'
+check_show 1728000 '3 weeks ago'
+check_show 13000000 '5 months ago'
+check_show 37500000 '1 year, 2 months ago'
+check_show 55188000 '1 year, 9 months ago'
+check_show 630000000 '20 years ago'
+
+check_parse() {
+ echo "$1 -> $2" >expect
+ test_expect_success "parse date ($1)" "
+ test-date parse '$1' >actual &&
+ test_cmp expect actual
+ "
+}
+
+check_parse 2008 bad
+check_parse 2008-02 bad
+check_parse 2008-02-14 '2008-02-14 00:00:00 +0000'
+check_parse '2008-02-14 20:30:45' '2008-02-14 20:30:45 +0000'
+
+check_approxidate() {
+ echo "$1 -> $2 +0000" >expect
+ test_expect_success "parse approxidate ($1)" "
+ test-date approxidate '$1' >actual &&
+ test_cmp expect actual
+ "
+}
+
+check_approxidate now '2009-08-30 19:20:00'
+check_approxidate '5 seconds ago' '2009-08-30 19:19:55'
+check_approxidate 5.seconds.ago '2009-08-30 19:19:55'
+check_approxidate 10.minutes.ago '2009-08-30 19:10:00'
+check_approxidate yesterday '2009-08-29 19:20:00'
+check_approxidate 3.days.ago '2009-08-27 19:20:00'
+check_approxidate 3.weeks.ago '2009-08-09 19:20:00'
+check_approxidate 3.months.ago '2009-05-30 19:20:00'
+check_approxidate 2.years.3.months.ago '2007-05-30 19:20:00'
+
+check_approxidate '6am yesterday' '2009-08-29 06:00:00'
+check_approxidate '6pm yesterday' '2009-08-29 18:00:00'
+check_approxidate '3:00' '2009-08-30 03:00:00'
+check_approxidate '15:00' '2009-08-30 15:00:00'
+check_approxidate 'noon today' '2009-08-30 12:00:00'
+check_approxidate 'noon yesterday' '2009-08-29 12:00:00'
+
+check_approxidate 'last tuesday' '2009-08-25 19:20:00'
+check_approxidate 'July 5th' '2009-07-05 19:20:00'
+check_approxidate '06/05/2009' '2009-06-05 00:00:00'
+check_approxidate '06.05.2009' '2009-05-06 00:00:00'
+
+test_done
--
1.6.4.2.375.g73938
^ permalink raw reply related
* [PATCH 2/3] refactor test-date interface
From: Jeff King @ 2009-08-30 21:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, git
In-Reply-To: <20090830093642.GA30922@coredump.intra.peff.net>
The test-date program goes back to the early days of git,
where it was presumably used to do manual sanity checks on
changes to the date code. However, it is not actually used
by the test suite to do any sort of automatic of systematic
tests.
This patch refactors the interface to the program to try to
make it more suitable for use by the test suite. There
should be no fallouts to changing the interface since it is
not actually installed and is not internally called by any
other programs.
The changes are:
- add a "mode" parameter so the caller can specify which
operation to test
- add a mode to test relative date output from show_date
- allow faking a fixed time via the TEST_DATE_NOW
environment variable, which allows consistent automated
testing
- drop the use of ctime for showing dates in favor of our
internal iso8601 printing routines. The ctime output is
somewhat redundant (because of the day-of-week) which
makes writing test cases more annoying.
Signed-off-by: Jeff King <peff@peff.net>
---
I mulled over replacing ctime for a bit, as we are testing git's date
code with other parts of git's date code. But it really is more
convenient for writing test cases to use iso8601, since you don't have
to calculate the day-of-week (and I also think it is a bit more
readable). And our iso8601 code is dead simple, so I am not too worried
about a bug in it hiding a bug elsewhere.
test-date.c | 86 +++++++++++++++++++++++++++++++++++++++++++++-------------
1 files changed, 66 insertions(+), 20 deletions(-)
rewrite test-date.c (63%)
diff --git a/test-date.c b/test-date.c
dissimilarity index 63%
index 62e8f23..5b0a220 100644
--- a/test-date.c
+++ b/test-date.c
@@ -1,20 +1,66 @@
-#include "cache.h"
-
-int main(int argc, char **argv)
-{
- int i;
-
- for (i = 1; i < argc; i++) {
- char result[100];
- time_t t;
-
- memcpy(result, "bad", 4);
- parse_date(argv[i], result, sizeof(result));
- t = strtoul(result, NULL, 0);
- printf("%s -> %s -> %s", argv[i], result, ctime(&t));
-
- t = approxidate(argv[i]);
- printf("%s -> %s\n", argv[i], ctime(&t));
- }
- return 0;
-}
+#include "cache.h"
+
+static const char *usage_msg = "\n"
+" test-date show [time_t]...\n"
+" test-date parse [date]...\n"
+" test-date approxidate [date]...\n";
+
+static void show_dates(char **argv, struct timeval *now)
+{
+ char buf[128];
+
+ for (; *argv; argv++) {
+ time_t t = atoi(*argv);
+ show_date_relative(t, 0, now, buf, sizeof(buf));
+ printf("%s -> %s\n", *argv, buf);
+ }
+}
+
+static void parse_dates(char **argv, struct timeval *now)
+{
+ for (; *argv; argv++) {
+ char result[100];
+ time_t t;
+
+ parse_date(*argv, result, sizeof(result));
+ t = strtoul(result, NULL, 0);
+ printf("%s -> %s\n", *argv,
+ t ? show_date(t, 0, DATE_ISO8601) : "bad");
+ }
+}
+
+static void parse_approxidate(char **argv, struct timeval *now)
+{
+ for (; *argv; argv++) {
+ time_t t;
+ t = approxidate_relative(*argv, now);
+ printf("%s -> %s\n", *argv, show_date(t, 0, DATE_ISO8601));
+ }
+}
+
+int main(int argc, char **argv)
+{
+ struct timeval now;
+ const char *x;
+
+ x = getenv("TEST_DATE_NOW");
+ if (x) {
+ now.tv_sec = atoi(x);
+ now.tv_usec = 0;
+ }
+ else
+ gettimeofday(&now, NULL);
+
+ argv++;
+ if (!*argv)
+ usage(usage_msg);
+ if (!strcmp(*argv, "show"))
+ show_dates(argv+1, &now);
+ else if (!strcmp(*argv, "parse"))
+ parse_dates(argv+1, &now);
+ else if (!strcmp(*argv, "approxidate"))
+ parse_approxidate(argv+1, &now);
+ else
+ usage(usage_msg);
+ return 0;
+}
--
1.6.4.2.375.g73938
^ permalink raw reply related
* [PATCH 1/3] Add date formatting and parsing functions relative to a given time
From: Jeff King @ 2009-08-30 21:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, git
In-Reply-To: <20090830093642.GA30922@coredump.intra.peff.net>
From: Alex Riesen <raa.lkml@gmail.com>
The main purpose is to allow predictable testing of the code.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
---
cache.h | 5 ++
date.c | 152 +++++++++++++++++++++++++++++++++++++--------------------------
2 files changed, 94 insertions(+), 63 deletions(-)
diff --git a/cache.h b/cache.h
index 808daba..5fad24c 100644
--- a/cache.h
+++ b/cache.h
@@ -731,9 +731,14 @@ enum date_mode {
};
const char *show_date(unsigned long time, int timezone, enum date_mode mode);
+const char *show_date_relative(unsigned long time, int tz,
+ const struct timeval *now,
+ char *timebuf,
+ size_t timebuf_size);
int parse_date(const char *date, char *buf, int bufsize);
void datestamp(char *buf, int bufsize);
unsigned long approxidate(const char *);
+unsigned long approxidate_relative(const char *date, const struct timeval *now);
enum date_mode parse_date_format(const char *format);
#define IDENT_WARN_ON_NO_NAME 1
diff --git a/date.c b/date.c
index f011692..0b0f7a7 100644
--- a/date.c
+++ b/date.c
@@ -84,6 +84,68 @@ static int local_tzoffset(unsigned long time)
return offset * eastwest;
}
+const char *show_date_relative(unsigned long time, int tz,
+ const struct timeval *now,
+ char *timebuf,
+ size_t timebuf_size)
+{
+ unsigned long diff;
+ if (now->tv_sec < time)
+ return "in the future";
+ diff = now->tv_sec - time;
+ if (diff < 90) {
+ snprintf(timebuf, timebuf_size, "%lu seconds ago", diff);
+ return timebuf;
+ }
+ /* Turn it into minutes */
+ diff = (diff + 30) / 60;
+ if (diff < 90) {
+ snprintf(timebuf, timebuf_size, "%lu minutes ago", diff);
+ return timebuf;
+ }
+ /* Turn it into hours */
+ diff = (diff + 30) / 60;
+ if (diff < 36) {
+ snprintf(timebuf, timebuf_size, "%lu hours ago", diff);
+ return timebuf;
+ }
+ /* We deal with number of days from here on */
+ diff = (diff + 12) / 24;
+ if (diff < 14) {
+ snprintf(timebuf, timebuf_size, "%lu days ago", diff);
+ return timebuf;
+ }
+ /* Say weeks for the past 10 weeks or so */
+ if (diff < 70) {
+ snprintf(timebuf, timebuf_size, "%lu weeks ago", (diff + 3) / 7);
+ return timebuf;
+ }
+ /* Say months for the past 12 months or so */
+ if (diff < 360) {
+ snprintf(timebuf, timebuf_size, "%lu months ago", (diff + 15) / 30);
+ return timebuf;
+ }
+ /* Give years and months for 5 years or so */
+ if (diff < 1825) {
+ unsigned long years = diff / 365;
+ unsigned long months = (diff % 365 + 15) / 30;
+ int n;
+ n = snprintf(timebuf, timebuf_size, "%lu year%s",
+ years, (years > 1 ? "s" : ""));
+ if (months)
+ snprintf(timebuf + n, timebuf_size - n,
+ ", %lu month%s ago",
+ months, (months > 1 ? "s" : ""));
+ else
+ snprintf(timebuf + n, timebuf_size - n,
+ " ago");
+ return timebuf;
+ }
+ /* Otherwise, just years. Centuries is probably overkill. */
+ snprintf(timebuf, timebuf_size, "%lu years ago", (diff + 183) / 365);
+ return timebuf;
+}
+
const char *show_date(unsigned long time, int tz, enum date_mode mode)
{
struct tm *tm;
@@ -95,63 +157,10 @@ const char *show_date(unsigned long time, int tz, enum date_mode mode)
}
if (mode == DATE_RELATIVE) {
- unsigned long diff;
struct timeval now;
gettimeofday(&now, NULL);
- if (now.tv_sec < time)
- return "in the future";
- diff = now.tv_sec - time;
- if (diff < 90) {
- snprintf(timebuf, sizeof(timebuf), "%lu seconds ago", diff);
- return timebuf;
- }
- /* Turn it into minutes */
- diff = (diff + 30) / 60;
- if (diff < 90) {
- snprintf(timebuf, sizeof(timebuf), "%lu minutes ago", diff);
- return timebuf;
- }
- /* Turn it into hours */
- diff = (diff + 30) / 60;
- if (diff < 36) {
- snprintf(timebuf, sizeof(timebuf), "%lu hours ago", diff);
- return timebuf;
- }
- /* We deal with number of days from here on */
- diff = (diff + 12) / 24;
- if (diff < 14) {
- snprintf(timebuf, sizeof(timebuf), "%lu days ago", diff);
- return timebuf;
- }
- /* Say weeks for the past 10 weeks or so */
- if (diff < 70) {
- snprintf(timebuf, sizeof(timebuf), "%lu weeks ago", (diff + 3) / 7);
- return timebuf;
- }
- /* Say months for the past 12 months or so */
- if (diff < 360) {
- snprintf(timebuf, sizeof(timebuf), "%lu months ago", (diff + 15) / 30);
- return timebuf;
- }
- /* Give years and months for 5 years or so */
- if (diff < 1825) {
- unsigned long years = diff / 365;
- unsigned long months = (diff % 365 + 15) / 30;
- int n;
- n = snprintf(timebuf, sizeof(timebuf), "%lu year%s",
- years, (years > 1 ? "s" : ""));
- if (months)
- snprintf(timebuf + n, sizeof(timebuf) - n,
- ", %lu month%s ago",
- months, (months > 1 ? "s" : ""));
- else
- snprintf(timebuf + n, sizeof(timebuf) - n,
- " ago");
- return timebuf;
- }
- /* Otherwise, just years. Centuries is probably overkill. */
- snprintf(timebuf, sizeof(timebuf), "%lu years ago", (diff + 183) / 365);
- return timebuf;
+ return show_date_relative(time, tz, &now,
+ timebuf, sizeof(timebuf));
}
if (mode == DATE_LOCAL)
@@ -866,19 +875,13 @@ static const char *approxidate_digit(const char *date, struct tm *tm, int *num)
return end;
}
-unsigned long approxidate(const char *date)
+static unsigned long approxidate_str(const char *date, const struct timeval *tv)
{
int number = 0;
struct tm tm, now;
- struct timeval tv;
time_t time_sec;
- char buffer[50];
- if (parse_date(date, buffer, sizeof(buffer)) > 0)
- return strtoul(buffer, NULL, 10);
-
- gettimeofday(&tv, NULL);
- time_sec = tv.tv_sec;
+ time_sec = tv->tv_sec;
localtime_r(&time_sec, &tm);
now = tm;
for (;;) {
@@ -899,3 +902,26 @@ unsigned long approxidate(const char *date)
tm.tm_year--;
return mktime(&tm);
}
+
+unsigned long approxidate_relative(const char *date, const struct timeval *tv)
+{
+ char buffer[50];
+
+ if (parse_date(date, buffer, sizeof(buffer)) > 0)
+ return strtoul(buffer, NULL, 10);
+
+ return approxidate_str(date, tv);
+}
+
+unsigned long approxidate(const char *date)
+{
+ struct timeval tv;
+ char buffer[50];
+
+ if (parse_date(date, buffer, sizeof(buffer)) > 0)
+ return strtoul(buffer, NULL, 10);
+
+ gettimeofday(&tv, NULL);
+ return approxidate_str(date, &tv);
+}
+
--
1.6.4.2.375.g73938
^ permalink raw reply related
* Re: What IDEs are you using to develop git?
From: Robin Rosenberg @ 2009-08-30 21:29 UTC (permalink / raw)
To: Daniele Segato; +Cc: John Tapsell, Frank Münnich, git
In-Reply-To: <1251655664.31273.4.camel@localhost>
söndag 30 augusti 2009 20:07:44 skrev Daniele Segato <daniele.bilug@gmail.com>:
> Il giorno mar, 25/08/2009 alle 13.47 +0100, John Tapsell ha scritto:
> > 2009/8/25 Frank Münnich <git@frank-muennich.com>:
> > > One thing I would like to ask you: what, if any, IDEs are you working with?
> >
> > I think everyone just uses vim/emacs :-)
>
> I can't get how would one take vim or emacs instead of an IDE like
> Eclipse.
> That's probably because I'm mainingly a Java developer and i don't know
> vim/emacs very much.
>
> What are the advantages of developing git with vim/emacs over an IDE?
Vim and Emacs has, and have had tools suitable for C and other languages
for ages. If you have learned to master them it's hard to find anything as
good. If you do java the tools in vim and emacs are not as developed as
those for older languages, which Eclipse is originally developed as a tool
for Java development and it shines at it. For non-java things vary. The C/C++
support in Eclipse is getting better, but it' nowhere near what exists
for Java. Learning and avoiding its's bugs and quirks is probably not
worth it if you already have other good or better tools.
VIM and Emacs are really IDE's. In particular you can login to emacs directly
and never leave it until you log out. Besdides all you pogramming tools you
have your email and (yes) your mp3 player there. That's pretty integrated to me.
-- robin
^ permalink raw reply
* Re: [PATCH] Documentation/git-add.txt: Explain --patch option in layman terms
From: Jeff King @ 2009-08-30 21:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jari Aalto, git
In-Reply-To: <7vab1hdppb.fsf@alter.siamese.dyndns.org>
On Sun, Aug 30, 2009 at 01:14:24PM -0700, Junio C Hamano wrote:
> > - operation to a subset of the working tree. See ``Interactive
> > - mode'' for details.
> > + operation to a subset of the working tree. See section
> > + ``INTERACTIVE MODE'' for details.
>
> Sorry, the change in this hunk does not make *any* sense to me.
>
> It is not justified with your commit log message, I do not see why you
> have to shout in all CAPS, and there is no such section in the
> documentation. But the "Interactive mode" section exists and is referred
> to by the original.
I think it is an attempt to match the way docbook renders manpage
headings; it converts headings to all-caps. And there is some precedent;
try grepping for ".EXAMPLES" in Documentation/*.txt.
That being said, the straight asciidoc->html version leaves the
capitalization untouched. However, that actually makes the html version
look quite awkward. Some of the headings are in all-caps and some are
not. So I wonder if we should make them typographically consistent.
(And yes, I totally agree that this hunk was a surprise after reading
the commit message and if anything is done, it should be in a separate
patch).
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (Aug 2009, #05; Wed, 26)
From: Junio C Hamano @ 2009-08-30 20:31 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git
In-Reply-To: <7vskfat07h.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
>>> There was a discussion that suggests that the use of colon ':' before vcs
>>> helper name needs to be corrected. Nothing happened since.
>>
>> I believe the outcome of that discussion was:
>>
>> - We want to keep supporting using regular location URLs that are URLs of
>> git repositories (e.g., http://git.savannah.gnu.org/cgit/xboard.git),
>> and we probably want to do it with a helper which runs when
>> run_command() is given "remote-<scheme>". I think installing hardlinks
>> in EXECPATH ended up being the best implementation here.
>
> That is different from what I recall.
> ...
> And from my point of view, this is what is blocking the series...
Just to make my position clear.
I brought up the issue of "should we leave it as a single colon that
confuses scp-like syntax and forces us to have three extra hardlinks?" in
the message I am following up to, not because I firmly am on that side of
the argument, but because I thought your version of "outcome" did not
match my recollection around that particular issue. I am more or less
neutral myself. Avoiding the confusion seems obviously the simple and
right thing to do, and I cannot think of obvious downsides of such a
change, but there probably are some downsides you have in mind, and I can
well imagine the issue may become "perfect is the enemy of good".
And I said "blocking the series", not in the sense that _I_ demand to
change it from colon to something else, but in the sense that I recall the
issue hasn't been settled in the discussion.
^ permalink raw reply
* Re: git svn pointing at svn branch instead of trunk?
From: Daniele Segato @ 2009-08-30 20:30 UTC (permalink / raw)
To: skillzero; +Cc: git
In-Reply-To: <2729632a0908221140p532a3c29k90af7b4cbd25d65e@mail.gmail.com>
Il giorno sab, 22/08/2009 alle 11.40 -0700, skillzero@gmail.com ha
scritto:
> When I used git svn to clone a repository, it ended up pointing master
> at a tag in svn instead of trunk. For example, git svn info shows the
> URL for the tag instead of trunk. git log master also shows the most
> recent commit is the creation of that tag in svn, but then the next
> commit is the most recent commit to trunk. It's like it's mixing
> things from the tag with things from trunk. The most recent commit in
> svn was to create the tag that master is now pointing to in case that
> matters.
I had the same problem a while ago.
When git-svn is done cloning you find yourself in the "master" branch
(check by executing git branch) and it's content is the last svn-commit.
If the last svn commit is a tag or in a branch you'll end up in that
tag/branch
> Is there something in the svn repository that might cause this? What's
> the correct way to reset what git svn thinks master should point to?
> And how should I get rid of the commit on master that created the tag
> without messing up git svn (e.g. can I just git reset or will that
> confuse git svn later?).
execute:
git branch -r
it will list all the remote branches:
usually one will be "trunk"
if you now execute:
git reset --hard remotes/trunk
it will reset your current local branch (master) to the remote trunk and
will start to truck that remote branch (trunk)
I'm a git newbie, so if i said something wrong I hope someone will
correct me.
Cheers,
Daniele
^ permalink raw reply
* Re: git-diff: must --exit-code work with --ignore* options?
From: Jim Meyering @ 2009-08-30 20:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git list
In-Reply-To: <7vljl1dpud.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Jim Meyering <jim@meyering.net> writes:
>> Junio C Hamano wrote:
>> ...
>>> Subject: [PATCH] diff --quiet: special case "ignore whitespace" options
>>> ...
>>> Change the semantics of --ignore-whitespace* options to mean more than
>>> "omit showing the difference in text". When these options are used, the
>>> internal "quick" optimization is turned off, and the status reported with
>>> the --exit-code option will now match if any the textual diff output is
>>> actually produced.
>>>
>>> Also rename the internal option "QUIET" to "QUICK" to better reflect what
>>> its true purpose is.
>>
>> Thanks again.
>> If there's anything I can to do help (add a test?), let me know.
>
> The change has been cooking in 'next' and hopefully be in 1.7.0. I think
> the updated series adds its own test script, too.
>
> Using it in every day scenario, and reporting any breakage you notice
> before 1.7.0 happens, would be greatly appreciated.
Oh! I am using next (will test!), and even searched log summary output,
but obviously my search was too cursory or just inaccurate.
I glanced through it and it looks fine (of course!).
I spotted one typo, and suggest a second change that's barely worth
mentioning, both in comments:
diff --git a/diff.c b/diff.c
index 91d6ea2..24bd3fc 100644
--- a/diff.c
+++ b/diff.c
@@ -2382,7 +2382,7 @@ int diff_setup_done(struct diff_options *options)
* Most of the time we can say "there are changes"
* only by checking if there are changed paths, but
* --ignore-whitespace* options force us to look
- * inside contets.
+ * inside contents.
*/
if (DIFF_XDL_TST(options, IGNORE_WHITESPACE) ||
@@ -3346,7 +3346,7 @@ free_queue:
fclose(options->file);
/*
- * Report the contents level differences with HAS_CHANGES;
+ * Report the content-level differences with HAS_CHANGES;
* diff_addremove/diff_change does not set the bit when
* DIFF_FROM_CONTENTS is in effect (e.g. with -w).
*/
^ permalink raw reply related
* Re: [msysGit] Re: Using VC build git (split patch)
From: Thiago Farina @ 2009-08-30 20:24 UTC (permalink / raw)
To: Erik Faye-Lund
Cc: Frank Li, Marius Storm-Olsen, git, msysGit, Johannes Schindelin
In-Reply-To: <40aa078e0908301316m68258630oe84c0e9b6191332b@mail.gmail.com>
Hi,
On Sun, Aug 30, 2009 at 5:16 PM, Erik Faye-Lund<kusmabite@googlemail.com> wrote:
> On Sun, Aug 30, 2009 at 9:36 PM, Thiago Farina<tfransosi@gmail.com> wrote:
>> Error 2635 error LNK2019: unresolved external symbol _socketpair
>> referenced in function _imap_open_store imap-send.obj imap-send
>>
>> Anyone faced this problem before?
>
> Yes. imap-send isn't supported on windows, since it uses
> posix-functions that aren't available in msvcrt. The Makefile system
> excludes it for MinGW-builds. Is it added to the vcproj-files?
>
Yep, an imap-send vcproject with one file(imap-send.c) was added to
gitbuild.sln.
^ permalink raw reply
* Re: [msysGit] Re: Using VC build git (split patch)
From: Erik Faye-Lund @ 2009-08-30 20:16 UTC (permalink / raw)
To: Thiago Farina
Cc: Frank Li, Marius Storm-Olsen, git, msysGit, Johannes Schindelin
In-Reply-To: <a4c8a6d00908301236l4394a471vb83ed2befda3a91@mail.gmail.com>
On Sun, Aug 30, 2009 at 9:36 PM, Thiago Farina<tfransosi@gmail.com> wrote:
> Error 2635 error LNK2019: unresolved external symbol _socketpair
> referenced in function _imap_open_store imap-send.obj imap-send
>
> Anyone faced this problem before?
Yes. imap-send isn't supported on windows, since it uses
posix-functions that aren't available in msvcrt. The Makefile system
excludes it for MinGW-builds. Is it added to the vcproj-files?
Any patches that adds a working socketpair()-function (or even better,
IMO: rewrite the code so socketpair isn't needed) would of course be
very welcome. I'd love to have a working imap-send on windows :)
--
Erik "kusma" Faye-Lund
kusmabite@gmail.com
(+47) 986 59 656
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox