* Re: Corrupted (?) commit 6e6db85e confusing gitk
From: Linus Torvalds @ 2007-12-02 21:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brian Downing, Steffen Prohaska, Git Mailing List
In-Reply-To: <7vmyssvn55.fsf@gitster.siamese.dyndns.org>
On Sun, 2 Dec 2007, Junio C Hamano wrote:
>
> The next issue would be to find who could pass an empty GIT_AUTHOR_DATE
> without noticing...
In the meantime, here's a not-very-well-tested patch to fsck to at least
notice this.
Of course, in the name of containment it would probably be even better if
parse_commit() did it, because then people would be unable to pull from
such a corrupt repository! But this would seem to be at least a slight
step in the right direction.
Linus
---
builtin-fsck.c | 57 ++++++++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 55 insertions(+), 2 deletions(-)
diff --git a/builtin-fsck.c b/builtin-fsck.c
index e4874f6..309212c 100644
--- a/builtin-fsck.c
+++ b/builtin-fsck.c
@@ -351,8 +351,48 @@ static int fsck_tree(struct tree *item)
return retval;
}
+static int parse_commit_line(struct commit *commit, const char *expect, const char *buffer)
+{
+ char *end;
+ const char *p;
+ int len = strlen(expect);
+ int saw_lt = 0;
+
+ if (memcmp(buffer, expect, len))
+ goto bad;
+ p = (char *)buffer + len;
+ if (*p != ' ')
+ goto bad;
+ while (*++p != '>') {
+ if (*p == '<')
+ saw_lt++;
+ if (!*p)
+ goto bad;
+ }
+ if (saw_lt != 1)
+ goto bad;
+ if (*++p != ' ')
+ goto bad;
+
+ /* Date in seconds since the epoch (UTC) */
+ if (strtoul(p, &end, 10) == ULONG_MAX)
+ goto bad;
+ if (*end++ != ' ')
+ goto bad;
+
+ /* TZ that date was done in */
+ if (strtoul(end, &end, 10) == ULONG_MAX)
+ goto bad;
+ if (*end++ != '\n')
+ goto bad;
+ return end - buffer;
+bad:
+ return objerror(&commit->object, "invalid format - missing or corrupt '%s'", expect);
+}
+
static int fsck_commit(struct commit *commit)
{
+ int len;
char *buffer = commit->buffer;
unsigned char tree_sha1[20], sha1[20];
@@ -370,8 +410,21 @@ static int fsck_commit(struct commit *commit)
return objerror(&commit->object, "invalid 'parent' line format - bad sha1");
buffer += 48;
}
- if (memcmp(buffer, "author ", 7))
- return objerror(&commit->object, "invalid format - expected 'author' line");
+
+ /*
+ * We check the author/committer lines for completeness.
+ * But errors here aren't fatal to the rest of the parsing.
+ */
+ len = parse_commit_line(commit, "author", buffer);
+ if (len >= 0) {
+ buffer += len;
+ len = parse_commit_line(commit, "committer", buffer);
+ if (len >= 0) {
+ buffer += len;
+ if (*buffer != '\n')
+ objerror(&commit->object, "invalid format - missing or corrupt end-of-headers");
+ }
+ }
free(commit->buffer);
commit->buffer = NULL;
if (!commit->tree)
^ permalink raw reply related
* Re: Corrupted (?) commit 6e6db85e confusing gitk
From: Johannes Schindelin @ 2007-12-02 21:34 UTC (permalink / raw)
To: Brian Downing; +Cc: Junio C Hamano, Steffen Prohaska, Git Mailing List
In-Reply-To: <20071202193918.GQ6212@lavos.net>
Hi,
On Sun, 2 Dec 2007, Brian Downing wrote:
> On Sun, Dec 02, 2007 at 10:53:33AM -0800, Junio C Hamano wrote:
> > Yeah, I was wondering what that commit that records the change older
> > than git or myself come to life ;-)
> >
> > I did rewrite the commit a few times, and it was some interaction
> > between the built-in commit series, git-rebase -i and git-am, but I do
> > not have the details, sorry.
>
> It looks like the "guilty" commit that allowed this behavior was:
>
> commit 13208572fbe8838fd8835548d7502202d1f7b21d
> Author: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> Date: Sun Nov 11 17:35:58 2007 +0000
>
> builtin-commit: fix --signoff
>
> The Signed-off-by: line contained a spurious timestamp. The reason was
> a call to git_committer_info(1), which automatically added the
> timestamp.
>
> Instead, fmt_ident() was taught to interpret an empty string for the
> date (as opposed to NULL, which still triggers the default behavior)
> as "do not bother with the timestamp", and builtin-commit.c uses it.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
>
> With the above, something like:
>
> echo msg | GIT_AUTHOR_DATE='' git commit-tree sha1
Darn. But when can "GIT_AUTHOR_DATE" be set to the empty string? I mean,
I understand unset'ing it. But setting it to ""?
Ciao,
Dscho
^ permalink raw reply
* Fix --signoff in builtin-commit differently.
From: Junio C Hamano @ 2007-12-02 21:43 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Brian Downing, Steffen Prohaska, Git Mailing List
In-Reply-To: <7vmyssvn55.fsf@gitster.siamese.dyndns.org>
Introduce fmt_name() specifically meant for formatting the name and
email pair, to add signed-off-by value. This reverts parts of
13208572fbe8838fd8835548d7502202d1f7b21d (builtin-commit: fix --signoff)
so that an empty datestamp string given to fmt_ident() by mistake will
error out as before.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Junio C Hamano <gitster@pobox.com> writes:
>> Personally, I think if the date_str is not NULL, it should die() on
>> anything that can't successfully be parsed as a date, rather than simply
>> falling back to the current time. But maybe that's a bit extreme.
>
> Yeah, that change does look like a hack now we look at it again. It
> would have been much cleaner to make the caller accept the default
> behaviour of fmt_ident() and strip out the part it does not want from
> the result. That way, the damage would have been much contained.
>
> The next issue would be to find who could pass an empty GIT_AUTHOR_DATE
> without noticing...
Perhaps like this...
builtin-commit.c | 6 ++----
cache.h | 1 +
ident.c | 34 ++++++++++++++++++++++++----------
3 files changed, 27 insertions(+), 14 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 96cb544..2319cc1 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -346,11 +346,9 @@ static int prepare_log_message(const char *index_file, const char *prefix)
strbuf_init(&sob, 0);
strbuf_addstr(&sob, sign_off_header);
- strbuf_addstr(&sob, fmt_ident(getenv("GIT_COMMITTER_NAME"),
- getenv("GIT_COMMITTER_EMAIL"),
- "", 1));
+ strbuf_addstr(&sob, fmt_name(getenv("GIT_COMMITTER_NAME"),
+ getenv("GIT_COMMITTER_EMAIL")));
strbuf_addch(&sob, '\n');
-
for (i = sb.len - 1; i > 0 && sb.buf[i - 1] != '\n'; i--)
; /* do nothing */
if (prefixcmp(sb.buf + i, sob.buf)) {
diff --git a/cache.h b/cache.h
index cf0bdc6..43cfebb 100644
--- a/cache.h
+++ b/cache.h
@@ -444,6 +444,7 @@ enum date_mode parse_date_format(const char *format);
extern const char *git_author_info(int);
extern const char *git_committer_info(int);
extern const char *fmt_ident(const char *name, const char *email, const char *date_str, int);
+extern const char *fmt_name(const char *name, const char *email);
struct checkout {
const char *base_dir;
diff --git a/ident.c b/ident.c
index 5be7533..021d79b 100644
--- a/ident.c
+++ b/ident.c
@@ -192,12 +192,14 @@ static const char *env_hint =
"Omit --global to set the identity only in this repository.\n"
"\n";
-const char *fmt_ident(const char *name, const char *email,
- const char *date_str, int error_on_no_name)
+static const char *fmt_ident_1(const char *name, const char *email,
+ const char *date_str, int flag)
{
static char buffer[1000];
char date[50];
int i;
+ int error_on_no_name = !!(flag & 01);
+ int name_addr_only = !!(flag & 02);
setup_ident();
if (!name)
@@ -224,24 +226,36 @@ const char *fmt_ident(const char *name, const char *email,
}
strcpy(date, git_default_date);
- if (date_str) {
- if (*date_str)
- parse_date(date_str, date, sizeof(date));
- else
- date[0] = '\0';
- }
+ if (!name_addr_only && date_str)
+ parse_date(date_str, date, sizeof(date));
i = copy(buffer, sizeof(buffer), 0, name);
i = add_raw(buffer, sizeof(buffer), i, " <");
i = copy(buffer, sizeof(buffer), i, email);
- i = add_raw(buffer, sizeof(buffer), i, date[0] ? "> " : ">");
- i = copy(buffer, sizeof(buffer), i, date);
+ if (!name_addr_only) {
+ i = add_raw(buffer, sizeof(buffer), i, "> ");
+ i = copy(buffer, sizeof(buffer), i, date);
+ } else {
+ i = add_raw(buffer, sizeof(buffer), i, ">");
+ }
if (i >= sizeof(buffer))
die("Impossibly long personal identifier");
buffer[i] = 0;
return buffer;
}
+const char *fmt_ident(const char *name, const char *email,
+ const char *date_str, int error_on_no_name)
+{
+ int flag = (error_on_no_name ? 01 : 0);
+ return fmt_ident_1(name, email, date_str, flag);
+}
+
+const char *fmt_name(const char *name, const char *email)
+{
+ return fmt_ident_1(name, email, NULL, 03);
+}
+
const char *git_author_info(int error_on_no_name)
{
return fmt_ident(getenv("GIT_AUTHOR_NAME"),
^ permalink raw reply related
* Re: Corrupted (?) commit 6e6db85e confusing gitk
From: Junio C Hamano @ 2007-12-02 21:47 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Brian Downing, Steffen Prohaska, Git Mailing List
In-Reply-To: <alpine.LFD.0.9999.0712021322580.8458@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Sun, 2 Dec 2007, Junio C Hamano wrote:
>>
>> The next issue would be to find who could pass an empty GIT_AUTHOR_DATE
>> without noticing...
>
> In the meantime, here's a not-very-well-tested patch to fsck to at least
> notice this.
Thanks.
I recall that the very initial git did not use the current format for
timestamp but ctime() return value, and this will also notice them (and
convert-objects will be there for us).
^ permalink raw reply
* Re: Corrupted (?) commit 6e6db85e confusing gitk
From: Linus Torvalds @ 2007-12-02 21:49 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Brian Downing, Junio C Hamano, Steffen Prohaska, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0712022132060.27959@racer.site>
On Sun, 2 Dec 2007, Johannes Schindelin wrote:
>
> Darn. But when can "GIT_AUTHOR_DATE" be set to the empty string? I mean,
> I understand unset'ing it. But setting it to ""?
Well, regardless, I think we should make sure that git-commit-tree never
writes out an invalid commit - no matter *how* insane input it gets.
Making it complain loudly (with a 'die("Oh, no, you don't!")') would be a
good idea.
Linus
^ permalink raw reply
* Re: [PATCH v4] Allow update hooks to update refs on their own.
From: Junio C Hamano @ 2007-12-02 21:56 UTC (permalink / raw)
To: Steven Grimm; +Cc: git
In-Reply-To: <20071202212224.GA22117@midwinter.com>
Steven Grimm <koreth@midwinter.com> writes:
> +The hook may optionally choose to update the ref on its own, e.g.,
> +if it needs to modify incoming revisions in some way. If it updates
> +the ref, it should exit with a status of 100. The hook should exit
> +with a status between 1 and 99 if it wants to disallow updating the
> +named ref. Otherwise it should exit with zero, and the ref will be
> +updated automatically.
This makes one wonder what happens if it returns 101, iow if there is
difference between returning 99 and 101, and if so why.
> +Remote Tracking Refs
> +--------------------
> +
> +After successfully sending a pack to the remote, 'git-send-pack'
> +updates the corresponding remote tracking ref in the local repository
> +to point to the same commit as was just sent to the remote side. In
> +most cases this eliminates the need to subsequently fetch from the
> +remote repository since there would be nothing new to fetch.
Micronit. The above is all "if exists". Not everybody pushes to
somewhere he uses tracking with.
> @@ -70,8 +73,11 @@ static struct command *commands;
> static const char pre_receive_hook[] = "hooks/pre-receive";
> static const char post_receive_hook[] = "hooks/post-receive";
>
> -static int hook_status(int code, const char *hook_name)
> +static int hook_status(int code, const char *hook_name, int ok_start)
> {
> + if (ok_start && -code >= ok_start)
> + return -code;
> +
I've always been puzzled by this "ok_start" parameter from the very
beginning edition of your patch. It is not like "if this is true, then
it is ok to run the hook but otherwise do not run". In layman's terms,
what does the parameter mean?
Maybe the variable is misnamed and not expressing the concept well
enough. Maybe the concept itself is muddy and hard to understand. I
cannot tell.
^ permalink raw reply
* v1.5.4 plans
From: Junio C Hamano @ 2007-12-02 22:04 UTC (permalink / raw)
To: git
Please do not take this as the final decision made by the Emperor, whose
subjects now must follow. This is a sanity-check to see if everybody is
on the same page.
I am not the Emperor anyway ;-)
Deprecation and Removal
-----------------------
* We have already removed svnimport without giving a deprecation notice
in the release notes of the previous feature release, which was bad.
Maybe the users will forgive us. Maybe not.
* As discussed on the list, v1.5.4 will ship with the dashed form of
commands (e.g. "git-commit") on users' PATH by default. However we
will move them outside the normal PATH (exact location needs to be
decided by checking FHS first, something like /usr/libexec/git-core)
in v1.5.5 so the release notes to v1.5.4 will declare deprecation
(see the top of Documentation/RelNotes-1.5.4.txt). We might want to
keep copies of dashed form Porcelains in /usr/bin but that discussion
is towards v1.5.5 (post v1.5.4, not now).
* We also will give deprecation warning for the following features and
commands in the release notes to v1.5.4, and remove them in v1.5.5:
- lost-found (use fsck --lost-found);
- post-update hook (use post-receive hook);
- peek-remote (use ls-remote)
Topics not in 'master' yet but should be in v1.5.4
--------------------------------------------------
I think the following should go in, along with what we already have in
'master':
* git-commit in C (Kristian and others)
* git-add --patch (Wincent)
* git-prune --expire (Dscho)
* git-add --interactive coloring (Dan Zwell)
* whitespace error classes in diff and patch, using gitattributes (Bruce and me)
* cvsserver runs post-receive (Michael Witten)
* git-rebase -i gives chance to rerere (Dscho)
* git-rebase gives more appropriate help text (Wincent)
* make refspec matching logic in git-push and git-fetch saner (Steffen Prohaska)
* work-tree related minor fixes (Nguyen and Dscho)
* allow update hook to munge commit (Steven Grimm)
I'd like to explicitly exclude topics about the following, although I
think there might be worthwhile ones among them to think about in the
longer term:
* removing dashed form from the filesystem
* teaching diff family about fileglob pathspecs
* making it possible to omit leading paths from diff family output when
run from a subdirectory
^ permalink raw reply
* Re: Corrupted (?) commit 6e6db85e confusing gitk
From: Junio C Hamano @ 2007-12-02 22:14 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Brian Downing, Steffen Prohaska, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0712022132060.27959@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> With the above, something like:
>>
>> echo msg | GIT_AUTHOR_DATE='' git commit-tree sha1
>
> Darn. But when can "GIT_AUTHOR_DATE" be set to the empty string? I mean,
> I understand unset'ing it. But setting it to ""?
Maybe something like this would catch such a breakage earlier, but with
the re-fix for --signoff I just sent to make fmt_ident() safer, I think
this patch would fall into belt-and-suspender category.
---
git-am.sh | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index 4126f0e..bab6f68 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -307,9 +307,11 @@ do
GIT_AUTHOR_EMAIL="$(sed -n '/^Email/ s/Email: //p' "$dotest/info")"
GIT_AUTHOR_DATE="$(sed -n '/^Date/ s/Date: //p' "$dotest/info")"
- if test -z "$GIT_AUTHOR_EMAIL"
+ if test -z "$GIT_AUTHOR_EMAIL" ||
+ test -z "$GIT_AUTHOR_NAME" ||
+ test -z "$GIT_AUTHOR_DATE"
then
- echo "Patch does not have a valid e-mail address."
+ echo "Patch does not have a valid authorship information."
stop_here $this
fi
^ permalink raw reply related
* Re: Fix --signoff in builtin-commit differently.
From: Johannes Schindelin @ 2007-12-02 22:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brian Downing, Steffen Prohaska, Git Mailing List
In-Reply-To: <7v63zgvkl5.fsf@gitster.siamese.dyndns.org>
Hi,
On Sun, 2 Dec 2007, Junio C Hamano wrote:
> Introduce fmt_name() specifically meant for formatting the name and
> email pair, to add signed-off-by value. This reverts parts of
> 13208572fbe8838fd8835548d7502202d1f7b21d (builtin-commit: fix --signoff)
> so that an empty datestamp string given to fmt_ident() by mistake will
> error out as before.
>From a quick glance, looks good to me.
Sorry for the breakage,
Dscho
^ permalink raw reply
* Re: v1.5.4 plans
From: Jakub Narebski @ 2007-12-02 22:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk5nwu51x.fsf@gitster.siamese.dyndns.org>
Does this mean we should be entering feature freeze?
Or at least feature freeze for 'master'?
--
Jakub Narebski
^ permalink raw reply
* Re: Corrupted (?) commit 6e6db85e confusing gitk
From: Junio C Hamano @ 2007-12-02 22:36 UTC (permalink / raw)
To: Linus Torvalds
Cc: Johannes Schindelin, Brian Downing, Steffen Prohaska,
Git Mailing List
In-Reply-To: <alpine.LFD.0.9999.0712021348020.8458@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Sun, 2 Dec 2007, Johannes Schindelin wrote:
>>
>> Darn. But when can "GIT_AUTHOR_DATE" be set to the empty string? I mean,
>> I understand unset'ing it. But setting it to ""?
>
> Well, regardless, I think we should make sure that git-commit-tree never
> writes out an invalid commit - no matter *how* insane input it gets.
> Making it complain loudly (with a 'die("Oh, no, you don't!")') would be a
> good idea.
FWIW, fmt_ident() records the current time (before the kh/commit series,
and after the fix I sent on top of kh/commit series), which may be a
reasonable alternative.
^ permalink raw reply
* Re: v1.5.4 plans
From: Junio C Hamano @ 2007-12-02 22:41 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m33aukwwtx.fsf@roke.D-201>
Jakub Narebski <jnareb@gmail.com> writes:
> Does this mean we should be entering feature freeze?
> Or at least feature freeze for 'master'?
I said "these are not in master but should be before v1.5.4", so master
is not frozen yet in that sense, but on the other hand, I want to stop
taking anything other than I explicitly listed to 'master' from now on.
So please take it as a "rfc feature freeze notice".
^ permalink raw reply
* Re: Corrupted (?) commit 6e6db85e confusing gitk
From: Linus Torvalds @ 2007-12-02 22:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brian Downing, Steffen Prohaska, Git Mailing List
In-Reply-To: <7v1wa4vkev.fsf@gitster.siamese.dyndns.org>
On Sun, 2 Dec 2007, Junio C Hamano wrote:
>
> I recall that the very initial git did not use the current format for
> timestamp but ctime() return value
Yes, but..
> and this will also notice them (and convert-objects will be there for
> us).
.. I don't think we have actually accepted the ctime-string format since
switchng over, so no existing git repositories will have them. The commit
date parsing just does a "strtoul()" in parse_commit_date().
So I wouldn't expect convert-objects to be needed - or rather, it was
needed 2.5 _years_ ago, and we've not supported those early broken formats
since, afaik.
Linus
^ permalink raw reply
* Re: Corrupted (?) commit 6e6db85e confusing gitk
From: Michael Gebetsroither @ 2007-12-02 22:59 UTC (permalink / raw)
To: git
In-Reply-To: <7vmyssvn55.fsf@gitster.siamese.dyndns.org>
* Junio C Hamano <gitster@pobox.com> wrote:
> Yeah, that change does look like a hack now we look at it again. It
> would have been much cleaner to make the caller accept the default
> behaviour of fmt_ident() and strip out the part it does not want from
> the result. That way, the damage would have been much contained.
Last hg2git from repo.or.cz does it (it uses git-fast-import).
Just tried to convert lastes mercurial repos to git and the resulting
git repos can't be displayed with gitk.
git fsck --full gives many "bad commit date in xxxx"
% git cat-file commit f7900d59930d796c4739452cf68ca9c08a921b5d | sed
% '/^$/,//d'
tree 4fb3636148433dcd368fc2dfa20247cb281e2ff8
parent 6ea0491f4ebb13003d15c6fc478d92cbe1201902
author Mathieu Clabaut <mathieu.clabaut@gmail.com> <"Mathieu Clabaut
<mathieu.clabaut@gmail.com>"> 1153937514 +0200
committer Mathieu Clabaut <mathieu.clabaut@gmail.com> <"Mathieu Clabaut
<mathieu.clabaut@gmail.com>"> 1153937514 +0200
But the new hg2git is _amazingly_ fast, converts the whole mercurial
repos got git in just 1min :).
cu,
michael
--
It's already too late!
^ permalink raw reply
* Re: Corrupted (?) commit 6e6db85e confusing gitk
From: Junio C Hamano @ 2007-12-02 23:05 UTC (permalink / raw)
To: Michael Gebetsroither; +Cc: git
In-Reply-To: <fivdfu$smr$1@ger.gmane.org>
Michael Gebetsroither <gebi@sbox.tugraz.at> writes:
> Last hg2git from repo.or.cz does it (it uses git-fast-import).
>
> Just tried to convert lastes mercurial repos to git and the resulting
> git repos can't be displayed with gitk.
>
> author Mathieu Clabaut <mathieu.clabaut@gmail.com> <"Mathieu Clabaut
> <mathieu.clabaut@gmail.com>"> 1153937514 +0200
> committer Mathieu Clabaut <mathieu.clabaut@gmail.com> <"Mathieu Clabaut
> <mathieu.clabaut@gmail.com>"> 1153937514 +0200
That's totally broken author/committer information from a broken
hg2git, with what appears to be correct timestamps.
^ permalink raw reply
* Re: make test failure with latest master
From: A Large Angry SCM @ 2007-12-02 23:19 UTC (permalink / raw)
To: Jeff King; +Cc: git, gitster
In-Reply-To: <20071202163426.GA29781@coredump.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 786 bytes --]
Jeff King wrote:
> On Sun, Dec 02, 2007 at 07:29:50AM -0500, A Large Angry SCM wrote:
>
>> With the latest master, 2221a6757161af1905925c405aded9ff470f70d5, "make
>> test" now fails; last successful "make test" was mid-week sometime with
>> master d25430. This is on a laptop running Suse 9.3.
>>
>> *** t9600-cvsimport.sh ***
>> * ok 1: setup cvsroot
>> * ok 2: setup a cvs module
>> * FAIL 3: import a trivial module
>>
>>
>> git cvsimport -a -z 0 -C module-git module &&
>> git diff module-cvs/o_fortuna module-git/o_fortuna
>
> Can you please try ./t9600 --verbose? Presumably cvsimport is generating
> some kind of error message to tell us what's going on.
Attached is the output of
./t9600-cvsimport.sh --verbose >/tmp/9600_out.txt 2>&1
[-- Attachment #2: 9600_out.txt --]
[-- Type: text/plain, Size: 5602 bytes --]
* expecting success: cvs init
* ok 1: setup cvsroot
* expecting success:
mkdir $CVSROOT/module &&
cvs co -d module-cvs module &&
cd module-cvs &&
cat <<EOF >o_fortuna &&
O Fortuna
velut luna
statu variabilis,
semper crescis
aut decrescis;
vita detestabilis
nunc obdurat
et tunc curat
ludo mentis aciem,
egestatem,
potestatem
dissolvit ut glaciem.
EOF
cvs add o_fortuna &&
cat <<EOF >message &&
add "O Fortuna" lyrics
These public domain lyrics make an excellent sample text.
EOF
cvs commit -F message &&
cd ..
cvs checkout: Updating module-cvs
cvs add: scheduling file `o_fortuna' for addition
cvs add: use `cvs commit' to add this file permanently
cvs commit: Examining .
/home/internet/GIT/git/t/trash/cvsroot/module/o_fortuna,v <-- o_fortuna
initial revision: 1.1
* ok 2: setup a cvs module
* expecting success:
git cvsimport -a -z 0 -C module-git module &&
git diff module-cvs/o_fortuna module-git/o_fortuna
Initialized empty Git repository in /home/internet/GIT/git/t/trash/module-git/.git/
bad usage: invalid argument -A
Usage: cvsps [-h] [-x] [-u] [-z <fuzz>] [-g] [-s <range>[,<range>]]
[-a <author>] [-f <file>] [-d <date1> [-d <date2>]]
[-b <branch>] [-l <regex>] [-r <tag> [-r <tag>]]
[-p <directory>] [-v] [-t] [--norc] [--summary-first]
[--test-log <captured cvs log file>] [--bkcvs]
[--no-rlog] [--diff-opts <option string>] [--cvs-direct]
[--debuglvl <bitmask>] [-Z <compression>] [--root <cvsroot>]
[<repository>] [-q]
Where:
-h display this informative message
-x ignore (and rebuild) cvsps.cache file
-u update cvsps.cache file
-z <fuzz> set the timestamp fuzz factor for identifying patch sets
-g generate diffs of the selected patch sets
-s <patch set>[-[<patch set>]][,<patch set>...] restrict patch sets by id
-a <author> restrict output to patch sets created by author
-f <file> restrict output to patch sets involving file
-d <date1> -d <date2> if just one date specified, show
revisions newer than date1. If two dates specified,
show revisions between two dates.
-b <branch> restrict output to patch sets affecting history of branch
-l <regex> restrict output to patch sets matching <regex> in log message
-r <tag1> -r <tag2> if just one tag specified, show
revisions since tag1. If two tags specified, show
revisions between the two tags.
-p <directory> output patch sets to individual files in <directory>
-v show very verbose parsing messages
-t show some brief memory usage statistics
--norc when invoking cvs, ignore the .cvsrc file
--summary-first when multiple patch sets are shown, put all summaries first
--test-log <captured cvs log> supply a captured cvs log for testing
--diff-opts <option string> supply special set of options to diff
--bkcvs special hack for parsing the BK -> CVS log format
--no-rlog disable rlog (it's faulty in some setups)
--cvs-direct (--no-cvs-direct) enable (disable) built-in cvs client code
--debuglvl <bitmask> enable various debug channels.
-Z <compression> A value 1-9 which specifies amount of compression
--root <cvsroot> specify cvsroot. overrides env. and working directory
-q be quiet about warnings
<repository> apply cvsps to repository. overrides working directory
cvsps version 2.0rc1
fatal: refs/heads/origin: not a valid SHA1
fatal: master: not a valid SHA1
warning: You appear to be on a branch yet to be born.
warning: Forcing checkout of HEAD.
fatal: just how do you expect me to merge 0 trees?
checkout failed: 256
* FAIL 3: import a trivial module
git cvsimport -a -z 0 -C module-git module &&
git diff module-cvs/o_fortuna module-git/o_fortuna
* expecting success: cd module-git && git gc && cd ..
Nothing new to pack.
* ok 4: pack refs
* expecting success:
cd module-cvs &&
cat <<EOF >o_fortuna &&
O Fortune,
like the moon
you are changeable,
ever waxing
and waning;
hateful life
first oppresses
and then soothes
as fancy takes it;
poverty
and power
it melts them like ice.
EOF
cat <<EOF >message &&
translate to English
My Latin is terrible.
EOF
cvs commit -F message &&
cd ..
cvs commit: Examining .
/home/internet/GIT/git/t/trash/cvsroot/module/o_fortuna,v <-- o_fortuna
new revision: 1.2; previous revision: 1.1
* ok 5: update cvs module
* expecting success:
cd module-git &&
git cvsimport -a -z 0 module &&
git merge origin &&
cd .. &&
git diff module-cvs/o_fortuna module-git/o_fortuna
fatal: Needed a single revision
Branch 'origin' does not exist.
Either use the correct '-o branch' option,
or import to a new repository.
* FAIL 6: update git module
cd module-git &&
git cvsimport -a -z 0 module &&
git merge origin &&
cd .. &&
git diff module-cvs/o_fortuna module-git/o_fortuna
* expecting success:
cd module-cvs &&
echo 1 >tick &&
cvs add tick &&
cvs commit -m 1
cd ..
./test-lib.sh: line 182: cd: module-cvs: No such file or directory
* ok 7: update cvs module
* expecting success:
cd module-git &&
git config cvsimport.module module &&
git cvsimport -a -z0 &&
git merge origin &&
cd .. &&
git diff module-cvs/tick module-git/tick
fatal: Needed a single revision
Branch 'origin' does not exist.
Either use the correct '-o branch' option,
or import to a new repository.
* FAIL 8: cvsimport.module config works
cd module-git &&
git config cvsimport.module module &&
git cvsimport -a -z0 &&
git merge origin &&
cd .. &&
git diff module-cvs/tick module-git/tick
* failed 3 among 8 test(s)
^ permalink raw reply
* [PATCH] gitweb: Update and improve gitweb/README file
From: Jakub Narebski @ 2007-12-02 23:22 UTC (permalink / raw)
To: git; +Cc: Petr Baudis, Alan Chandler, Jakub Narebski
Update list of build configuration variables, add references
to gitweb/INSTALL, add description of runtime and per-repository
runtime configuration.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/README | 215 ++++++++++++++++++++++++++++++++++++++++++++++++++++-----
1 files changed, 197 insertions(+), 18 deletions(-)
diff --git a/gitweb/README b/gitweb/README
index 7186ced..b28f59f 100644
--- a/gitweb/README
+++ b/gitweb/README
@@ -10,28 +10,96 @@ From the git version 1.4.0 gitweb is bundled with git.
How to configure gitweb for your local system
---------------------------------------------
+See also "Build time configuration" section in INSTALL
+file for gitweb (in gitweb/INSTALL).
+
You can specify the following configuration variables when building GIT:
+ * GIT_BINDIR
+ Points out where to find git executable. You should set up it to
+ the place where git binary was installed (usually /usr/bin) if you
+ don't install git from sources together with gitweb. [Default: $(bindir)]
* GITWEB_SITENAME
- Shown in the title of all generated pages, defaults to the servers name.
+ Shown in the title of all generated pages, defaults to the server name
+ (SERVER_NAME CGI environment variable) if not set. [No default]
* GITWEB_PROJECTROOT
- The root directory for all projects shown by gitweb.
+ The root directory for all projects shown by gitweb. Must be set
+ correctly for gitweb to find repositories to display. See also
+ "Gitweb repositories" in INSTALL file for gitweb. [Default: /pub/git]
+ * GITWEB_PROJECT_MAXDEPTH
+ The filesystem traversing limit for getting projects list; the number
+ is taken as depth relative to the projectroot. It is used when
+ GITWEB_LIST is a directory (or is not set; then project root is used).
+ Is is meant to speed up project listing on large work trees by limiting
+ find depth. [Default: 2007]
* GITWEB_LIST
- points to a directory to scan for projects (defaults to project root)
- or to a file for explicit listing of projects.
+ Points to a directory to scan for projects (defaults to project root
+ if not set / if empty) or to a file with explicit listing of projects
+ (together with projects' ownership). See "Generating projects list
+ using gitweb" in INSTALL file for gitweb to find out how to generate
+ such file from scan of a directory. [No default, which means use root
+ directory for projects]
+ * GITWEB_EXPORT_OK
+ Show repository only if this file exists (in repository). Only
+ effective if this variable evaluates to true. [No default / Not set]
+ * GITWEB_STRICT_EXPORT
+ Only allow viewing of repositories also shown on the overview page.
+ This for example makes GITWEB_EXPORT_OK to decide if repository is
+ available and not only if it is shown. If GITWEB_LIST points to
+ file with list of project, only those repositories listed would be
+ available for gitweb. [No default]
* GITWEB_HOMETEXT
- points to an .html file which is included on the gitweb project
- overview page.
+ Points to an .html file which is included on the gitweb project
+ overview page ('projects_list' view), if it exists. Relative to
+ gitweb.cgi script. [Default: indextext.html]
+ * GITWEB_SITE_HEADER
+ Filename of html text to include at top of each page. Relative to
+ gitweb.cgi script. [No default]
+ * GITWEB_SITE_FOOTER
+ Filename of html text to include at bottom of each page. Relative to
+ gitweb.cgi script. [No default]
+ * GITWEB_HOME_LINK_STR
+ String of the home link on top of all pages, leading to $home_link
+ (usually main gitweb page, which means projects list). Used as first
+ part of gitweb view "breadcrumb trail": <home> / <project> / <view>.
+ [Default: projects]
+ * GITWEB_SITENAME
+ Name of your site or organization to appear in page titles. Set it
+ to something descriptive for clearer bookmarks etc. If not set
+ (if empty) gitweb uses "$SERVER_NAME Git", or "Untitled Git" if
+ SERVER_NAME CGI environment variable is not set (e.g. if running
+ gitweb as standalone script). [No default]
+ * GITWEB_BASE_URL
+ Git base URLs used for URL to where fetch project from, i.e. full
+ URL is "$git_base_url/$project". Shown on projects summary page.
+ Repository URL for project can be also configured per repository; this
+ takes precendence over URL composed from base URL and project name.
+ Note that you can setup multiple base URLs (for example one for
+ git:// protocol access, one for http:// access) from gitweb config
+ file. [No default]
* GITWEB_CSS
- Points to the location where you put gitweb.css on your web server.
+ Points to the location where you put gitweb.css on your web server
+ (or to be more generic URI of gitweb stylesheet). Relative to base
+ URI of gitweb. Note that you can setup multiple stylesheets from
+ gitweb config file. [Default: gitweb.css]
* GITWEB_LOGO
- Points to the location where you put git-logo.png on your web server.
+ Points to the location where you put git-logo.png on your web server
+ (or to be more generic URI of logo, 72x27 size, displayed in top right
+ corner of each gitweb page, and used as logo for Atom feed). Relative
+ to base URI of gitweb. [Default: git-logo.png]
+ * GITWEB_FAVICON
+ Points to the location where you put git-favicon.png on your web server
+ (or to be more generic URI of favicon, assumed to be image/png type;
+ web browsers that support favicons (website icons) may display them
+ in the browser's URL bar and next to site name in bookmarks). Relative
+ to base URI of gitweb. [Default: git-favicon.png]
* GITWEB_CONFIG
- This file will be loaded using 'require' and can be used to override any
- of the options above as well as some other options - see the top of
- 'gitweb.cgi' for their full list and description. If the environment
- $GITWEB_CONFIG is set when gitweb.cgi is executed the file in the
- environment variable will be loaded instead of the file
- specified when gitweb.cgi was created.
+ This Perl file will be loaded using 'do' and can be used to override any
+ of the options above as well as some other options -- see the "Runtime
+ gitweb configuration" section below, and top of 'gitweb.cgi' for their
+ full list and description. If the environment variable GITWEB_CONFIG
+ is set when gitweb.cgi is executed, then the file specified in the
+ environment variable will be loaded instead of the file specified
+ when gitweb.cgi was created. [Default: gitweb_config.perl]
Runtime gitweb configuration
@@ -39,11 +107,122 @@ Runtime gitweb configuration
You can adjust gitweb behaviour using the file specified in `GITWEB_CONFIG`
(defaults to 'gitweb_config.perl' in the same directory as the CGI).
-See the top of 'gitweb.cgi' for the list of variables and some description.
The most notable thing that is not configurable at compile time are the
-optional features, stored in the '%features' variable. You can find further
-description on how to reconfigure the default features setting in your
-`GITWEB_CONFIG` or per-project in `project.git/config` inside 'gitweb.cgi'.
+optional features, stored in the '%features' variable.
+
+Ultimate description on how to reconfigure the default features setting
+in your `GITWEB_CONFIG` or per-project in `project.git/config` can be found
+as comments inside 'gitweb.cgi'.
+
+See also "Gitweb config file" (with example of gitweb config file), and
+"Gitweb repositories" sections in INSTALL file for gitweb.
+
+
+Gitweb config file is [fragment] of perl code. You can set variables
+using "our $variable = value"; text from "#" character until the end
+of a line is ignored. See perlsyn(1) man page for details.
+
+Below there is list of vaiables which you might want to set in gitweb config.
+See the top of 'gitweb.cgi' for the full list of variables and their
+descriptions.
+
+Gitweb config file variables
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+You can set, among others, the following variables in gitweb config files:
+ * $GIT
+ Cure git executable to use. By default set to "$GIT_BINDIR/git", which
+ in turn is by default set to "$(bindir)/git". If you use git from binary
+ package, set this to "/usr/bin/git". This can just be "git" if your
+ webserver has a sensible PATH. If you have multiple git versions
+ installed it is / can be used to choose which one to use.
+ * $version
+ Gitweb version, set automatically when creating gitweb.cgi from
+ gitweb.perl. You might want to modify it if you are running modified
+ gitweb.
+ * $my_url, $my_uri
+ URL and absolute URL of gitweb script; you might need to set those
+ variables if you are using 'pathinfo' feature: see also below.
+ * $home_link
+ Target of the home link on top of all pages (the first part of view
+ "breadcrumbs"). By default set to absolute URI of a page; you might
+ need to set it up to [base] gitweb URI if you use 'pathinfo' feature
+ (alternative format of the URLs, with project name embedded directly
+ in the path part of URL).
+ * @stylesheets
+ List of URIs of stylesheets (relative to base URI of a page). You
+ might specify more than one stylesheet, for example use gitweb.css
+ as base, with site specific modifications in separate stylesheet
+ to make it easier to upgrade gitweb. You can add 'site' stylesheet
+ for example by using
+ push @stylesheets, "gitweb-site.css";
+ in gitweb config file.
+ * $logo_url, $logo_label
+ URI and label (title) of GIT logo link (or your site logo, if you choose
+ to use different logo image). By default they point to git homepage;
+ in the past they pointed to git documentation at www.kernel.org.
+ * $projects_list_description_width
+ The width (in characters) of the projects list "Description" column.
+ Longer descriptions will be cut (trying to cut at word boundary);
+ full description is available as 'title' attribute (usually shown on
+ mouseover). By default set to 25, which might be too small if you
+ use long project descriptions.
+ * @git_base_url_list
+ List of git base URLs used for URL to where fetch project from, shown
+ in project summary page. Full URL is "$git_base_url/$project".
+ You can setup multiple base URLs (for example one for git:// protocol
+ access, and one for http:// "dumb" protocol access). Note that per
+ repository configuration in 'cloneurl' file, or as values of gitweb.url
+ project config.
+ * $default_blob_plain_mimetype
+ Default mimetype for blob_plain (raw) view, if mimetype checking
+ doesn't result in some other type; by default 'text/plain'.
+ * $default_text_plain_charset
+ Default charset for text files. If not set, web serwer configuration
+ would be used.
+ * $mimetypes_file
+ File to use for (filename extension based) guessing of MIME types before
+ trying /etc/mime.types. Path, if relative, is taken currently as taken
+ relative to current git repositoy.
+ * $fallback_encoding
+ Gitweb assumes this charset if line contains non-UTF-8 characters.
+ Fallback decoding is used without error checking, so it can be even
+ 'utf-8'. Value mist be valid encodig; see Encoding::Supported(3pm) man
+ page for a list. By default 'latin1', aka. 'iso-8859-1'.
+ * @diff_opts
+ Rename detection options for git-diff and git-diff-tree. By default
+ ('-M'); set it to ('-C') or ('-C', '-C') to also detect copies, or
+ set it to () if you don't want to have renames detection.
+
+Per-repository gitweb configuration
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+You can also configure individual repositories shown in gitweb by creating
+file in the GIT_DIR of git repository, or by setting some repo configuration
+variable (in GIT_DIR/config).
+
+You can use the following files in repository:
+ * README.html
+ A .html file (HTML fragment) which is included on the gitweb project
+ summary page inside <div> block element. You can use it for longer
+ description of a project, to provide links for example to projects
+ homepage, etc.
+ * description (or gitweb.description)
+ Short (shortened by default to 25 characters in the projects list page)
+ single line description of a project (of a repository). Plain text file;
+ HTML will be escaped. By default set to
+ Unnamed repository; edit this file to name it for gitweb.
+ from the template during creating repository. You can use
+ gitweb.description repo configuration variable, but the file takes
+ precendence.
+ * cloneurl (or multiple-valued gitweb.url)
+ File with repository URL (used for clone and fetch), one per line.
+ Displayed in the project summary page. You can use multiple-valued
+ gitweb.url repository configuration variable for that, but the file
+ takes precendence.
+ * various gitweb.* config variables (in config)
+ Read description of %feature hash for detailed list, and some
+ descriptions.
Webserver configuration
--
1.5.3.6
^ permalink raw reply related
* Re: gitk error: expected integer but got "Hamano"
From: David Kastrup @ 2007-12-02 23:23 UTC (permalink / raw)
To: git
In-Reply-To: <20071202160204.GA13141@fawkes>
Jing Xue <jingxue@digizenstudio.com> writes:
> I keep running into this error today when using "gitk --all" in my local
> git.git clone. It happens everytime when I use the mouse to grab the
> thumb button on the scroll bar, and drag it up and down rapidly.
>
> I'm running git 1.5.3.6.862.g3f72.
>
> expected integer but got "Hamano"
Consider me surprised. I have the highest regard for the integrity of
Junio Hamano.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: v1.5.4 plans
From: David Symonds @ 2007-12-02 23:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk5nwu51x.fsf@gitster.siamese.dyndns.org>
On Dec 3, 2007 9:04 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Please do not take this as the final decision made by the Emperor, whose
> subjects now must follow. This is a sanity-check to see if everybody is
> on the same page.
>
> I am not the Emperor anyway ;-)
>
> Topics not in 'master' yet but should be in v1.5.4
> --------------------------------------------------
>
> I think the following should go in, along with what we already have in
> 'master':
Can we add the git-status/git-checkout relative path stuff that's
currently been sitting in 'next'? It would be a good step forward for
usability.
Dave.
^ permalink raw reply
* Re: make test failure with latest master
From: Johannes Schindelin @ 2007-12-02 23:41 UTC (permalink / raw)
To: A Large Angry SCM; +Cc: Jeff King, git, gitster
In-Reply-To: <47533D75.1090002@gmail.com>
Hi,
On Sun, 2 Dec 2007, A Large Angry SCM wrote:
> Jeff King wrote:
> > On Sun, Dec 02, 2007 at 07:29:50AM -0500, A Large Angry SCM wrote:
> >
> > > With the latest master, 2221a6757161af1905925c405aded9ff470f70d5, "make
> > > test" now fails; last successful "make test" was mid-week sometime with
> > > master d25430. This is on a laptop running Suse 9.3.
> > >
> > > *** t9600-cvsimport.sh ***
> > > * ok 1: setup cvsroot
> > > * ok 2: setup a cvs module
> > > * FAIL 3: import a trivial module
> > >
> > >
> > > git cvsimport -a -z 0 -C module-git module &&
> > > git diff module-cvs/o_fortuna module-git/o_fortuna
> >
> > Can you please try ./t9600 --verbose? Presumably cvsimport is generating
> > some kind of error message to tell us what's going on.
>
> Attached is the output of
>
> ./t9600-cvsimport.sh --verbose >/tmp/9600_out.txt 2>&1
>
Unfortunately you attached the interesting part, so I cannot quote it
here. Seems that your cvsps does not understand the "-A" option. So it
looks like it is too old.
Hth,
Dscho
^ permalink raw reply
* Incorrect git-blame result if I use full path to file
From: Anatol Pomozov @ 2007-12-03 0:52 UTC (permalink / raw)
To: git
Hi, all.
I just start learning git and I found a bug (but sorry if the
functionality I am trying to blame as a bug not actually bug and it
was made by intention)
The problem is that git-blame returns incorrect result if you use full
path for files.
Here is an example script that generates repo.
#go to empty dir
git init
echo "On master" >> master.txt
git add master.txt
git commit -m "First commit"
echo "On master" >> master.txt
git commit -a -m "Second commit"
echo "On master" >> master.txt
Now lets do blame for master.txt
anatol:repo $ git blame master.txt
^69bce74 (Anatol Pomozov 2007-12-02 16:44:07 -0800 1) On master
4e2bbde4 (Anatol Pomozov 2007-12-02 16:44:15 -0800 2) On master
00000000 (Not Committed Yet 2007-12-02 16:44:27 -0800 3) On master
It is exaclty what we expect. But lets try full path for master.txt
$pwd
/personal/sources/learn/gitea/repo
$git blame /personal/sources/learn/gitea/repo/master.txt
^69bce74 (Anatol Pomozov 2007-12-02 16:44:07 -0800 1) On master
^69bce74 (Anatol Pomozov 2007-12-02 16:44:07 -0800 2) On master
^69bce74 (Anatol Pomozov 2007-12-02 16:44:07 -0800 3) On master
Now git shows that all lines in the file were changed by the first
commit and that it does not true.
--
anatol
^ permalink raw reply
* Re: [RFC] use typechange as rename source
From: Jeff King @ 2007-12-03 1:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8x4cykkj.fsf@gitster.siamese.dyndns.org>
On Sun, Dec 02, 2007 at 11:15:40AM -0800, Junio C Hamano wrote:
> > @@ -250,6 +250,7 @@ static void wt_status_print_updated(struct wt_status *s)
> > + rev.diffopt.break_opt = 0;
>
> I have to wonder how much this is going to make things worse in the real
> world, although I agree in the "as we already spend cycles for
> detect_rename why not" sense.
>
> With the recent change from Alex not to run status when not interactive,
> it probably does not matter. If we are going to spawn an editor, we are
> dealing with human interaction and even -B -M should not be too bad.
I had more or less the same thinking, but I don't have any real-world
numbers. I would be curious to see averages on how diffcore-break
compares to diffcore-rename. Just thinking about it, it seems intuitive
that breaking would always be cheaper, which means that adding "-B" to
"-M" won't have a significant performance impact.
-Peff
^ permalink raw reply
* [PATCH] Reorder msgfmt command-line arguments.
From: brian m. carlson @ 2007-12-03 1:26 UTC (permalink / raw)
To: git
Any program using getopt or getopt_long will stop processing options
once a non-option argument has been encountered, if POSIXLY_CORRECT is
set. Therefore, reorder the command-line arguments to put options
first, so that the msgfmt call works in this scenario.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.ath.cx>
---
Note that this patch is against the next branch, since that's what I
use. It may or may not apply (or be needed) on the mainline.
git-gui/Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-gui/Makefile b/git-gui/Makefile
index e860319..4ce4663 100644
--- a/git-gui/Makefile
+++ b/git-gui/Makefile
@@ -212,7 +212,7 @@ $(PO_TEMPLATE): $(SCRIPT_SH) $(ALL_LIBFILES)
update-po:: $(PO_TEMPLATE)
$(foreach p, $(ALL_POFILES), echo Updating $p ; msgmerge -U $p $(PO_TEMPLATE) ; )
$(ALL_MSGFILES): %.msg : %.po
- $(QUIET_MSGFMT0)$(MSGFMT) --statistics --tcl $< -l $(basename $(notdir $<)) -d $(dir $@) $(QUIET_MSGFMT1)
+ $(QUIET_MSGFMT0)$(MSGFMT) --statistics --tcl -l $(basename $(notdir $<)) -d $(dir $@) $< $(QUIET_MSGFMT1)
lib/tclIndex: $(ALL_LIBFILES) GIT-GUI-VARS
$(QUIET_INDEX)if echo \
--
1.5.3.6.1797.g67f5d
^ permalink raw reply related
* Re: make test failure with latest master
From: Jeff King @ 2007-12-03 1:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: A Large Angry SCM, git, gitster
In-Reply-To: <Pine.LNX.4.64.0712022340250.27959@racer.site>
On Sun, Dec 02, 2007 at 11:41:10PM +0000, Johannes Schindelin wrote:
> > Attached is the output of
> >
> > ./t9600-cvsimport.sh --verbose >/tmp/9600_out.txt 2>&1
> >
>
> Unfortunately you attached the interesting part, so I cannot quote it
> here. Seems that your cvsps does not understand the "-A" option. So it
> looks like it is too old.
Yes, the changelog indicates that -A was added in 2.1, and he is running
2.0rc1.
We can do something like this, though it feels a bit hack-ish and will
need updated for new cvsps versions (a less lazy or more clever shell
coder than me could do a nice >= version comparator).
-- >8 --
t9600: require cvsps 2.1 to perform tests
git-cvsimport won't run at all with less than cvsps 2.1, because it
lacks the -A flag. But there's no point in preventing people who have an
old cvsps from running the full testsuite.
Signed-off-by: Jeff King <peff@peff.net>
---
diff --git a/t/t9600-cvsimport.sh b/t/t9600-cvsimport.sh
index 08f0f2a..c646111 100755
--- a/t/t9600-cvsimport.sh
+++ b/t/t9600-cvsimport.sh
@@ -3,13 +3,29 @@
test_description='git-cvsimport basic tests'
. ./test-lib.sh
-if ! ( type cvs && type cvsps ) >/dev/null 2>&1
+if ! type cvs >/dev/null 2>&1
then
- test_expect_success 'skipping cvsimport tests, cvs/cvsps not found' ''
+ test_expect_success 'skipping cvsimport tests, cvs not found' ''
test_done
exit
fi
+cvsps_version=`cvsps -h 2>&1 | sed -ne 's/cvsps version //p'`
+case "$cvsps_version" in
+2.1)
+ ;;
+'')
+ test_expect_success 'skipping cvsimport tests, cvsps not found' ''
+ test_done
+ exit
+ ;;
+*)
+ test_expect_success 'skipping cvsimport tests, cvsps too old' ''
+ test_done
+ exit
+ ;;
+esac
+
CVSROOT=$(pwd)/cvsroot
export CVSROOT
# for clean cvsps cache
^ permalink raw reply related
* Re: [PATCH v4] Allow update hooks to update refs on their own.
From: Jeff King @ 2007-12-03 2:13 UTC (permalink / raw)
To: Steven Grimm; +Cc: git
In-Reply-To: <20071202212224.GA22117@midwinter.com>
On Sun, Dec 02, 2007 at 01:22:24PM -0800, Steven Grimm wrote:
> Since Junio's main objection to this seemed to be the protocol
> change to bypass the automatic update of the tracking ref in
> git-send-pack, that code is gone (thus reverting this to the
> same code change as the initial version!) and I added a section
> to the git-send-pack manual page describing the automatic
> tracking ref update behavior, which wasn't documented at all
> before. Someone please review my terminology there.
I am dubious of the usefulness of passing back the new commit id, but an
"ok, but btw I changed your commit" status from receive-pack seems like
it would be useful, for two reasons:
- it can be displayed differently, so the user is reminded to do a
fetch afterwards
- we can avoid updating the tracking ref, which makes it less likely
to result in a non-fast forward fetch next time. For example,
consider:
1. The remote master and my origin/master are at A.
2. I make a commit B on top of A.
3. I push B to remote, who rewrites it to B' on top of A. At the
same time, I move my origin/master to B.
4. I fetch, and get non-ff going from B to B'.
If I had never written anything to my origin/master, it would be a
fast forward. And obviously git handles it just fine, but it is more
useful to the user during the next fetch to see A..B rather than
B'...B.
-Peff
^ 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