* Announcement: cvs2svn 2.3.0 released
From: Michael Haggerty @ 2009-08-22 22:44 UTC (permalink / raw)
To: announce; +Cc: Subversion Users, Git Mailing List, Bazaar
I am happy to announce release 2.3.0 of cvs2svn/cvs2git/cvs2bzr.
cvs2svn is a tool for migrating a CVS repository to Subversion, git,
Bazaar, or Mercurial. The main design goals are robustness and 100% data
preservation. cvs2svn can convert just about any CVS repository we've
ever seen, including gcc, Mozilla, FreeBSD, KDE, and GNOME.
Release 2.3.0 primarily improves the support for converting to git and
Bazaar (including explicit cvs2git and cvs2bzr scripts). This release
also adds a few other minor features and fixes a bug when converting to
git with non-inline blobs.
More detailed information is available in the CHANGES file [1].
Note to packagers: Beginning with this release, the man pages for the
main scripts are generated automatically by running the script with the
"--man" option (e.g., "cvs2svn --man >cvs2svn.1") or by executing "make
man". The tarball does *not* include the man pages anymore.
You can get the tarball here:
http://cvs2svn.tigris.org/files/documents/1462/46528/cvs2svn-2.3.0.tar.gz
The MD5 checksum is 6c412baec974f3ff64b9145944682a15.
Please send any bug reports and comments to users@cvs2svn.tigris.org.
Michael
[1]
http://cvs2svn.tigris.org/source/browse/cvs2svn/tags/2.3.0/CHANGES?view=markup
------------------------------------------------------
http://cvs2svn.tigris.org/ds/viewMessage.do?dsForumId=1668&dsMessageId=2386391
To unsubscribe from this discussion, e-mail: [announce-unsubscribe@cvs2svn.tigris.org].
------------------------------------------------------
http://cvs2svn.tigris.org/ds/viewMessage.do?dsForumId=1670&dsMessageId=2386392
To unsubscribe from this discussion, e-mail: [users-unsubscribe@cvs2svn.tigris.org].
^ permalink raw reply
* [RFC] gitweb.perl t9500 t9501
From: Mark A Rada @ 2009-08-22 22:42 UTC (permalink / raw)
To: Jakub Narebski, Junio C Hamano; +Cc: git
In-Reply-To: <7vfxbldj31.fsf@alter.siamese.dyndns.org>
Ok, I have a few questions, please:
> Word-wrapped.
I have not been telling git-format-patch to use a specific width for
the diffstat, is the
standard width supposed to be 70? Also, you will note a line in the
patch below
that will definitely be broken, it looks like
diff --git a/t/t9500-gitweb-standalone-no-errors.sh b/t/t9500-gitweb-
standalone-no-errors.sh
I don't see an option for git-format-patch to get around that in the
man page,
how would I fix that?
> I do not mind keeping these two lines as belt-and-suspender, though.
That is a vivid analogy...I will have to remember that one for later.
I tried switching the order of the last two checks, and I think it
makes that unused
check more useful, it can inform clients they are trying something
that has been
explicitly disabled as opposed to just notifying them the format is
unsupported.
Do you think making the change is worthwhile? (new commit? rewinding?)
(The patch at the bottom currently assumes you have switched them
already.)
another snippet:
@@ -5175,10 +5175,10 @@ sub git_snapshot {
die_error(400, "Invalid snapshot format parameter");
} elsif (!exists($known_snapshot_formats{$format})) {
die_error(400, "Unknown snapshot format");
- } elsif (!grep($_ eq $format, @snapshot_fmts)) {
- die_error(403, "Unsupported snapshot format");
} elsif ($known_snapshot_formats{$format}{'disabled'}) {
die_error(403, "Snapshot format not allowed");
+ } elsif (!grep($_ eq $format, @snapshot_fmts)) {
+ die_error(403, "Unsupported snapshot format");
}
if (!defined $hash) {
>> A trick: use '\EOF' and you don't need to escape $ against variable
>> expansion by shell.
> It is not a "trick" but is a basic courtesy for reviewers. Even if
> you do
> not have any $ to worry about, _unless_ you actively know you would
> want
> variable substitution to happen, it is easier for readers if you
> signal
> the fact that the here-doc is verbatim by quoting the \EOF marker
> upfront.
Thanks for the protip, I've taken the liberty of making use of it for
gitweb-lib.sh,
I hope you don't mind, Jakub.
--
Mark A Rada (ferrous26)
marada@uwaterloo.ca
---
t/gitweb-lib.sh | 74 +++++++++++++++++++
t/t9500-gitweb-standalone-no-errors.sh | 68 +-----------------
t/t9501-gitweb-standalone-http-status.sh | 78 ++++++++++++++++++++
3 files changed, 153 insertions(+), 67 deletions(-)
diff --git a/t/gitweb-lib.sh b/t/gitweb-lib.sh
new file mode 100644
index 0000000..4f4115f
--- /dev/null
+++ b/t/gitweb-lib.sh
@@ -0,0 +1,74 @@
+#!/bin/sh
+#
+# Copyright (c) 2007 Jakub Narebski
+#
+
+
+gitweb_init () {
+ safe_pwd="$(perl -MPOSIX=getcwd -e 'print quotemeta(getcwd)')"
+ cat >gitweb_config.perl <<EOF
+#!/usr/bin/perl
+
+# gitweb configuration for tests
+
+our \$version = 'current';
+our \$GIT = 'git';
+our \$projectroot = "$safe_pwd";
+our \$project_maxdepth = 8;
+our \$home_link_str = 'projects';
+our \$site_name = '[localhost]';
+our \$site_header = '';
+our \$site_footer = '';
+our \$home_text = 'indextext.html';
+our @stylesheets = ('file:///$TEST_DIRECTORY/../gitweb/gitweb.css');
+our \$logo = 'file:///$TEST_DIRECTORY/../gitweb/git-logo.png';
+our \$favicon = 'file:///$TEST_DIRECTORY/../gitweb/git-favicon.png';
+our \$projects_list = '';
+our \$export_ok = '';
+our \$strict_export = '';
+
+EOF
+
+ cat >.git/description <<EOF
+$0 test repository
+EOF
+}
+
+gitweb_run () {
+ GATEWAY_INTERFACE='CGI/1.1'
+ HTTP_ACCEPT='*/*'
+ REQUEST_METHOD='GET'
+ SCRIPT_NAME="$TEST_DIRECTORY/../gitweb/gitweb.perl"
+ QUERY_STRING=""$1""
+ PATH_INFO=""$2""
+ export GATEWAY_INTERFACE HTTP_ACCEPT REQUEST_METHOD \
+ SCRIPT_NAME QUERY_STRING PATH_INFO
+
+ GITWEB_CONFIG=$(pwd)/gitweb_config.perl
+ export GITWEB_CONFIG
+
+ # some of git commands write to STDERR on error, but this is not
+ # written to web server logs, so we are not interested in that:
+ # we are interested only in properly formatted errors/warnings
+ rm -f gitweb.log &&
+ perl -- "$SCRIPT_NAME" \
+ >gitweb.output 2>gitweb.log &&
+ if grep '^[[]' gitweb.log >/dev/null 2>&1; then false; else true; fi
+
+ # gitweb.log is left for debugging
+ # gitweb.output is used to parse http output
+}
+
+. ./test-lib.sh
+
+if ! test_have_prereq PERL; then
+ say 'skipping gitweb tests, perl not available'
+ test_done
+fi
+
+perl -MEncode -e 'decode_utf8("", Encode::FB_CROAK)' >/dev/null 2>&1
|| {
+ say 'skipping gitweb tests, perl version is too old'
+ test_done
+}
+
+gitweb_init
diff --git a/t/t9500-gitweb-standalone-no-errors.sh b/t/t9500-gitweb-
standalone-no-errors.sh
index 6275181..32e47d3 100755
--- a/t/t9500-gitweb-standalone-no-errors.sh
+++ b/t/t9500-gitweb-standalone-no-errors.sh
@@ -9,73 +9,7 @@ This test runs gitweb (git web interface) as CGI
script from
commandline, and checks that it would not write any errors
or warnings to log.'
-gitweb_init () {
- safe_pwd="$(perl -MPOSIX=getcwd -e 'print quotemeta(getcwd)')"
- cat >gitweb_config.perl <<EOF
-#!/usr/bin/perl
-
-# gitweb configuration for tests
-
-our \$version = "current";
-our \$GIT = "git";
-our \$projectroot = "$safe_pwd";
-our \$project_maxdepth = 8;
-our \$home_link_str = "projects";
-our \$site_name = "[localhost]";
-our \$site_header = "";
-our \$site_footer = "";
-our \$home_text = "indextext.html";
-our @stylesheets = ("file:///$TEST_DIRECTORY/../gitweb/gitweb.css");
-our \$logo = "file:///$TEST_DIRECTORY/../gitweb/git-logo.png";
-our \$favicon = "file:///$TEST_DIRECTORY/../gitweb/git-favicon.png";
-our \$projects_list = "";
-our \$export_ok = "";
-our \$strict_export = "";
-
-EOF
-
- cat >.git/description <<EOF
-$0 test repository
-EOF
-}
-
-gitweb_run () {
- GATEWAY_INTERFACE="CGI/1.1"
- HTTP_ACCEPT="*/*"
- REQUEST_METHOD="GET"
- SCRIPT_NAME="$TEST_DIRECTORY/../gitweb/gitweb.perl"
- QUERY_STRING=""$1""
- PATH_INFO=""$2""
- export GATEWAY_INTERFACE HTTP_ACCEPT REQUEST_METHOD \
- SCRIPT_NAME QUERY_STRING PATH_INFO
-
- GITWEB_CONFIG=$(pwd)/gitweb_config.perl
- export GITWEB_CONFIG
-
- # some of git commands write to STDERR on error, but this is not
- # written to web server logs, so we are not interested in that:
- # we are interested only in properly formatted errors/warnings
- rm -f gitweb.log &&
- perl -- "$SCRIPT_NAME" \
- >/dev/null 2>gitweb.log &&
- if grep "^[[]" gitweb.log >/dev/null 2>&1; then false; else true; fi
-
- # gitweb.log is left for debugging
-}
-
-. ./test-lib.sh
-
-if ! test_have_prereq PERL; then
- say 'skipping gitweb tests, perl not available'
- test_done
-fi
-
-perl -MEncode -e 'decode_utf8("", Encode::FB_CROAK)' >/dev/null 2>&1
|| {
- say 'skipping gitweb tests, perl version is too old'
- test_done
-}
-
-gitweb_init
+. ./gitweb-lib.sh
#
----------------------------------------------------------------------
# no commits (empty, just initialized repository)
diff --git a/t/t9501-gitweb-standalone-http-status.sh b/t/t9501-gitweb-
standalone-http-status.sh
new file mode 100644
index 0000000..be042f0
--- /dev/null
+++ b/t/t9501-gitweb-standalone-http-status.sh
@@ -0,0 +1,78 @@
+#!/bin/sh
+#
+# Copyright (c) 2009 Mark Rada
+#
+
+
+test_description='gitweb as standalone script (http status tests).
+
+This test runs gitweb (git web interface) as CGI script from the
+commandline, and checks that it returns the appropriate http status
+code and message.'
+
+. ./gitweb-lib.sh
+
+#
----------------------------------------------------------------------
+# snapshot settings
+
+test_commit \
+ 'GITWEB' \
+ 'I CAN HAS SNAPSHOT?'
+
+cat >>gitweb_config.perl <<\EOF
+$feature{'snapshot'}{'override'} = 0;
+EOF
+
+test_expect_success \
+ 'snapshots: tgz only default format enabled' \
+ 'gitweb_run "p=.git;a=snapshot;h=HEAD;sf=tgz" &&
+ grep "Status: 200 OK" gitweb.output &&
+ gitweb_run "p=.git;a=snapshot;h=HEAD;sf=tbz2" &&
+ grep "403 - Unsupported snapshot format" gitweb.output &&
+ gitweb_run "p=.git;a=snapshot;h=HEAD;sf=txz" &&
+ grep "403 - Snapshot format not allowed" gitweb.output &&
+ gitweb_run "p=.git;a=snapshot;h=HEAD;sf=zip" &&
+ grep "403 - Unsupported snapshot format" gitweb.output'
+test_debug 'cat gitweb.output'
+
+
+cat >>gitweb_config.perl <<\EOF
+$feature{'snapshot'}{'default'} = ['tgz','tbz2','txz','zip'];
+EOF
+
+test_expect_success \
+ 'snapshots: all enabled in default, use default disabled value' \
+ 'gitweb_run "p=.git;a=snapshot;h=HEAD;sf=tgz" &&
+ grep "Status: 200 OK" gitweb.output &&
+ gitweb_run "p=.git;a=snapshot;h=HEAD;sf=tbz2" &&
+ grep "Status: 200 OK" gitweb.output &&
+ gitweb_run "p=.git;a=snapshot;h=HEAD;sf=txz" &&
+ grep "403 - Snapshot format not allowed" gitweb.output &&
+ gitweb_run "p=.git;a=snapshot;h=HEAD;sf=zip" &&
+ grep "Status: 200 OK" gitweb.output'
+test_debug 'cat gitweb.output'
+
+
+cat >>gitweb_config.perl <<\EOF
+$known_snapshot_formats{'zip'}{'disabled'} = 1;
+EOF
+
+test_expect_success \
+ 'snapshots: zip explicitly disabled' \
+ 'gitweb_run "p=.git;a=snapshot;h=HEAD;sf=zip" &&
+ grep "403 - Snapshot format not allowed" gitweb.output'
+test_debug 'cat gitweb.output'
+
+
+cat >>gitweb_config.perl <<\EOF
+$known_snapshot_formats{'tgz'}{'disabled'} = 0;
+EOF
+
+test_expect_success \
+ 'snapshots: tgz explicitly enabled' \
+ 'gitweb_run "p=.git;a=snapshot;h=HEAD;sf=tgz" &&
+ grep "Status: 200 OK" gitweb.output'
+test_debug 'cat gitweb.output'
+
+
+test_done
--
1.6.4
^ permalink raw reply related
* Re: git svn pointing at svn branch instead of trunk?
From: skillzero @ 2009-08-22 22:12 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20090822204627.GA22484@dcvr.yhbt.net>
On Sat, Aug 22, 2009 at 1:46 PM, Eric Wong<normalperson@yhbt.net> wrote:
> So you have something like this?
>
> ----------trunk
> \
> \-> tag
>
> It looks like it's mixed but that's because trunk is an ancestor of your
> tag, so the majority of commits (see git-svn-id:) look like they're from
> trunk except the latest git-svn-id: which should have the URL of the tag
> in it. So in short, everything here is OK.
Yes, that's what I see: most of the commits have a /trunk URL except
the last one has a /tags/TagX URL.
When the next commit happens on master (I don't have svn commit access
on the svn repo to try it myself), will git svn automatically track
master->trunk again? Or is there something I need to change to tell it
"master tracks svn's /trunk"? I normally do git svn fetch and git svn
rebase (while on master, I do all my own commits on a separate
branch).
> I changed this recently in b186a261b1f7ec1fbda8c5f6d84595f3a7716d92
> git svn used to always pick the newest change in the entire SVN repo
> to point master to, now it'll attempt to find "trunk" to be master.
Thanks, I'll build that and try it out. That sounds like what was confusing me.
^ permalink raw reply
* Improve on 'approxidate'
From: Linus Torvalds @ 2009-08-22 22:10 UTC (permalink / raw)
To: Git Mailing List, Junio C Hamano
This is not a new failure mode - approxidate has always been kind of
random in the input it accepts, but some of the randomness is more
irritating than others.
For example:
Jun 6, 5AM -> Mon Jun 22 05:00:00 2009
5AM Jun 6 -> Sat Jun 6 05:00:00 2009
Whaa? The reason for the above is that approxidate squirrells away the '6'
from "Jun 6" to see if it's going to be a relative number, and then
forgets about it when it sees a new number (the '5' in '5AM'). So the odd
"June 22" date is because today is July 22nd, and if it doesn't have
another day of the month, it will just pick todays mday - having ignored
the '6' entirely due to getting all excited about seeing a new number (5).
There are other oddnesses. This does not fix them all, but I think it
makes for fewer _really_ perplexing cases. At least now we have
Jun 6, 5AM -> Sat Jun 6 05:00:00 2009
5AM, Jun 6 -> Sat Jun 6 05:00:00 2009
which makes me happier. I can still point to cases that don't work as
well, but those are separate issues.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
date.c | 93 +++++++++++++++++++++++++++++++++++++++++++--------------------
1 files changed, 63 insertions(+), 30 deletions(-)
diff --git a/date.c b/date.c
index 409a17d..51c6461 100644
--- a/date.c
+++ b/date.c
@@ -525,11 +525,8 @@ static int match_digit(const char *date, struct tm *tm, int *offset, int *tm_gmt
}
}
- if (num > 0 && num < 32) {
- tm->tm_mday = num;
- } else if (num > 0 && num < 13) {
+ if (num > 0 && num < 13 && tm->tm_mon < 0)
tm->tm_mon = num-1;
- }
return n;
}
@@ -657,42 +654,59 @@ void datestamp(char *buf, int bufsize)
date_string(now, offset, buf, bufsize);
}
-static void update_tm(struct tm *tm, unsigned long sec)
+/*
+ * Relative time update (eg "2 days ago"). If we haven't set the time
+ * yet, we need to set it from current time.
+ */
+static unsigned long update_tm(struct tm *tm, struct tm *now, unsigned long sec)
{
- time_t n = mktime(tm) - sec;
+ time_t n;
+
+ if (tm->tm_mday < 0)
+ tm->tm_mday = now->tm_mday;
+ if (tm->tm_mon < 0)
+ tm->tm_mon = now->tm_mon;
+ if (tm->tm_year < 0) {
+ tm->tm_year = now->tm_year;
+ if (tm->tm_mon > now->tm_mon)
+ tm->tm_year--;
+ }
+
+ n = mktime(tm) - sec;
localtime_r(&n, tm);
+ return n;
}
-static void date_yesterday(struct tm *tm, int *num)
+static void date_yesterday(struct tm *tm, struct tm *now, int *num)
{
- update_tm(tm, 24*60*60);
+ update_tm(tm, now, 24*60*60);
}
-static void date_time(struct tm *tm, int hour)
+static void date_time(struct tm *tm, struct tm *now, int hour)
{
if (tm->tm_hour < hour)
- date_yesterday(tm, NULL);
+ date_yesterday(tm, now, NULL);
tm->tm_hour = hour;
tm->tm_min = 0;
tm->tm_sec = 0;
}
-static void date_midnight(struct tm *tm, int *num)
+static void date_midnight(struct tm *tm, struct tm *now, int *num)
{
- date_time(tm, 0);
+ date_time(tm, now, 0);
}
-static void date_noon(struct tm *tm, int *num)
+static void date_noon(struct tm *tm, struct tm *now, int *num)
{
- date_time(tm, 12);
+ date_time(tm, now, 12);
}
-static void date_tea(struct tm *tm, int *num)
+static void date_tea(struct tm *tm, struct tm *now, int *num)
{
- date_time(tm, 17);
+ date_time(tm, now, 17);
}
-static void date_pm(struct tm *tm, int *num)
+static void date_pm(struct tm *tm, struct tm *now, int *num)
{
int hour, n = *num;
*num = 0;
@@ -706,7 +720,7 @@ static void date_pm(struct tm *tm, int *num)
tm->tm_hour = (hour % 12) + 12;
}
-static void date_am(struct tm *tm, int *num)
+static void date_am(struct tm *tm, struct tm *now, int *num)
{
int hour, n = *num;
*num = 0;
@@ -720,7 +734,7 @@ static void date_am(struct tm *tm, int *num)
tm->tm_hour = (hour % 12);
}
-static void date_never(struct tm *tm, int *num)
+static void date_never(struct tm *tm, struct tm *now, int *num)
{
time_t n = 0;
localtime_r(&n, tm);
@@ -728,7 +742,7 @@ static void date_never(struct tm *tm, int *num)
static const struct special {
const char *name;
- void (*fn)(struct tm *, int *);
+ void (*fn)(struct tm *, struct tm *, int *);
} special[] = {
{ "yesterday", date_yesterday },
{ "noon", date_noon },
@@ -757,7 +771,7 @@ static const struct typelen {
{ NULL }
};
-static const char *approxidate_alpha(const char *date, struct tm *tm, int *num)
+static const char *approxidate_alpha(const char *date, struct tm *tm, struct tm *now, int *num)
{
const struct typelen *tl;
const struct special *s;
@@ -778,7 +792,7 @@ static const char *approxidate_alpha(const char *date, struct tm *tm, int *num)
for (s = special; s->name; s++) {
int len = strlen(s->name);
if (match_string(date, s->name) == len) {
- s->fn(tm, num);
+ s->fn(tm, now, num);
return end;
}
}
@@ -800,7 +814,7 @@ static const char *approxidate_alpha(const char *date, struct tm *tm, int *num)
while (tl->type) {
int len = strlen(tl->type);
if (match_string(date, tl->type) >= len-1) {
- update_tm(tm, tl->length * *num);
+ update_tm(tm, now, tl->length * *num);
*num = 0;
return end;
}
@@ -818,7 +832,7 @@ static const char *approxidate_alpha(const char *date, struct tm *tm, int *num)
n++;
diff += 7*n;
- update_tm(tm, diff * 24 * 60 * 60);
+ update_tm(tm, now, diff * 24 * 60 * 60);
return end;
}
}
@@ -866,6 +880,22 @@ static const char *approxidate_digit(const char *date, struct tm *tm, int *num)
return end;
}
+/*
+ * Do we have a pending number at the end, or when
+ * we see a new one? Let's assume it's a month day,
+ * as in "Dec 6, 1992"
+ */
+static void pending_number(struct tm *tm, int *num)
+{
+ int number = *num;
+
+ if (number) {
+ *num = 0;
+ if (tm->tm_mday < 0 && number < 32)
+ tm->tm_mday = number;
+ }
+}
+
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;
+
for (;;) {
unsigned char c = *date;
if (!c)
break;
date++;
if (isdigit(c)) {
+ pending_number(&tm, &number);
date = approxidate_digit(date-1, &tm, &number);
continue;
}
if (isalpha(c))
- date = approxidate_alpha(date-1, &tm, &number);
+ date = approxidate_alpha(date-1, &tm, &now, &number);
}
- if (number > 0 && number < 32)
- tm.tm_mday = number;
- if (tm.tm_mon > now.tm_mon && tm.tm_year == now.tm_year)
- tm.tm_year--;
- return mktime(&tm);
+ pending_number(&tm, &number);
+ return update_tm(&tm, &now, 0);
}
^ permalink raw reply related
* Re: What's a good setup for submitting patches to the list properly?
From: Thell Fowler @ 2009-08-22 20:58 UTC (permalink / raw)
To: Christian Couder; +Cc: Thell Fowler, git, Julian Phillips
In-Reply-To: <200908222220.35354.chriscool@tuxfamily.org>
Christian Couder (chriscool@tuxfamily.org) wrote on Aug 22, 2009:
> On Saturday 22 August 2009, Thell Fowler wrote:
> >
> > > What could I have done/checked before sending to make sure that these
> > > would have posted properly?
>
> Perhaps you could send them to yourself.
>
Yes, I did. They all showed up under the correct thread, but then I
changed how I did it by adding cover-letter to the format-patch options.
BTW - After looking at the headers it looks like the cover letter header
worked just fine, but that the cover letter msg-id changed between when
format-patch created it and when it was sent out causing the reset of the
msgs to not have anything to reference to.
> > No input on this? Perhaps I should've posted to the git user or alpine
> > lists?
>
> It's ok to post this kind of questions on the git mailing list.
>
> There is "git send-email" that is bundled with git. But I use
> git-mail-commits from Julian Philips. I am very happy with it. Thanks
> Julian!
>
I guess I'll setup smtp and try the send-email route, not sure if that
is going to change anything having to do with the In-Reply-To field
and a cover letter or how it shows in the threading.
If that doesn't work then I'll give Julian's mail-commits a whirl.
Thanks for replying Christian!
--
Thell
^ permalink raw reply
* git-mail-commits (Re: What's a good setup for submitting patches to the list properly?)
From: Nicolas Sebrecht @ 2009-08-22 20:56 UTC (permalink / raw)
To: Christian Couder; +Cc: Thell Fowler, git, Julian Phillips
In-Reply-To: <200908222220.35354.chriscool@tuxfamily.org>
The 22/08/09, Christian Couder wrote:
> There is "git send-email" that is bundled with git. But I use
> git-mail-commits from Julian Philips. I am very happy with it. Thanks
> Julian!
Isn't there any public repo for it?
--
Nicolas Sebrecht
^ permalink raw reply
* Re: git svn pointing at svn branch instead of trunk?
From: Eric Wong @ 2009-08-22 20:46 UTC (permalink / raw)
To: skillzero; +Cc: git
In-Reply-To: <2729632a0908221140p532a3c29k90af7b4cbd25d65e@mail.gmail.com>
skillzero@gmail.com wrote:
> 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.
Hi,
So you have something like this?
----------trunk
\
\-> tag
It looks like it's mixed but that's because trunk is an ancestor of your
tag, so the majority of commits (see git-svn-id:) look like they're from
trunk except the latest git-svn-id: which should have the URL of the tag
in it. So in short, everything here is OK.
> 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?).
I changed this recently in b186a261b1f7ec1fbda8c5f6d84595f3a7716d92
git svn used to always pick the newest change in the entire SVN repo
to point master to, now it'll attempt to find "trunk" to be master.
You can git reset anything on your master without affecting git svn.
If you have commits on master, just cherry pick them to a new branch
that's based off trunk and then reset master to be that new branch.
--
Eric Wong
^ permalink raw reply
* Re: What's a good setup for submitting patches to the list properly?
From: Christian Couder @ 2009-08-22 20:20 UTC (permalink / raw)
To: Thell Fowler; +Cc: git, Julian Phillips
In-Reply-To: <alpine.DEB.2.00.0908220953460.2012@GWPortableVCS>
On Saturday 22 August 2009, Thell Fowler wrote:
>
> > What could I have done/checked before sending to make sure that these
> > would have posted properly?
Perhaps you could send them to yourself.
> No input on this? Perhaps I should've posted to the git user or alpine
> lists?
It's ok to post this kind of questions on the git mailing list.
There is "git send-email" that is bundled with git. But I use
git-mail-commits from Julian Philips. I am very happy with it. Thanks
Julian!
Regards,
Christian.
^ permalink raw reply
* Re: Issue with gitweb + tag + branch of the same name from master branch commit
From: Nicholas A. Bellinger @ 2009-08-22 20:12 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, J.H., H. Peter Anvin
In-Reply-To: <m3fxbkn5ot.fsf@localhost.localdomain>
Greetings Jakub,
On Fri, 2009-08-21 at 15:49 -0700, Jakub Narebski wrote:
> "Nicholas A. Bellinger" <nab@linux-iscsi.org> writes:
>
> > I have recently been trying to make a tag and branch of the same name
>
> But why? Why do you want to confuse git and yourself?
>
I stumbled the strangeness in k.o gitweb due to my inexperience with git
tagging+branch.. I absoulutely agree that it makes more sense to use
different names for these, and that is what I am doing from now on.. :-)
> > from a previous <COMMIT> on a master branch on a kernel.org tree using
> > the following commands:
> >
> > # Create the tag:
> > git tag -a lio-x.y <COMMIT>
> > # Push the tags:
> > git push --tags origin
> > # Fetch to be sure
> > git fetch origin
> > # Make tagged branch:
> > git checkout -b lio-x.y <COMMIT>
> > # Make <NEW_COMMIT> to lio-x.y and commit
> > git commit frob
> > # Switch back to master branch
> > git checkout master
> > # Push local branch to origin
> > git push origin refs/heads/lio-x.y
> >
> > At this point after pushing to origin, I can do a fresh clone of the
> > tree, and do a 'git checkout origin/lio-x.y and I see '<NEW_COMMIT>',
> > and the logs and blobs look as expected..
> >
> > However, after checking gitweb log for branch lio-x.y on kernel.org, I
> > only see <COMMIT>, and not <NEW_COMMIT>, and all of the blobs in branch
> > lio-x.y still reference the original <COMMIT>, et al.
>
> I guess that you meant here gitweb's 'log' / 'shortlog' view linked
> from 'heads' view, don't you?
That is correct..
>
> > John Hawley has been helping to resolve the issue (I am just going to
> > use different tag/branch names instead), and hpa asked me to report this
> > as it is easy to reproduce with the gitweb version on kernel.org..
>
> > 22:42 < warthog9> I would got show this to the git people, it *could*
> > just be an old bug in gitweb (ours is not particularly
> > up to date) but if I can replicate it here easily enough
> > I'm guessing there's still a bug elsewhere
>
> This is an old and long fixed (or rather worked around) issue in
> gitweb, fixed in bf901f8 (gitweb: disambiguate heads and tags withs
> the same name, 2007-12-15)... well if by fixed you can consider
> passing around "fully qualified" refnames, i.e. the 'shortlog' link in
> 'heads' view now uses 'refs/heads/frob', and not only 'frob'.
>
Cool, I am hear it has already been fixed.
--nab
^ permalink raw reply
* Re: [PATCH v3 1/9] sequencer: add "do_fast_forward()" to perform a fast forward
From: Junio C Hamano @ 2009-08-22 20:15 UTC (permalink / raw)
To: Christian Couder
Cc: git, Johannes Schindelin, Stephan Beyer, Daniel Barkalow,
Jakub Narebski
In-Reply-To: <200908221319.37737.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
>> Hmm, forgot to amend, or perhaps you sent out a wrong series?
>
> Your comments on the v2 series were in a message replying to patch 5/9, so I
> amended only 5/9 and after it, because I thought that you had already
> reviewed those before 5/9 and they were ok.
Sorry, but in general I expect readers of this list to be intelligent
enough and capable of extrapolating, so that I do not have to spell out
the same issue over and over again ;-)
> As you merged the series in pu, I thought that it was ok.
Heh, being queued to 'pu' does not mean any more than just that we do not
want to lose what the author spent efforts to produce, and we want to give
reviewers easier access to the end result. If it is Ok, it would have
been in 'next'.
That's why topics initially queued in 'pu' sometimes move to 'stalled'
state in "What's in" report and then eventually get ejected.
The comment you added only says what it does, namely, that it does two
different things, based on the allow_dirty global variable that is
underdocumented. It does not explain _why_ it is a good thing, in what
circumstance the caller would want "almost" semantics and in what other
circumstance the caller would want a "real" hard reset.
>> I am afraid that the whole cc/sequencer-rebase-i series needs a serious
>> reroll before it gets near 'next'.
>
> Ok, I will reroll everything to try to improve commit messages.
It would be a good idea; it may expose a wrong abstraction or an
insufficient refactoring (e.g. adding yet another function to make a
commit object that runs parallel to what we already have).
Thanks.
^ permalink raw reply
* git svn pointing at svn branch instead of trunk?
From: skillzero @ 2009-08-22 18:40 UTC (permalink / raw)
To: git
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.
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?).
^ permalink raw reply
* Re: hitting home directory's parent
From: Jeff King @ 2009-08-22 18:16 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Daniel Convissor, Git Mailing List
In-Reply-To: <fcaeb9bf0908220920g29ec24e9v23d0504d10ca6cfb@mail.gmail.com>
On Sat, Aug 22, 2009 at 11:20:39PM +0700, Nguyen Thai Ngoc Duy wrote:
> > I did read a bit farther in the manual and initialized a new repository.
> > Issuing "git --help" once inside that new repository works. Requiring
> > the --help command to be called from inside a repository, or even that
> > it's looking for a repository at all, seems unwise. All it should do is
> > display the usage information and exit.
>
> For simple things like --help, I agree Git should not do extra work
> such as searching for Git repository, which is the cause. That was on
> Jeff's plan IIRC.
Without looking, I would not be surprised if it is a side effect of
git trying to look up help-related config. So I don't think it is a
problem exactly that it checks to see if it is in a repo (which would
impact config lookup), but that inability to find a repo is a hard
error.
Probably it is calling "setup_git_directory_gently" and ignoring an
error return, but there is a die() inside that function. The bug
then is that the _gently form is calling die().
As for fixing the setup code, I am sadly way behind on my git queue and
not likely to catch up to this anytime soon. So if anybody feels like
taking a stab at it, that would be very welcome.
-Peff
^ permalink raw reply
* Re: hitting home directory's parent
From: Nguyen Thai Ngoc Duy @ 2009-08-22 16:22 UTC (permalink / raw)
To: Daniel Convissor; +Cc: Git Mailing List
In-Reply-To: <fcaeb9bf0908220920g29ec24e9v23d0504d10ca6cfb@mail.gmail.com>
On Sat, Aug 22, 2009 at 11:20 PM, Nguyen Thai Ngoc Duy<pclouds@gmail.com> wrote:
> But did it at least change the error message? Here is what I got when
> "chmod 000 /tmp/a":
>
> /tmp/a/b/c $ cd ../..
> bash: cd: ../..: Permission denied
> /tmp/a/b/c $ git --help
> fatal: Cannot change to '/tmp/a/b/c/..': Permission denied
> /tmp/a/b/c $ GIT_CEILING_DIRECTORIES=/tmp/a/b git --help
> fatal: Cannot come back to cwd: Permission denied
Note: I tested it on Linux, not Cygwin so the behavior may differ.
--
Duy
^ permalink raw reply
* Re: hitting home directory's parent
From: Nguyen Thai Ngoc Duy @ 2009-08-22 16:20 UTC (permalink / raw)
To: Daniel Convissor; +Cc: Git Mailing List
In-Reply-To: <20090822150542.GA29507@panix.com>
On Sat, Aug 22, 2009 at 10:05 PM, Daniel
Convissor<danielc@analysisandsolutions.com> wrote:
> Hi Duy:
>
> On Sat, Aug 22, 2009 at 11:10:18AM +0700, Nguyen Thai Ngoc Duy wrote:
>>
>> I guess it tried to find .git directory upward. I think you can set
>> GIT_CEILING_DIRECTORIES to make it stop at /home/danielc. Excerpt from
>> git.txt
>
> That didn't change the situation.
I'd suggest you to degrade Git to a version earlier than 1.6.1, when
the error was not added. :-D
But did it at least change the error message? Here is what I got when
"chmod 000 /tmp/a":
/tmp/a/b/c $ cd ../..
bash: cd: ../..: Permission denied
/tmp/a/b/c $ git --help
fatal: Cannot change to '/tmp/a/b/c/..': Permission denied
/tmp/a/b/c $ GIT_CEILING_DIRECTORIES=/tmp/a/b git --help
fatal: Cannot come back to cwd: Permission denied
Looks like absolute path will cause troubles anyway this case.
> I did read a bit farther in the manual and initialized a new repository.
> Issuing "git --help" once inside that new repository works. Requiring
> the --help command to be called from inside a repository, or even that
> it's looking for a repository at all, seems unwise. All it should do is
> display the usage information and exit.
For simple things like --help, I agree Git should not do extra work
such as searching for Git repository, which is the cause. That was on
Jeff's plan IIRC.
--
Duy
^ permalink raw reply
* Re: hitting home directory's parent
From: Daniel Convissor @ 2009-08-22 15:05 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <fcaeb9bf0908212110o5ed1233ek11183fa37b474a06@mail.gmail.com>
Hi Duy:
On Sat, Aug 22, 2009 at 11:10:18AM +0700, Nguyen Thai Ngoc Duy wrote:
>
> I guess it tried to find .git directory upward. I think you can set
> GIT_CEILING_DIRECTORIES to make it stop at /home/danielc. Excerpt from
> git.txt
That didn't change the situation.
I did read a bit farther in the manual and initialized a new repository.
Issuing "git --help" once inside that new repository works. Requiring
the --help command to be called from inside a repository, or even that
it's looking for a repository at all, seems unwise. All it should do is
display the usage information and exit.
Thanks,
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
^ permalink raw reply
* Re: What's a good setup for submitting patches to the list properly?
From: Thell Fowler @ 2009-08-22 15:01 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.2.00.0908191849220.2012@GWPortableVCS>
Thell Fowler (git@tbfowler.name) wrote on Aug 19, 2009:
> I haven't been able to figure out a good setup for posting patches to the
> list correctly, perhaps someone could tell me where I'm going wrong.
>
> Alpine is setup to access git @ tbfowler.name with the 'postpone' folder
> being the 'Drafts' folder on the remote mail host, and a local mbox folder
> ~/mail/git
>
> Locally I prepped the emails using:
>
> git format-patch --cover-letter --full-index -n
> --in-reply-to=1249428804.2774.52.camel@GWPortableVCS --thread --signoff -6
> --stdout>>~/mail/git
>
Did I miss something with that command?
> http://article.gmane.org/gmane.comp.version-control.git/124834
>
> Thinking that the cover letter would be in reply to a previous thread, and
> that the rest would show as a reply to that. After doing the
> format-patch, I went into Alpine's git folder selected the messages and
> saved them to the Drafts folder, then did 'compose' for each one, filling
> in the information I thought was needed.
>
Perhaps the saving to a new folder could've messed something up with the
headers?
[snip]
> What could I have done/checked before sending to make sure that these
> would have posted properly?
No input on this? Perhaps I should've posted to the git user or alpine
lists?
Either way, I'll be sending a new version of the patch I've been working
on and rather than have them show as top posts again I'd rather do it
correctly.
Or perhaps there is an easier more direct route...
--
Thell
^ permalink raw reply
* [RFC PATCH] ce_uptodate(): discriminate lstat()-based and assume-unchanged uptodate
From: Nguyễn Thái Ngọc Duy @ 2009-08-22 12:43 UTC (permalink / raw)
To: git, Junio C Hamano; +Cc: Nguyễn Thái Ngọc Duy
Commit 1dcafcc (verify_uptodate(): add ce_uptodate(ce) test) makes me
realize that people might not be well aware of assume-unchanged bit (CE_VALID).
Back when there was no assume-unchanged bit, ce_uptodate() means that
entry is really uptodate and has been checked by lstat(). When
assume-unchanged comes into play, it will blindly mark an entry
uptodate if that entry is assume-unchanged.
Even if it is assume-unchanged, it may have local changes that users
may want to keep. Thus when it comes to updating worktree, we may need to
know if it is _really_ uptodate regardless assume-unchanged. For that
matter, ce_uptodate() does not help much as it could be a result of
lstat() or assume-unchanged bit.
This patch attempts to make Git developers think twice about that
by.. getting rid of ce_uptodate() in favor of two new macros
ce_maybe_uptodate() and ce_really_uptodate()
- ce_maybe_uptodate() works as ce_uptodate() does now.
- ce_really_uptodate() is true only if it is lstat()-based uptodate.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
OK I could not stop looking at CE_VALID :-) I think this is a good
change. However I may have made mistakes in translating from
ce_uptodate() to ce_{maybe,really}_uptodate().
cache.h | 14 ++++++++++++--
diff-lib.c | 6 +++---
diff.c | 2 +-
dir.c | 4 ++--
preload-index.c | 4 ++--
read-cache.c | 12 ++++++------
unpack-trees.c | 4 ++--
7 files changed, 28 insertions(+), 18 deletions(-)
diff --git a/cache.h b/cache.h
index f793789..24f66ab 100644
--- a/cache.h
+++ b/cache.h
@@ -176,6 +176,7 @@ struct cache_entry {
#define CE_HASHED (0x100000)
#define CE_UNHASHED (0x200000)
+#define CE_ASSUME_UPTODATE (0x800000)
/*
* Extended on-disk flags
@@ -232,8 +233,9 @@ static inline size_t ce_namelen(const struct cache_entry *ce)
ondisk_cache_entry_extended_size(ce_namelen(ce)) : \
ondisk_cache_entry_size(ce_namelen(ce)))
#define ce_stage(ce) ((CE_STAGEMASK & (ce)->ce_flags) >> CE_STAGESHIFT)
-#define ce_uptodate(ce) ((ce)->ce_flags & CE_UPTODATE)
-#define ce_mark_uptodate(ce) ((ce)->ce_flags |= CE_UPTODATE)
+#define ce_maybe_uptodate(ce) ((ce)->ce_flags & (CE_UPTODATE | CE_ASSUME_UPTODATE))
+#define ce_really_uptodate(ce) ((ce)->ce_flags & CE_UPTODATE)
+/* #define ce_mark_uptodate(ce) ((ce)->ce_flags |= CE_UPTODATE) */
#define ce_permissions(mode) (((mode) & 0100) ? 0755 : 0644)
static inline unsigned int create_ce_mode(unsigned int mode)
@@ -463,6 +465,14 @@ extern int index_name_is_other(const struct index_state *, const char *, int);
extern int ie_match_stat(const struct index_state *, struct cache_entry *, struct stat *, unsigned int);
extern int ie_modified(const struct index_state *, struct cache_entry *, struct stat *, unsigned int);
+static inline void ce_mark_uptodate(struct cache_entry *ce, int options)
+{
+ if ((ce->ce_flags & CE_VALID) && !(options & CE_MATCH_IGNORE_VALID))
+ ce->ce_flags |= CE_ASSUME_UPTODATE;
+ else
+ ce->ce_flags |= CE_UPTODATE;
+}
+
extern int ce_path_match(const struct cache_entry *ce, const char **pathspec);
extern int index_fd(unsigned char *sha1, int fd, struct stat *st, int write_object, enum object_type type, const char *path);
extern int index_path(unsigned char *sha1, const char *path, struct stat *st, int write_object);
diff --git a/diff-lib.c b/diff-lib.c
index e7e8e88..9cbfec0 100644
--- a/diff-lib.c
+++ b/diff-lib.c
@@ -159,7 +159,7 @@ int run_diff_files(struct rev_info *revs, unsigned int option)
continue;
}
- if (ce_uptodate(ce))
+ if (ce_maybe_uptodate(ce))
continue;
changed = check_removed(ce, &st);
@@ -176,7 +176,7 @@ int run_diff_files(struct rev_info *revs, unsigned int option)
}
changed = ce_match_stat(ce, &st, ce_option);
if (!changed) {
- ce_mark_uptodate(ce);
+ ce_mark_uptodate(ce, ce_option);
if (!DIFF_OPT_TST(&revs->diffopt, FIND_COPIES_HARDER))
continue;
}
@@ -214,7 +214,7 @@ static int get_stat_data(struct cache_entry *ce,
const unsigned char *sha1 = ce->sha1;
unsigned int mode = ce->ce_mode;
- if (!cached && !ce_uptodate(ce)) {
+ if (!cached && !ce_really_uptodate(ce)) {
int changed;
struct stat st;
changed = check_removed(ce, &st);
diff --git a/diff.c b/diff.c
index 91d6ea2..7b94fb9 100644
--- a/diff.c
+++ b/diff.c
@@ -1811,7 +1811,7 @@ static int reuse_worktree_file(const char *name, const unsigned char *sha1, int
/*
* If ce matches the file in the work tree, we can reuse it.
*/
- if (ce_uptodate(ce) ||
+ if (ce_really_uptodate(ce) ||
(!lstat(name, &st) && !ce_match_stat(ce, &st, 0)))
return 1;
diff --git a/dir.c b/dir.c
index d0999ba..64f0fc6 100644
--- a/dir.c
+++ b/dir.c
@@ -573,7 +573,7 @@ static int get_index_dtype(const char *path, int len)
ce = cache_name_exists(path, len, 0);
if (ce) {
- if (!ce_uptodate(ce))
+ if (!ce_maybe_uptodate(ce))
return DT_UNKNOWN;
if (S_ISGITLINK(ce->ce_mode))
return DT_DIR;
@@ -597,7 +597,7 @@ static int get_index_dtype(const char *path, int len)
break;
if (ce->name[len] < '/')
continue;
- if (!ce_uptodate(ce))
+ if (!ce_maybe_uptodate(ce))
break; /* continue? */
return DT_DIR;
}
diff --git a/preload-index.c b/preload-index.c
index 9289933..85c31c5 100644
--- a/preload-index.c
+++ b/preload-index.c
@@ -47,7 +47,7 @@ static void *preload_thread(void *_data)
if (ce_stage(ce))
continue;
- if (ce_uptodate(ce))
+ if (ce_maybe_uptodate(ce))
continue;
if (!ce_path_match(ce, p->pathspec))
continue;
@@ -57,7 +57,7 @@ static void *preload_thread(void *_data)
continue;
if (ie_match_stat(index, ce, &st, CE_MATCH_RACY_IS_DIRTY))
continue;
- ce_mark_uptodate(ce);
+ ce_mark_uptodate(ce, 0);
} while (--nr > 0);
return NULL;
}
diff --git a/read-cache.c b/read-cache.c
index 4e3e272..ac7cdd3 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -81,7 +81,7 @@ void fill_stat_cache_info(struct cache_entry *ce, struct stat *st)
ce->ce_flags |= CE_VALID;
if (S_ISREG(st->st_mode))
- ce_mark_uptodate(ce);
+ ce_mark_uptodate(ce, CE_MATCH_IGNORE_VALID);
}
static int ce_compare_data(struct cache_entry *ce, struct stat *st)
@@ -605,7 +605,7 @@ int add_to_index(struct index_state *istate, const char *path, struct stat *st,
if (alias && !ce_stage(alias) && !ie_match_stat(istate, alias, st, ce_option)) {
/* Nothing changed, really */
free(ce);
- ce_mark_uptodate(alias);
+ ce_mark_uptodate(alias, ce_option);
alias->ce_flags |= CE_ADDED;
return 0;
}
@@ -1001,7 +1001,7 @@ static struct cache_entry *refresh_cache_ent(struct index_state *istate,
int changed, size;
int ignore_valid = options & CE_MATCH_IGNORE_VALID;
- if (ce_uptodate(ce))
+ if (ce_maybe_uptodate(ce))
return ce;
/*
@@ -1009,7 +1009,7 @@ static struct cache_entry *refresh_cache_ent(struct index_state *istate,
* the work tree does not matter and told us not to worry.
*/
if (!ignore_valid && (ce->ce_flags & CE_VALID)) {
- ce_mark_uptodate(ce);
+ ce_mark_uptodate(ce, options);
return ce;
}
@@ -1037,7 +1037,7 @@ static struct cache_entry *refresh_cache_ent(struct index_state *istate,
* because CE_UPTODATE flag is in-core only;
* we are not going to write this change out.
*/
- ce_mark_uptodate(ce);
+ ce_mark_uptodate(ce, options);
return ce;
}
}
@@ -1543,7 +1543,7 @@ int write_index(struct index_state *istate, int newfd)
struct cache_entry *ce = cache[i];
if (ce->ce_flags & CE_REMOVE)
continue;
- if (!ce_uptodate(ce) && is_racy_timestamp(istate, ce))
+ if (!ce_maybe_uptodate(ce) && is_racy_timestamp(istate, ce))
ce_smudge_racily_clean_entry(ce);
if (ce_write_entry(&c, newfd, ce) < 0)
return -1;
diff --git a/unpack-trees.c b/unpack-trees.c
index 720f7a1..c0774d7 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -450,7 +450,7 @@ static int verify_uptodate(struct cache_entry *ce,
{
struct stat st;
- if (o->index_only || o->reset || ce_uptodate(ce))
+ if (o->index_only || o->reset || ce_really_uptodate(ce))
return 0;
if (!lstat(ce->name, &st)) {
@@ -1004,7 +1004,7 @@ int oneway_merge(struct cache_entry **src, struct unpack_trees_options *o)
if (old && same(old, a)) {
int update = 0;
- if (o->reset && !ce_uptodate(old)) {
+ if (o->reset && !ce_really_uptodate(old)) {
struct stat st;
if (lstat(old->name, &st) ||
ie_match_stat(o->src_index, old, &st, CE_MATCH_IGNORE_VALID))
--
1.6.3.GIT
^ permalink raw reply related
* Re: [RFC PATCH v4 04/19] Teach Git to respect skip-worktree bit (reading part)
From: Nguyen Thai Ngoc Duy @ 2009-08-22 11:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd46pf4yw.fsf@alter.siamese.dyndns.org>
On Sat, Aug 22, 2009 at 12:32 AM, Junio C Hamano<gitster@pobox.com> wrote:
> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>
>> 2009/8/20 Nguyễn Thái Ngọc Duy <pclouds@gmail.com>:
>>> grep: turn on --cached for files that is marked skip-worktree
>>> ls-files: do not check for deleted file that is marked skip-worktree
>>> update-index: ignore update request if it's skip-worktree, while still allows removing
>>> diff*: skip worktree version
>>
>> I kept reminding myself and still managed to miss it. skip-worktree
>> bit is not completely independent from assume-unchanged. It shares
>> CE_MATCH_IGNORE_VALID flag in ie_match_stat(). Should have mentioned
>> that in commit log.
I should have just renamed it to CE_MATCH_PARANOID. That would fit
both assume-unchanged and skip-worktree bits.
> Yeah, that is why I feel uneasy reading your response to my other message:
>
> This series does not fix assume-unchanged bit. I'd like to focus on
> skip-worktree bit now. ... I don't know if I understand assume-unchanged
> semantics correctly anymore :-)
The thing is there are grey areas where assume-unchanged is used. If
worktree version is there and really uptodate, nothing to worry about.
We seemed to care of local changes in assume-unchanged files, but
that's not written in stone. So I started off with a new bit, clearer
semantics. Perhaps new changes could be applied back to
assume-unchanged bit, but I'd stay away from that for now.
--
Duy
^ permalink raw reply
* Re: [PATCH 09/14] Avoid including windows.h in winansi.c for MSVC build
From: Marius Storm-Olsen @ 2009-08-22 11:40 UTC (permalink / raw)
To: Reece Dunn; +Cc: Junio C Hamano, Johannes.Schindelin, msysgit, git, lznuaa
In-Reply-To: <3f4fd2640908211416i489b6e23s27cb9cae6a439ddc@mail.gmail.com>
On Fri, Aug 21, 2009 at 11:16 PM, Reece Dunn<msclrhd@googlemail.com> wrote:
> 2009/8/21 Junio C Hamano <gitster@pobox.com>:
>> Marius Storm-Olsen <mstormo@gmail.com> writes:
>>
>>> From: Frank Li <lznuaa@gmail.com>
>>>
>>> compat/msvc.h includes winsock2.h which conflicts with windows.h.
>>> msvc.h also defines the oldest Windows API version required.
>>
>> The first sentence sort-of makes sense; compat/msvc.h will be included by
>> git-compat-util.h and including <windows.h> here will bring conflicting
>> definitions, so we avoid doing so when on MSC.
>>
>> The second sentence does not make any sense to me. It may be correctly
>> stating a fact (i.e. "defines required WAPI version"), but it is unclear
>> what relevance it has to this change to stop including <windows.h>.
>
> The way things are configured, windows.h is pulling in winsock.h. In
> git-compat-util.h, winsock2.h is included which has conflicting
> definitions of various functions and data structures.
>
>> Having said that, the first sentence hints me that perhaps you guys should
>> include (conditionally only on windows but not with MSC) <windows.h> not
>> from this file, but from git-compat-util.h?
>
> It would make sense for windows.h to be included in git-compat-util.h.
>
> According to http://social.msdn.microsoft.com/Forums/en-US/windowssdk/thread/4a90b143-1fb8-43e9-a54c-956127e0c579,
> the following will work:
>
> #define _WINSOCKAPI_ // stops windows.h including winsock.h
> #include <winsock2.h>
> #include <windows.h>
>
> Also, if you define WIN32_LEAN_AND_MEAN, windows.h will pull in a
> subset of the Windows header files (which also improves compilation
> times). Adding this may prevent it from pulling in winsock.h. This
> would be a better approach (and would make sense to go into
> git-compat-util.h).
>
> I don't have access to a Windows dev box at the moment, so can't
> verify that this does indeed work.
>
> - Reece
>
I'll check this on Monday, and send out a v3 of the series,
incorporating the pieces commented on, and clarifying some of the
still confusing commit msgs.
--
.marius
^ permalink raw reply
* Re: [PATCH 03/14] Define SNPRINTF_SIZE_CORR=1 for Microsoft Visual C++
From: Marius Storm-Olsen @ 2009-08-22 11:32 UTC (permalink / raw)
Cc: git
In-Reply-To: <7vfxbkbyvw.fsf@alter.siamese.dyndns.org>
[Resending to list since gmail web interface was setup to do HTML
mails by default. Grrr
Get plain text, reply with plain text. Obvious, isn't it Google? Sorry guys..]
On Sat, Aug 22, 2009 at 12:11 AM, Junio C Hamano <gitster@pobox.com> wrote:
>
> Johannes Sixt <j6t@kdbg.org> writes:
>
> > Not quite. The parameter *is* the size of the buffer and vsnprintf does not
> > write beyond the buffer. However, it has the awkward behavior that if the
> > buffer is too short by exactly one byte...
>
> Thanks; I was fooled by the leading comment. How about ...
>
> compat/snprintf.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/compat/snprintf.c b/compat/snprintf.c
> index 6c0fb05..4d07087 100644
> --- a/compat/snprintf.c
> +++ b/compat/snprintf.c
> @@ -3,7 +3,8 @@
> /*
> * The size parameter specifies the available space, i.e. includes
> * the trailing NUL byte; but Windows's vsnprintf expects the
> - * number of characters to write without the trailing NUL.
> + * number of characters to write, and does not necessarily write the
> + * trailing NUL.
> */
> #ifndef SNPRINTF_SIZE_CORR
> #if defined(__MINGW32__) && defined(__GNUC__) && __GNUC__ < 4
Agreed. If you'd like, I'll squash that into the change, and make the
commit msg more clear.
--
.marius
^ permalink raw reply
* Re: [PATCH 03/14] Define SNPRINTF_SIZE_CORR=1 for Microsoft Visual C++
From: Marius Storm-Olsen @ 2009-08-22 11:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, Johannes.Schindelin, msysgit, git, lznuaa
In-Reply-To: <7vfxbkbyvw.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1134 bytes --]
On Sat, Aug 22, 2009 at 12:11 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Johannes Sixt <j6t@kdbg.org> writes:
>
> > Not quite. The parameter *is* the size of the buffer and vsnprintf does
> not
> > write beyond the buffer. However, it has the awkward behavior that if the
> > buffer is too short by exactly one byte...
>
> Thanks; I was fooled by the leading comment. How about ...
>
> compat/snprintf.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/compat/snprintf.c b/compat/snprintf.c
> index 6c0fb05..4d07087 100644
> --- a/compat/snprintf.c
> +++ b/compat/snprintf.c
> @@ -3,7 +3,8 @@
> /*
> * The size parameter specifies the available space, i.e. includes
> * the trailing NUL byte; but Windows's vsnprintf expects the
> - * number of characters to write without the trailing NUL.
> + * number of characters to write, and does not necessarily write the
> + * trailing NUL.
> */
> #ifndef SNPRINTF_SIZE_CORR
> #if defined(__MINGW32__) && defined(__GNUC__) && __GNUC__ < 4
>
Agreed. If you'd like, I'll squash that into the change, and make the commit
msg more clear.
--
.marius
[-- Attachment #2: Type: text/html, Size: 1676 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/9] sequencer: add "do_fast_forward()" to perform a fast forward
From: Christian Couder @ 2009-08-22 11:19 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Johannes Schindelin, Stephan Beyer, Daniel Barkalow,
Jakub Narebski
In-Reply-To: <7vab1s5mtc.fsf@alter.siamese.dyndns.org>
On Saturday 22 August 2009, Junio C Hamano wrote:
> Christian Couder <chriscool@tuxfamily.org> writes:
> > From: Stephan Beyer <s-beyer@gmx.net>
> >
> > This code is taken from the sequencer GSoC project:
> >
> > git://repo.or.cz/git/sbeyer.git
> >
> > (commit e7b8dab0c2a73ade92017a52bb1405ea1534ef20)
> >
> > but the messages have been changed to be the same as those
> > displayed by git-rebase--interactive.sh.
>
> Hmm, forgot to amend, or perhaps you sent out a wrong series?
Your comments on the v2 series were in a message replying to patch 5/9, so I
amended only 5/9 and after it, because I thought that you had already
reviewed those before 5/9 and they were ok.
> The log message does not explain:
>
> - why the patch adds a new static function that nobody calls;
> - what the new function is good for;
>
> which are the most important things in order to defend the change.
Yes, but the function contains only 5 lines of code and it mostly only calls
reset_almost_hard() that is already documented by a big comment before its
definition.
> "The messages have been changed to..." hints that the original commit by
> Stephan had different messages produced, perhaps so that it can be used
> in a different context. I hoped, in an ideal world, perhaps Stephan
> defended why the change was relevant to his project in some way, and
> because you are using it in a different context that needs modification
> of the message, perhaps Stephan's defense of his commit could be reworded
> to defend your change here.
>
> So I decided to take a look at the quoted commit to see if I can reword
> this mess.
>
> But the quoted commit e7b8dab0c2a73ade92017a52bb1405ea1534ef20 does not
> even seem to be a commit that corresponds to this change. It is a merge
> from upstream.
>
> commit e7b8dab0c2a73ade92017a52bb1405ea1534ef20
> Merge: 0c73ae7 99ddd24
> Author: Stephan Beyer <s-beyer@gmx.net>
> Date: Wed May 20 10:54:37 2009 +0200
>
> Merge branch 'junio/master' into seq-builtin-dev
>
> After this merge f79d4c8 "teach git-am to apply a patch to an
> unborn branch" has to be reimplemented in sequencer by allowing the
> "patch" insn on unborn branches.
> The related test in t/t4150-am.sh is set to test_expect_failure.
>
> Conflicts:
> git-am.sh
This is the commit at the point where I took the code of the function, not
the commit that introduce the function. This is because some functions like
pick() in patch 5/9 evolve a lot in the sequencer repo after they are
introduced.
> It does not help that the function that is crucial to the implemention of
> this new function, reset_almost_hard(), is not explained at all in the
> earlier commit in the previous series (36f692b (sequencer: add
> "reset_almost_hard()" and related functions, 2009-08-05).
>
> The log message to the commit does not even hint in what sense "almost"
> the function is, iow, in what situation it behaves exactly like "reset
> --hard", and in what other situation it doesn't, and more importantly why
> that distinction is there. I thought I asked these questions when the
> previous series was submitted, but I do not remember ever seeing
> satisfactory answers to them.
You asked questions about reset_almost_hard() and I added the big comment
before its definition, see:
http://git.kernel.org/?p=git/git.git;a=commitdiff;h=9d41fbd28f1ba3d07cd2e0f547521f9dced4cfd2
As you merged the series in pu, I thought that it was ok.
> I am afraid that the whole cc/sequencer-rebase-i series needs a serious
> reroll before it gets near 'next'.
Ok, I will reroll everything to try to improve commit messages.
> Before giving up, I'll quickly re-review how (un)readable the log of each
> commit is in the series. The following comments are mostly about the log
> messages, which are supposed to entice people to review the code, and
> more importantly, used as part of the release notes to summarize what the
> newly added toys are about. If they are horrible, the code has little
> chance to be even read, and I'll have a hard time merging the series up
> into a new release.
About the release notes, as "git sequencer--helper" is not for public use,
and as many functions like reset_almost_hard() are static, perhaps it would
be ok to have only something like:
(developers)
- parts of "git rebase -i" have been ported to C using "git
sequencer--helper"
- cherry-pick and revert functionality is available using new functions
declared in "pick.h"
> 6db6551 sequencer: add "builtin-sequencer--helper.c"
>
> Good.
>
> b512803 sequencer: add "make_patch" function to save a patch
>
> Passably okay, but the limitation that it always writes into a file with
> a fixed name "$SEQ_DIR/patch" should be noted in the log.
Ok.
> 0ccc92b sequencer: free memory used in "make_patch" function
>
> Should be squashed to the previous.
Will do.
> f121b06 rebase -i: use "git sequencer--helper --make-patch"
>
> Good.
>
> 36f692b sequencer: add "reset_almost_hard()" and related functions
>
> Horrible. See above.
>
> 9d41fbd sequencer: add comments about reset_almost_hard()
>
> Should be squashed to the previous---lift some text to justify the
> existence of the function in the commit log message.
Will do.
> Even though
> allow_dirty is referred to in the comment as affecting the behaviour, it
> is unclear who sets that global variable using what interface, making the
> reader suspect that maybe it should be a function parameter instead of a
> global (but the other parts of the helper may also look at allow_dirty
> and the internal implementation might be--I am just guessing--simpler
> this way, in which case _that_ should be explained and justified).
Will have a look.
> 022a9e7 sequencer: add "--reset-hard" option to "git sequencer--helper"
>
> This by itself is Okay, provided if 36f692b were made readable. Then you
> can expect the reader to know why reset_almost_hard() needs to be there,
> and you need an interface to that function. Until then, it is totally
> unclear why you need this, instead of using "reset --hard" itself.
Ok.
> ad28459 rebase -i: use "git sequencer--helper --reset-hard"
>
> Ditto.
>
> e4b3f0f sequencer: add "do_fast_forward()" to perform a fast forward
>
> See above.
>
> 1d88073 sequencer: add "--fast-forward" option to "git sequencer--helper"
>
> Okay.
>
> 6eff656 sequencer: let "git sequencer--helper" callers set "allow_dirty"
>
> Why? What for?
Daniel asked me to make it available so people interested can test. I will
state this in the commit message.
> 877ddc1 rebase -i: use "git sequencer--helper --fast-forward"
>
> It is unclear how this relates to the previous one, nor why it is more
> appropriate than "reset-hard" it replaces.
It is more appropriate because it makes the rebase -i shell code a little
bit shorter. I will add that to the commit message.
> ff312f0 revert: libify pick
>
> Almost good.
Will try to improve.
> ab67716 pick: libify "pick_help_msg()"
>
> Good.
>
> d871b0e sequencer: add "do_commit()" and related functions
>
> We can see from "git show" what static functions that are never called in
> this commit are added, but nobody explains why they are needed. For
> example, do_commit() may create a new commit object, but does not share
> the code with what "git commit" and/or "git commit-tree" do? If so, how?
> If not, why not?
Will have a look.
> ac5fc4d sequencer: add "--cherry-pick" option to "git sequencer--helper"
>
> Passably okay. I can see ff312f0 made about a half of cherry-pick
> accessible to the sequencer, and this patch uses it to finish the other
> half, although that is not explained in the log message. Also it is
> unclear why the resulting "libified" code does not share more
> infrastructure with "git cherry-pick" itself (and "git revert").
Will have a look.
> 664c7ab rebase -i: use "git sequencer--helper --cherry-pick"
>
> Passably okay, even though it is not quite convincing why using
> sequencer-helper's cherry-pick option makes it easier to later port the
> script, than keeping calls to cherry-pick.
Will have a look.
Thanks,
Christian.
^ permalink raw reply
* Re: [msysGit] Re: [PATCH 01/14] Fix non-constant array creation
From: Erik Faye-Lund @ 2009-08-22 10:35 UTC (permalink / raw)
To: Johan 't Hart
Cc: Janos Laube, Marius Storm-Olsen, Johannes.Schindelin, msysgit,
git, lznuaa
In-Reply-To: <4A8EFE29.6010706@gmail.com>
On Fri, Aug 21, 2009 at 10:06 PM, Johan 't Hart<johanthart@gmail.com> wrote:
> alloca() throws an exception when out of stack memory. But what would the
> dynamically alloced array do when it runs out of memory? (Supposing that
> those arrays are also created on the stack, which I don't know...) Is that
> realy more complicated?
You get a run-time error. Or rather, you get a run-time error if
you're out of address space. If you go out of memory, swapping
mechanisms are used. And in turn, if the swapping mechanisms fail,
you'll get a run-time error AFAIK.
--
Erik "kusma" Faye-Lund
kusmabite@gmail.com
(+47) 986 59 656
^ permalink raw reply
* Re: [PATCH JGIT] Ensure created test repositories use canonical paths
From: Robin Rosenberg @ 2009-08-22 10:15 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Shawn O. Pearce, git
In-Reply-To: <2c6b72b30908212032t39a4896x3308148c44692a80@mail.gmail.com>
lördag 22 augusti 2009 05:32:59 skrev Jonas Fonseca <fonseca@diku.dk>:
> [With correct CC list. Sorry for the resend Robin]
>
> On Thu, Aug 20, 2009 at 18:35, Robin
> Rosenberg<robin.rosenberg.lists@dewire.com> wrote:
> > onsdag 19 augusti 2009 15:18:11 skrev Jonas Fonseca <fonseca@diku.dk>:
> >> Fixes breakage in the RepositoryCacheTest when running tests using:
> >>
> >> mvn -f ./jgit-maven/jgit/pom.xml test
> >> [...]
> >> @@ -217,7 +217,7 @@ public void setUp() throws Exception {
> >> trash = new File(trashParent,"trash"+System.currentTimeMillis()+"."+(testcount++));
> >> - trash_git = new File(trash, ".git");
> >> + trash_git = new File(trash, ".git").getCanonicalFile();
> >> @@ -307,7 +307,7 @@ protected Repository createNewEmptyRepo() throws IOException {
> >> protected Repository createNewEmptyRepo(boolean bare) throws IOException {
> >> final File newTestRepo = new File(trashParent, "new"
> >> + System.currentTimeMillis() + "." + (testcount++)
> >> - + (bare ? "" : "/") + ".git");
> >> + + (bare ? "" : "/") + ".git").getCanonicalFile();
> >
> > We use getCanonicalFile here and Repository.gitDir is initialized with getAbsoluteDir.
>
> BTW, a simpler fix would be to initialize trashParent to a canonical
> path, which might be less intrusive.
>
> > Does this work on all platforms?
>
> I have only tested on Linux.
>
> > Seems linux normalized things when you do things like, but I'm not sure that happens everywhere.
>
> If you think it is a problem, let's drop the patch. It just seemed
> like a simple way to increase robustness.
Just a hunch, can't prove it so I'll accept the patch.
-- robin
^ permalink raw reply
* Re: Continue git clone after interruption
From: Nicolas Pitre @ 2009-08-22 8:13 UTC (permalink / raw)
To: Sam Vilain
Cc: Jakub Narebski, Tomasz Kontusz, git, Johannes Schindelin,
Scott Chacon
In-Reply-To: <1250920259.3644.11.camel@maia.lan>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 5187 bytes --]
On Sat, 22 Aug 2009, Sam Vilain wrote:
> On Fri, 2009-08-21 at 23:37 -0400, Nicolas Pitre wrote:
> > > What did you think about the bundle slicing stuff?
> >
> > If I didn't comment on it already, then I probably missed it and have no
> > idea.
>
> I really tire of repeating myself for your sole benefit. Please show
> some consideration for other people in the conversation by trying to
> listen. Thank-you.
I'm sorry but I have way too many emails to consider reading. This is
like ethernet: not a reliable transport, and lost packets means you have
to retransmit. Cut and paste does wonders, or even a link to previous
post.
> > > I think the first step here would be to allow thin pack generation to
> > > accept a bounded range of commits, any of the objects within which may
> > > be used as delta base candidates. That way, these "top down" thin packs
> > > can be generated. Currently of course it just uses the --not and makes
> > > "bottom up" thin packs.
> >
> > The pack is still almost top-down. It's only the missing delta base
> > that are in the other direction, refering to objects you have locally
> > and therefore older.
>
> Ok, but right now there's no way to specify that you want a thin pack,
> where the allowable base objects are *newer* than the commit range you
> wish to include.
Sure you can. Try this:
( echo "-$(git rev-parse v1.6.4)"; \
git rev-list --objects v1.6.2..v1.6.3 ) | \
git pack-objects --progress --stdout > foo.pack
That'll give you a thin pack for the _new_ objects that _appeared_
between v1.6.2 and v1.6.3, but which external delta base objects are
found in v1.6.4.
If you want _all_ the objects that are referenced from commits between
v1.6.2 and v1.6.3 then you just have to list them all for v1.6.2 in
addition to the rest:
( echo "-$(git rev-parse v1.6.4)"; \
git rev-list --objects v1.6.2..v1.6.3; \
git ls-tree -t -r v1.6.2 | cut -d' ' -f 3- | tr "\t" " "; ) | \
git pack-objects --progress --stdout > foo.pack
> What I said in my other e-mail where I showed how well it works taking
> a given bundle, and slicing it into a series of thin packs, was that it
> seems to add a bit of extra size to the resultant packs - best I got for
> slicing up the entire git.git run was about 20%. If this can be
> reduced to under 10% (say), then sending bundle slices would be quite
> reasonable by default for the benefit of making large fetches
> restartable, or even spreadable across multiple mirrors.
In theory you could have about no overhead. That all depends how you
slice the pack. If you want a pack to contain a fixed number of commits
(such that all objects introduced by a given commit are all in the same
pack) then you are of course putting a constraint on the possible delta
matches and compression result might be suboptimal. In comparison, with
a single big pack a given blob can delta against a blob from a
completely distant commit in the history graph if that provides a better
compression ratio.
If you slice your pack according to a size treshold, then you might
consider the --max-pack-size= argument to pack-objects. This currently
doesn't produce thin pack as delta objects whose base are stored in a
different pack than their base because of a pack split are simply not
stored as delta. Only a few line of code would need to be modified in
order to store those deltas nevertheless and turn those packs into thin
packs, preserving the optimal delta match. Of course cross pack delta
reference have to be REF_DELTA objects with headers about 16 to 17 bytes
larger than those of OFS_DELTA objects, so you will still have some
overhead.
> The object sorting stuff is something of a distraction; it's required
> for download spreading but not for the case at hand now.
Well, the idea of spreading small packs has its drawbacks. You still
might need to get a sizeable portion of them to get at least one usable
commit. And ideally you want the top commit in priority, which pretty
much impose an ordering on the packs you're likely to want first, unlike
with BitTorrent where you don't care as you normally want all
the blocks anyway.
If the goal is to make for faster downloads, then you could simply make
a bundle, copy it on multiple server, and slice your download across
those servers. This has the disadvantage of being static data that
doubles the disk (and cache) usage. That doesn't work too well with
shallow clones though.
If you were envisioning _clients_ à la BitTorrent putting up pack slices
instead, then in that case the slices have to be well defined entities,
like packs containing objects for known range of commits, but then we're
back to the delta inefficiency I mentioned above. And again this might
work only if a lot of people are interested in the same repository at
the same time, and of course most people have no big insentive to "seed"
once they got their copy. So I'm not sure if that might work that well
in practice.
This certainly still looks like a pretty cool project. But it is not
all the cool stuff that works well in real conditions I'm afraid. Just
my opinion of course.
Nicolas
^ 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