* 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
* Re: [PATCH] Remove unused t/t8005/iso8859-5.txt file
From: Junio C Hamano @ 2009-08-30 20:14 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git
In-Reply-To: <20090829170809.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting Junio C Hamano <gitster@pobox.com>
>
>> Out of curiosity, how did you find this?
>
> Soon after you posted your original in
> http://thread.gmane.org/gmane.comp.version-control.git/121881, I applied
> it to my tree, and I have been running 'git pull --rebase' for ever. I
> noticed that rebase didn't remove the commit, even after your 54bc13c.
>
> Today I found that the rebased patch only removed that file. The real
> question is how you lost the deletion of the file when you applied. What
> happened?
My stupidity, and a little bit of danger in trusting "am -3" blindly.
The patch sent to the list was against the master, but the actual commit
created, 54bc13c, was on maint. Back then, there was a commit in master
but not in maint that stopped using cp1251.txt and started using
iso8859-5.txt instead.
Because maint did not have iso8859-5.txt (which the patch wanted to
remove), when "am -3" did its fake 3-way merge, the removal of the path
did not even conflict. It was the case of "neither side wants to have
this file". As the result, cp1251.txt was left in the tree (which is
half-Ok, even though the updated test never looked at it anymore), and
merging the result back to master did not touch iso8859-5.txt.
^ permalink raw reply
* Re: [PATCH] Documentation/git-add.txt: Explain --patch option in layman terms
From: Junio C Hamano @ 2009-08-30 20:14 UTC (permalink / raw)
To: Jari Aalto; +Cc: git
In-Reply-To: <87ocpxb46g.fsf@jondo.cante.net>
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.
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.
> -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.
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.
^ permalink raw reply
* Re: git-diff: must --exit-code work with --ignore* options?
From: Junio C Hamano @ 2009-08-30 20:11 UTC (permalink / raw)
To: Jim Meyering; +Cc: git list
In-Reply-To: <87skf9uv3r.fsf@meyering.net>
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.
Thanks.
^ permalink raw reply
* Re: [BUG] git stash refuses to save after "add -N"
From: Junio C Hamano @ 2009-08-30 20:01 UTC (permalink / raw)
To: Jeff King; +Cc: Yann Dirson, git
In-Reply-To: <20090830095509.GB30922@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Sat, Aug 29, 2009 at 03:34:45PM -0700, Junio C Hamano wrote:
>
>> I am slightly in favor of leaving the things as they are, as the error
>> message is quite clear.
>
> Hmm. Thinking about it a bit more, I think "add as empty content" is
> probably the best. It scares me a little because it is losing
> information during the stash, but consider it from the user's
> perspective.
> ...
> And all of this while they are trying to quickly switch contexts to
> whatever it was that caused them to stash in the first place.
Ok, then probably the "how about" patch would be a part of the right
solution.
One thing I noticed was that while unstashing without --index, we add full
contents to the index of new files. I think it is because back then when
stash was written there was no other way, but now we have intent-to-add
and a way to stash such an entry, I think we should add only the intent to
add them in that codepath.
Of course we will not do this when unstashing with --index.
^ permalink raw reply
* Re: Merging in Subversion 1.5 (was: Re: Using git to track my PhD thesis, couple of questions)
From: Sam Vilain @ 2009-08-30 19:41 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Matthias Andree, git, Matthieu Moy
In-Reply-To: <m3ocq0km5m.fsf_-_@localhost.localdomain>
On Fri, 2009-08-28 at 08:12 -0700, Jakub Narebski wrote:
> * svn:mergeinfo contains _per-file_ merge info, so it is much, much
> more "chatty" than Git multiple parents.
It can. But more often, if you're merging complete paths, you will get
complete revision ranges.
See eg
https://trac.parrot.org/parrot/browser/trunk
Note how trac is also hiding the branches that were subsequently deleted
from the mergeinfo ticket.
> * The command to merge trunk into branch is different from command to
> merge branch into trunk.
This is a caveat of url-based branches.
> Also IIRC there is warning (well, at least there was in Subversion 1.5
> release notes) that merge tracking doesn't work entirely correctly in
> the face of criss-cross merges (multiple merge bases) and renaming
> (although I do hope that they fixed problem with silent corruption if
> there is rename during merge).
Not sure about that one. I also heard - unconfirmed - that things start
to go awry if you start branching off branches and merging around the
place. But if that happens it's likely a bug rather than a design flaw
(I think).
Sam
^ permalink raw reply
* Re: [msysGit] Re: Using VC build git (split patch)
From: Thiago Farina @ 2009-08-30 19:36 UTC (permalink / raw)
To: Frank Li; +Cc: Marius Storm-Olsen, git, msysGit, Johannes Schindelin
In-Reply-To: <1976ea660908171807x22f4b755r2e522a15ff462917@mail.gmail.com>
Hi
In line 999 of imap-send.c there is a call to the function socketpair,
but apparently it isn't defined anywhere, because the compiler is
returning this following error:
Error 2635 error LNK2019: unresolved external symbol _socketpair
referenced in function _imap_open_store imap-send.obj imap-send
Anyone faced this problem before?
Thanks!
^ permalink raw reply
* Re: What IDEs are you using to develop git?
From: Howard Miller @ 2009-08-30 19:06 UTC (permalink / raw)
To: Daniele Segato; +Cc: John Tapsell, Frank Münnich, git
In-Reply-To: <1251655664.31273.4.camel@localhost>
I can only reply very generally (I don't develop git - I develop php
and use git). However, I have tried to use Eclipse on a number of
occasions and have always drifted back to Vim. With a bit of learning
can can do most of the stuff that an IDE does, usually faster and with
less fuss. However, the killer for me is that you can access your
development box in an emergency over a slow dialup line and vim will
get you out of trouble - your fancy, resource-hogging IDE will not.
2009/8/30 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?
>
> Cheers,
> Daniele
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: What IDEs are you using to develop git?
From: Nicolas Pitre @ 2009-08-30 19:01 UTC (permalink / raw)
To: Daniele Segato; +Cc: John Tapsell, Frank Münnich, git
In-Reply-To: <1251655664.31273.4.camel@localhost>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 697 bytes --]
On Sun, 30 Aug 2009, Daniele Segato wrote:
> 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.
I've spent all my career as a professional programmer using vim as my
sole source code editor for the last 15 years.
> What are the advantages of developing git with vim/emacs over an IDE?
Simplicity.
Nicolas
^ permalink raw reply
* Re: What IDEs are you using to develop git?
From: Daniele Segato @ 2009-08-30 18:07 UTC (permalink / raw)
To: John Tapsell; +Cc: Frank Münnich, git
In-Reply-To: <43d8ce650908250547t17b76c95qb9931983e0a4b232@mail.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?
Cheers,
Daniele
^ permalink raw reply
* Re: [PATCH] Fix overridable written with an extra 'e'
From: Uri Okrent @ 2009-08-30 17:58 UTC (permalink / raw)
To: git
In-Reply-To: <20090828034305.GQ4297@inocybe.localdomain>
Todd Zullinger <tmz <at> pobox.com> writes:
>
> Nanako Shiraishi wrote:
> > Found during the lunch break by one of my students...
>
> Is overridable a word itself? While English is my native language, I
> wouldn't call myself an expert on its proper usage. ;)
No, it's not a word =). But of the two non-words, overridable is probably
preferred.
>
> However, I can't find 'overridable' in several online dictionaries:
>
> http://dictionary.reference.com/browse/overridable
> http://www.merriam-webster.com/dictionary/overridable
> http://www.google.com/dictionary?aq=f&langpair=en|en&q=overridable&hl=en
> http://dictionary.cambridge.org/results.asp?searchword=overridable&x=0&y=0
>
> Perhaps using overridden would be more accurate?
It would be more correct, but also slightly more verbose. Still, as a grammar
nazi, my two cents says it raises git's esteem if the language in the docs is
proper English.
Uri
^ permalink raw reply
* [PATCH] Documentation/git-add.txt: Explain --patch option in layman terms
From: Jari Aalto @ 2009-08-30 17:29 UTC (permalink / raw)
To: git
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.
-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.
-e, \--edit::
Open the diff vs. the index in an editor and let the user
--
1.6.3.3
^ permalink raw reply related
* Re: Anyone meet DNS fail translate repo.or.cz
From: Mikael Magnusson @ 2009-08-30 16:58 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: Frank Li, git
In-Reply-To: <237967ef0908300350k4e06b522x9baa7aa5528d32d@mail.gmail.com>
Seems to be back up now.
2009/8/30 Mikael Magnusson <mikachu@gmail.com>:
> 2009/8/30 Erik Faye-Lund <kusmabite@googlemail.com>:
>> On Sun, Aug 30, 2009 at 6:20 AM, Frank Li<lznuaa@gmail.com> wrote:
>>> ALL:
>>> I can't access repo.or.cz from yesterday.
>>> DNS can't translate repo.or.cz.
>>> Even
>>> http://www.dnswatch.info/dns/dnslookup?la=en&host=repo.or.cz&type=A
>>>
>>> It also can't recognize repo.or.cz.
>>>
>>> Anyone meet the same problem?
>>
>> Yeah, I've been seeing the same problem here.
>
> The IP for both repo.or.cz and git.or.cz is 62.24.64.27
> If you add this to /etc/hosts you can still access both fine.
> 62.24.64.27 repo.or.cz git.or.cz
>
> --
> Mikael Magnusson
>
--
Mikael Magnusson
^ permalink raw reply
* Re: git-diff: must --exit-code work with --ignore* options?
From: Jim Meyering @ 2009-08-30 16:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git list
In-Reply-To: <7v7i087twu.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Jim Meyering <jim@meyering.net> writes:
>> Junio C Hamano wrote:
>>> Jim Meyering <jim@meyering.net> writes:
>>>>
>>>> # do this in an empty directory
>>>> $ git init -q; echo>k; git add .; git commit -q -m. .; echo \ >k
>>>> $ git diff --ignore-space-at-eol --quiet || echo bad
>>>> bad
>>>
>>> I am slightly torn about this, in that I can picture myself saying that
>>> this is unintuitive on some different days, but not today ;-)
>>
>> Thanks for the quick reply. Here's why I noticed:
>> ...
>
> It seems that today is already "some different day" ;-) We could do
> something like this patch.
>
> While in the longer term I think it may make the world a better place by
> being more consistent with what users expect, I am not sure at what
> revision boundary we should introduce such a semantic change.
>
> We could always declare this a bug and apply the "fix" at any time. It's
> all perception ;-).
>
> -- >8 --
> Subject: [PATCH] diff --quiet: special case "ignore whitespace" options
>
> The option "QUIET" primarily meant "find if we have _any_ difference as
> quick as possible and report", which means we often do not even have to
> look at blobs if we know the trees are different by looking at the higher
> level (e.g. "diff-tree A B"). As a side effect, because there is no point
> showing one change that we happened to have found first, it also enables
> NO_OUTPUT and EXIT_WITH_STATUS options, making the end result look quiet.
>
> Traditionally, the --ignore-whitespace* options have merely meant to tell
> the diff output routine that some class of differences are not worth
> showing in the textual diff output, so that the end user has easier time
> to review the remaining (presumably more meaningful) changes. These
> options never affected the outcome of the command, given as the exit
> status when the --exit-code option was in effect (either directly or
> indirectly).
>
> These two classes of options are incompatible. When you have only
> whitespace changes, you would expect:
>
> git diff -b --quiet
>
> to report that there is _no_ change. This is unfortunately not the case,
> however, if there are differences to be reported if the command was run
> without --quiet; there _is_ a change, and the command still exits with
> non-zero status.
>
> And that is wrong.
>
> Change the semantics of --ignore-whitespace* options to mean more than
> "omit showing the difference in text". When these options are used, the
> internal "quick" optimization is turned off, and the status reported with
> the --exit-code option will now match if any the textual diff output is
> actually produced.
>
> Also rename the internal option "QUIET" to "QUICK" to better reflect what
> its true purpose is.
Thanks again.
If there's anything I can to do help (add a test?), let me know.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox