* Re: [PATCH] Don't dereference NULL upon lookup_tree failure.
From: Jim Meyering @ 2007-12-22 0:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git list, Matthew Farrellee
In-Reply-To: <7vve6r39bp.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Jim Meyering <jim@meyering.net> writes:
>
>> Junio C Hamano <gitster@pobox.com> wrote:
>> ...
>>> Sorry, I asked for a wrong thing. parse_object() reads and
>>> finds out the type, so type there is presumably the right type
>>> of the object (which is OBJ_TREE). Then parse_object_buffer()
>>> checks if it has already seen the object of the same SHA-1 and
>>> finds that somebody had earlier told that SHA-1 name is of a
>>> commit object. Either you found a SHA-1 collision (highly
>>> unlikely) or the earlier caller had lied. And I think what
>>> really needs to be fixed is that lying caller. That is not in
>>> the above call chain.
>>
>> I presume that parsecvs is the culprit, in constructing
>> an invalid repository...
>
> Independent of who creates a "invalid repository", our tools
> should be prepared to be fed bad data and not get upset.
> Somebody in our code read a non-commit (or it did not read
> anything) and told the object layer it is a commit. That
> codepath needs to be tightened up, no?
Yes, of course.
Unfortunately, I won't have time to investigate for a while.
^ permalink raw reply
* Re: [PATCH] Don't dereference NULL upon lookup_tree failure.
From: Junio C Hamano @ 2007-12-21 23:40 UTC (permalink / raw)
To: Jim Meyering; +Cc: git list, Matthew Farrellee
In-Reply-To: <87bq8jvd1g.fsf@rho.meyering.net>
Jim Meyering <jim@meyering.net> writes:
> Junio C Hamano <gitster@pobox.com> wrote:
> ...
>> Sorry, I asked for a wrong thing. parse_object() reads and
>> finds out the type, so type there is presumably the right type
>> of the object (which is OBJ_TREE). Then parse_object_buffer()
>> checks if it has already seen the object of the same SHA-1 and
>> finds that somebody had earlier told that SHA-1 name is of a
>> commit object. Either you found a SHA-1 collision (highly
>> unlikely) or the earlier caller had lied. And I think what
>> really needs to be fixed is that lying caller. That is not in
>> the above call chain.
>
> I presume that parsecvs is the culprit, in constructing
> an invalid repository...
Independent of who creates a "invalid repository", our tools
should be prepared to be fed bad data and not get upset.
Somebody in our code read a non-commit (or it did not read
anything) and told the object layer it is a commit. That
codepath needs to be tightened up, no?
^ permalink raw reply
* Re: [PATCH] Don't dereference NULL upon lookup_tree failure.
From: Jim Meyering @ 2007-12-21 23:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git list, Matthew Farrellee
In-Reply-To: <7vzlw33a1o.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Jim Meyering <jim@meyering.net> writes:
>
>>> While this change may be a prudent safeguard, there is something
>>> else going on. Can you provide the callchain that led to the
>>> parse_object_buffer() that gave SHA1 of a commit object with
>>> type set to OBJ_TREE? Which caller does that bogus combination?
>>
>> Sure.
>> Here's valgrind output from running this (from my reproducer):
>>
>> valgrind --trace-children=yes git clone . k
>> ---------------
>> error: Object 0d57588da39d10795486bd5451bc2660832228e6 is a commit, not a tree
>> ==9483== Invalid read of size 1
>> ==9483== at 0x405C27: parse_object_buffer (object.c:146)
>> ==9483== by 0x405CE4: parse_object (object.c:187)
>> ==9483== by 0x403185: send_ref (upload-pack.c:561)
>> ==9483== by 0x408EEF: do_for_each_ref (refs.c:546)
>> ==9483== by 0x4036EC: main (upload-pack.c:587)
>
> Sorry, I asked for a wrong thing. parse_object() reads and
> finds out the type, so type there is presumably the right type
> of the object (which is OBJ_TREE). Then parse_object_buffer()
> checks if it has already seen the object of the same SHA-1 and
> finds that somebody had earlier told that SHA-1 name is of a
> commit object. Either you found a SHA-1 collision (highly
> unlikely) or the earlier caller had lied. And I think what
> really needs to be fixed is that lying caller. That is not in
> the above call chain.
I haven't debugged it enough to find/fix the bug in parsecvs.
I presume that parsecvs is the culprit, in constructing
an invalid repository -- especially, since inserting the
single missing tag into the ,v file is enough to make it so
parsecvs creates a repository that no longer triggers the git bug.
^ permalink raw reply
* Re: [PATCH] Don't dereference NULL upon lookup_tree failure.
From: Junio C Hamano @ 2007-12-21 23:25 UTC (permalink / raw)
To: Jim Meyering; +Cc: git list, Matthew Farrellee
In-Reply-To: <87hcibveut.fsf@rho.meyering.net>
Jim Meyering <jim@meyering.net> writes:
>> While this change may be a prudent safeguard, there is something
>> else going on. Can you provide the callchain that led to the
>> parse_object_buffer() that gave SHA1 of a commit object with
>> type set to OBJ_TREE? Which caller does that bogus combination?
>
> Sure.
> Here's valgrind output from running this (from my reproducer):
>
> valgrind --trace-children=yes git clone . k
> ---------------
> error: Object 0d57588da39d10795486bd5451bc2660832228e6 is a commit, not a tree
> ==9483== Invalid read of size 1
> ==9483== at 0x405C27: parse_object_buffer (object.c:146)
> ==9483== by 0x405CE4: parse_object (object.c:187)
> ==9483== by 0x403185: send_ref (upload-pack.c:561)
> ==9483== by 0x408EEF: do_for_each_ref (refs.c:546)
> ==9483== by 0x4036EC: main (upload-pack.c:587)
Sorry, I asked for a wrong thing. parse_object() reads and
finds out the type, so type there is presumably the right type
of the object (which is OBJ_TREE). Then parse_object_buffer()
checks if it has already seen the object of the same SHA-1 and
finds that somebody had earlier told that SHA-1 name is of a
commit object. Either you found a SHA-1 collision (highly
unlikely) or the earlier caller had lied. And I think what
really needs to be fixed is that lying caller. That is not in
the above call chain.
^ permalink raw reply
* [PATCH] Allow selection of different cleanup modes for commit messages
From: Alex Riesen @ 2007-12-21 23:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7v8x3n4tbe.fsf@gitster.siamese.dyndns.org>
Sometimes the message just have to be the way user wants it.
For instance, a template can contain "#" characters, or the message
must be kept as close to its original source as possible for reimport
reasons. Or maybe the user just copied a shell script including its
comments into the commit message for future reference.
The cleanup modes are default, verbatim, whitespace and strip. The
default mode depends on if the message is being edited and will either
strip whitespace and comments (if editor active) or just strip the
whitespace (for where the message is given explicitely).
Suggested by Linus.
Signed-off-by: Alex Riesen <raa@gmail.com>
---
Junio C Hamano, Fri, Dec 21, 2007 22:43:49 +0100:
> Alex Riesen <raa.lkml@gmail.com> writes:
>
> > The patch is on top of my previos patches. Junio, if you wish, I can
> > squash and resend.
>
> That would be a sane thing to do.
Done
Documentation/git-commit.txt | 12 +++++++-
builtin-commit.c | 69 +++++++++++++++++++++++++++++++----------
t/t7502-commit.sh | 40 ++++++++++++++++++++++++
3 files changed, 103 insertions(+), 18 deletions(-)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 4261384..ac2bfd5 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -11,7 +11,7 @@ SYNOPSIS
'git-commit' [-a | --interactive] [-s] [-v] [-u]
[(-c | -C) <commit> | -F <file> | -m <msg> | --amend]
[--allow-empty] [--no-verify] [-e] [--author <author>]
- [--] [[-i | -o ]<file>...]
+ [--cleanup=<mode>] [--] [[-i | -o ]<file>...]
DESCRIPTION
-----------
@@ -95,6 +95,16 @@ OPTIONS
from making such a commit. This option bypasses the safety, and
is primarily for use by foreign scm interface scripts.
+--cleanup=<mode>::
+ This option sets how the commit message is cleaned up.
+ The '<mode>' can be one of 'verbatim', 'whitespace', 'strip',
+ and 'default'. The 'default' mode will strip leading and
+ trailing empty lines and #commentary from the commit message
+ only if the message is to be edited. Otherwise only whitespace
+ removed. The 'verbatim' mode wont change message at all,
+ 'whitespace' removes just leading/trailing whitespace lines
+ and 'strip' removes both whitespace and commentary.
+
-e|--edit::
The message taken from file with `-F`, command line with
`-m`, and from file with `-C` are usually used as the
diff --git a/builtin-commit.c b/builtin-commit.c
index 0a91013..6f98537 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -47,6 +47,20 @@ static char *logfile, *force_author, *template_file;
static char *edit_message, *use_message;
static int all, edit_flag, also, interactive, only, amend, signoff;
static int quiet, verbose, untracked_files, no_verify, allow_empty;
+/*
+ * The default commit message cleanup mode will remove the lines
+ * beginning with # (shell comments) and leading and trailing
+ * whitespaces (empty lines or containing only whitespaces)
+ * if editor is used, and only the whitespaces if the message
+ * is specified explicitly.
+ */
+static enum {
+ CLEANUP_DEFAULT,
+ CLEANUP_NONE,
+ CLEANUP_SPACE,
+ CLEANUP_ALL,
+} cleanup_mode;
+static char *cleanup_arg;
static int no_edit, initial_commit, in_merge;
const char *only_include_assumed;
@@ -88,6 +102,7 @@ static struct option builtin_commit_options[] = {
OPT_BOOLEAN(0, "amend", &amend, "amend previous commit"),
OPT_BOOLEAN(0, "untracked-files", &untracked_files, "show all untracked files"),
OPT_BOOLEAN(0, "allow-empty", &allow_empty, "ok to record an empty change"),
+ OPT_STRING(0, "cleanup", &cleanup_arg, "default", "how to strip spaces and #comments from message"),
OPT_END()
};
@@ -346,7 +361,8 @@ static int prepare_log_message(const char *index_file, const char *prefix)
if (fp == NULL)
die("could not open %s", git_path(commit_editmsg));
- stripspace(&sb, 0);
+ if (cleanup_mode != CLEANUP_NONE)
+ stripspace(&sb, 0);
if (signoff) {
struct strbuf sob;
@@ -394,20 +410,24 @@ static int prepare_log_message(const char *index_file, const char *prefix)
return !!DIFF_OPT_TST(&rev.diffopt, HAS_CHANGES);
}
- if (in_merge && !no_edit)
- fprintf(fp,
- "#\n"
- "# It looks like you may be committing a MERGE.\n"
- "# If this is not correct, please remove the file\n"
- "# %s\n"
- "# and try again.\n"
- "#\n",
- git_path("MERGE_HEAD"));
-
- fprintf(fp,
- "\n"
- "# Please enter the commit message for your changes.\n"
- "# (Comment lines starting with '#' will not be included)\n");
+ if (!no_edit) {
+ if (in_merge)
+ fprintf(fp,
+ "#\n"
+ "# It looks like you may be committing a MERGE.\n"
+ "# If this is not correct, please remove the file\n"
+ "# %s\n"
+ "# and try again.\n"
+ "#\n",
+ git_path("MERGE_HEAD"));
+ if (cleanup_mode != CLEANUP_NONE)
+ fprintf(fp,
+ "\n"
+ "# Please enter the commit message for your changes.\n");
+ if (cleanup_mode == CLEANUP_DEFAULT)
+ fprintf(fp,
+ "# (Comment lines starting with '#' will not be included)\n");
+ }
if (only_include_assumed)
fprintf(fp, "# %s\n", only_include_assumed);
@@ -431,10 +451,13 @@ static int message_is_empty(struct strbuf *sb, int start)
const char *nl;
int eol, i;
+ if (cleanup_mode == CLEANUP_NONE && sb->len)
+ return 0;
+
/* See if the template is just a prefix of the message. */
strbuf_init(&tmpl, 0);
if (template_file && strbuf_read_file(&tmpl, template_file, 0) > 0) {
- stripspace(&tmpl, 1);
+ stripspace(&tmpl, !no_edit);
if (start + tmpl.len <= sb->len &&
memcmp(tmpl.buf, sb->buf + start, tmpl.len) == 0)
start += tmpl.len;
@@ -587,6 +610,16 @@ static int parse_and_validate_options(int argc, const char *argv[],
only_include_assumed = "Explicit paths specified without -i nor -o; assuming --only paths...";
also = 0;
}
+ if (!cleanup_arg || !strcmp(cleanup_arg, "default"))
+ cleanup_mode = CLEANUP_DEFAULT;
+ else if (!strcmp(cleanup_arg, "verbatim"))
+ cleanup_mode = CLEANUP_NONE;
+ else if (!strcmp(cleanup_arg, "whitespace"))
+ cleanup_mode = CLEANUP_SPACE;
+ else if (!strcmp(cleanup_arg, "strip"))
+ cleanup_mode = CLEANUP_ALL;
+ else
+ die("Invalid cleanup mode %s", cleanup_arg);
if (all && argc > 0)
die("Paths with -a does not make sense.");
@@ -813,7 +846,9 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
if (p != NULL)
strbuf_setlen(&sb, p - sb.buf + 1);
- stripspace(&sb, 1);
+ if (cleanup_mode != CLEANUP_NONE)
+ stripspace(&sb, cleanup_mode == CLEANUP_DEFAULT ?
+ !no_edit: cleanup_mode == CLEANUP_ALL);
if (sb.len < header_len || message_is_empty(&sb, header_len)) {
rollback_index_files();
die("no commit message? aborting commit.");
diff --git a/t/t7502-commit.sh b/t/t7502-commit.sh
index 21ac785..6219378 100755
--- a/t/t7502-commit.sh
+++ b/t/t7502-commit.sh
@@ -89,4 +89,44 @@ test_expect_success 'verbose' '
'
+test_expect_success 'verbatim commit messages' '
+
+ echo >>negative &&
+ { echo;echo "# text";echo; } >expect &&
+ git commit --cleanup=verbatim -t expect -a &&
+ git cat-file -p HEAD |sed -e "1,/^\$/d" |head -n 3 >actual &&
+ diff -u expect actual &&
+ echo >>negative &&
+ git commit --cleanup=verbatim -F expect -a &&
+ git cat-file -p HEAD |sed -e "1,/^\$/d">actual &&
+ diff -u expect actual &&
+ echo >>negative &&
+ git commit --cleanup=verbatim -m "$(cat expect)" -a &&
+ git cat-file -p HEAD |sed -e "1,/^\$/d">actual &&
+ diff -u expect actual
+
+'
+
+test_expect_success 'cleanup only whitespace from commit messages' '
+
+ echo >>negative &&
+ { echo;echo "# text";echo; } >text &&
+ echo "# text" >expect &&
+ git commit --cleanup=whitespace -F text -a &&
+ git cat-file -p HEAD |sed -e "1,/^\$/d">actual &&
+ diff -u expect actual
+
+'
+
+test_expect_success 'cleanup commit messages' '
+
+ echo >>negative &&
+ { echo;echo "# text";echo sample;echo; } >text &&
+ echo sample >expect &&
+ git commit --cleanup=strip -F text -a &&
+ git cat-file -p HEAD |sed -e "1,/^\$/d">actual &&
+ diff -u expect actual
+
+'
+
test_done
--
1.5.4.rc1.36.g24341
^ permalink raw reply related
* Re: Failed binary detection.
From: Sean @ 2007-12-21 23:02 UTC (permalink / raw)
To: David Brown; +Cc: Git
In-Reply-To: <20071221195019.GA20668@old.davidb.org>
On Fri, 21 Dec 2007 11:50:19 -0800
David Brown <git@davidb.org> wrote:
> A coworker has a branch with some large binary files (video test streams).
> Git doesn't seem to be detecting this file is binary, and is causing things
> that try to generate diffs to fail.
>
> Specifically, he is unable to rebase his branch, getting an error:
>
> .dotest/patch:3241:LD := ld
> fatal: corrupt patch at line 84682
> Patch failed at 0001.
>
> Line 84682 is in the middle of what appear to be the binary contents of the
> large media file, with pluses inserted after newline.
>
> Any advice on where to look or possibly how to fix this?
>
> I was able to work around the problem by cherry picking the change instead
> of using rebase. git-format-patch generates a patch that is corrupt in the
> same way, which fails with 'git-am'.
>
Dave,
Telling Git that the file is binary is likely all you need to do. Something
like the following line in a .gitattributes file:
filename -diff
For more info see "man gitattributes".
HTH,
Sean
^ permalink raw reply
* Re: Failed binary detection.
From: Dmitry V. Levin @ 2007-12-21 23:00 UTC (permalink / raw)
To: Git
In-Reply-To: <20071221195019.GA20668@old.davidb.org>
[-- Attachment #1: Type: text/plain, Size: 741 bytes --]
On Fri, Dec 21, 2007 at 11:50:19AM -0800, David Brown wrote:
> A coworker has a branch with some large binary files (video test streams).
> Git doesn't seem to be detecting this file is binary, and is causing things
> that try to generate diffs to fail.
>
> Specifically, he is unable to rebase his branch, getting an error:
>
> .dotest/patch:3241:LD := ld
> fatal: corrupt patch at line 84682
> Patch failed at 0001.
>
> Line 84682 is in the middle of what appear to be the binary contents of the
> large media file, with pluses inserted after newline.
>
> Any advice on where to look or possibly how to fix this?
See discussion of this issue in git archives, e.g.
http://marc.info/?t=119652720900002
--
ldv
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Don't dereference NULL upon lookup_tree failure.
From: Jim Meyering @ 2007-12-21 22:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git list, Matthew Farrellee
In-Reply-To: <7v4peb4qbj.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Jim Meyering <jim@meyering.net> writes:
>
>> When running on an x86_64 system (either debian unstable or rawhide)
>> I see only this:
>>
>> 0 blocks
>> error: Object 0d57588da39d10795486bd5451bc2660832228e6 is a commit, not a tree
>> fatal: The remote end hung up unexpectedly
>>...
>> diff --git a/object.c b/object.c
>> index 16793d9..eb59550 100644
>> --- a/object.c
>> +++ b/object.c
>> @@ -142,10 +142,14 @@ struct object *parse_object_buffer(const unsigned char *sha1, enum object_type t
>> obj = &blob->object;
>> } else if (type == OBJ_TREE) {
>> struct tree *tree = lookup_tree(sha1);
>> - obj = &tree->object;
>> - if (!tree->object.parsed) {
>> - parse_tree_buffer(tree, buffer, size);
>> - eaten = 1;
>> + if (!tree)
>> + obj = NULL;
>> + else {
>> + obj = &tree->object;
>> + if (!tree->object.parsed) {
>> + parse_tree_buffer(tree, buffer, size);
>> + eaten = 1;
>> + }
>> }
>> } else if (type == OBJ_COMMIT) {
>> struct commit *commit = lookup_commit(sha1);
>
> While this change may be a prudent safeguard, there is something
> else going on. Can you provide the callchain that led to the
> parse_object_buffer() that gave SHA1 of a commit object with
> type set to OBJ_TREE? Which caller does that bogus combination?
Sure.
Here's valgrind output from running this (from my reproducer):
valgrind --trace-children=yes git clone . k
---------------
error: Object 0d57588da39d10795486bd5451bc2660832228e6 is a commit, not a tree
==9483== Invalid read of size 1
==9483== at 0x405C27: parse_object_buffer (object.c:146)
==9483== by 0x405CE4: parse_object (object.c:187)
==9483== by 0x403185: send_ref (upload-pack.c:561)
==9483== by 0x408EEF: do_for_each_ref (refs.c:546)
==9483== by 0x4036EC: main (upload-pack.c:587)
==9483== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==9483==
==9483== Process terminating with default action of signal 11 (SIGSEGV)
==9483== Access not within mapped region at address 0x0
==9483== at 0x405C27: parse_object_buffer (object.c:146)
==9483== by 0x405CE4: parse_object (object.c:187)
==9483== by 0x403185: send_ref (upload-pack.c:561)
==9483== by 0x408EEF: do_for_each_ref (refs.c:546)
==9483== by 0x4036EC: main (upload-pack.c:587)
...
fatal: The remote end hung up unexpectedly
^ permalink raw reply
* Re: [PATCH] Don't dereference NULL upon lookup_tree failure.
From: Junio C Hamano @ 2007-12-21 22:48 UTC (permalink / raw)
To: Jim Meyering; +Cc: git list, Matthew Farrellee
In-Reply-To: <873atvwueq.fsf@rho.meyering.net>
Jim Meyering <jim@meyering.net> writes:
> When running on an x86_64 system (either debian unstable or rawhide)
> I see only this:
>
> 0 blocks
> error: Object 0d57588da39d10795486bd5451bc2660832228e6 is a commit, not a tree
> fatal: The remote end hung up unexpectedly
>...
> diff --git a/object.c b/object.c
> index 16793d9..eb59550 100644
> --- a/object.c
> +++ b/object.c
> @@ -142,10 +142,14 @@ struct object *parse_object_buffer(const unsigned char *sha1, enum object_type t
> obj = &blob->object;
> } else if (type == OBJ_TREE) {
> struct tree *tree = lookup_tree(sha1);
> - obj = &tree->object;
> - if (!tree->object.parsed) {
> - parse_tree_buffer(tree, buffer, size);
> - eaten = 1;
> + if (!tree)
> + obj = NULL;
> + else {
> + obj = &tree->object;
> + if (!tree->object.parsed) {
> + parse_tree_buffer(tree, buffer, size);
> + eaten = 1;
> + }
> }
> } else if (type == OBJ_COMMIT) {
> struct commit *commit = lookup_commit(sha1);
While this change may be a prudent safeguard, there is something
else going on. Can you provide the callchain that led to the
parse_object_buffer() that gave SHA1 of a commit object with
type set to OBJ_TREE? Which caller does that bogus combination?
^ permalink raw reply
* Re: [PATCH] git-send-email: Add --suppress-all-from option.
From: David Brown @ 2007-12-21 22:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfxxw7xkb.fsf@gitster.siamese.dyndns.org>
On Fri, Dec 21, 2007 at 09:43:48AM -0800, Junio C Hamano wrote:
>David Brown <git@davidb.org> writes:
>
>> Sometimes, it is useful to be able to send a patch to a third party
>> without the author of the patch being copied on the message.
>
>I would agree with the cause, but not necessarily with the
>execution.
Ok. I will look into the overall cleanup, but probably not until this
weekend.
Dave
^ permalink raw reply
* [PATCH] Don't dereference NULL upon lookup_tree failure.
From: Jim Meyering @ 2007-12-21 22:32 UTC (permalink / raw)
To: git list; +Cc: Matthew Farrellee
While Matthew Farrellee was working on converting the Condor repository
from cvs to git, he managed to make git segfault (with help from parsecvs)
while producing a 100MB .git repository. He found the single offending
,v file that led parsecvs to generate a bogus repository, and deduced
that adding a single well-placed branch tag[*] was enough to avoid
the problem. I fixed the bug in git along with a few in parsecvs that
were exposed while paring the ,v file down from a 150KB monstrosity to
something manageable.
[*] Adding this tag avoids the problem: FOO:1.30.2.5.0.8
First, here's how to reproduce the git segfault, using the file, "min,v"
included below. Run this in an empty directory:
rm -rf k .git .git-cvs
parsecvs min,v >& log
git clone -q . k
I noticed that while I get a segfault both on x86 and x86_64, I see
clear evidence of it only on x86:
0 blocks
error: Object 0d57588da39d10795486bd5451bc2660832228e6 is a commit, not a tree
Segmentation fault
fatal: The remote end hung up unexpectedly
[Exit 1]
When running on an x86_64 system (either debian unstable or rawhide)
I see only this:
0 blocks
error: Object 0d57588da39d10795486bd5451bc2660832228e6 is a commit, not a tree
fatal: The remote end hung up unexpectedly
Of course, valgrind shows you the segfault in both cases.
The above was using git version 1.5.4.rc1.3.gec692
and the latest parsecvs from here:
git://people.freedesktop.org/~keithp/parsecvs
commit 2b0113ffb0055620193397c025d6f6bca3b110cd
Author: Finn Arne Gangstad <finnag@pvv.org>
Date: Sun Nov 18 15:26:35 2007 -0800
This patch avoids the NULL dereference by treating a failed lookup_tree the
same way an invalid "type" is handled in the "else" block just below.
The only difference is that for a failed lookup_tree, the failing
function has already produced a diagnostic.
-----------------------------------------------------
From 4cd649160d8174b23727b3d7276f1bd7246d0aff Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyering@redhat.com>
Date: Fri, 21 Dec 2007 11:56:32 +0100
Subject: [PATCH] Don't dereference NULL upon lookup_tree failure.
Signed-off-by: Jim Meyering <meyering@redhat.com>
---
object.c | 12 ++++++++----
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/object.c b/object.c
index 16793d9..eb59550 100644
--- a/object.c
+++ b/object.c
@@ -142,10 +142,14 @@ struct object *parse_object_buffer(const unsigned char *sha1, enum object_type t
obj = &blob->object;
} else if (type == OBJ_TREE) {
struct tree *tree = lookup_tree(sha1);
- obj = &tree->object;
- if (!tree->object.parsed) {
- parse_tree_buffer(tree, buffer, size);
- eaten = 1;
+ if (!tree)
+ obj = NULL;
+ else {
+ obj = &tree->object;
+ if (!tree->object.parsed) {
+ parse_tree_buffer(tree, buffer, size);
+ eaten = 1;
+ }
}
} else if (type == OBJ_COMMIT) {
struct commit *commit = lookup_commit(sha1);
--
1.5.4.rc0.76.g55ee
Here's the contents of min,v
------------------------------------------------
head 1.31;
access;
symbols
a:1.30.2.18.4.14.4.29.0.6
b:1.30.2.18.4.14.4.29.0.4
c:1.30.2.18.4.14.4.29.0.2
d:1.30.2.18.4.14.4.27.0.6
e:1.30.2.18.4.14.4.27.0.4
f:1.30.2.18.4.14.4.27.0.2
g:1.30.2.18.4.14.4.25.0.6
h:1.30.2.18.4.14.4.25.0.4
i:1.30.2.18.4.14.4.25.0.2
j:1.30.2.18.4.14.4.24.0.24
k:1.30.2.18.4.14.4.24.0.22
l:1.30.2.18.4.14.4.24.0.20
m:1.30.2.18.4.14.4.24.0.18
n:1.30.2.18.4.14.4.24.0.16
o:1.30.2.18.4.14.4.24.0.14
p:1.30.2.18.4.14.4.24.0.12
q:1.30.2.18.4.14.4.24.0.10
r:1.30.2.18.4.14.4.24.0.8
s:1.30.2.18.4.14.4.24.0.6
t:1.30.2.18.4.14.4.24.0.4
u:1.30.2.18.4.14.4.24.0.2
a0:1.30.2.18.4.14.4.23.0.10
a1:1.30.2.18.4.14.4.23.0.8
a2:1.30.2.18.4.14.4.23.0.6
a3:1.30.2.18.4.14.4.23.0.4
a4:1.30.2.18.4.14.4.23.0.2
a5:1.30.2.18.4.14.4.22.0.2
a6:1.30.2.18.4.14.4.21.0.2
a7:1.30.2.18.4.14.4.18.4.1.0.2
a8:1.30.2.18.4.14.4.18.0.6
a9:1.30.2.18.4.14.4.18.0.4
a10:1.30.2.18.4.14.4.17.0.12
a11:1.30.2.18.4.14.4.18.0.2
a12:1.30.2.18.4.14.4.17.0.10
a13:1.30.2.18.4.14.4.17.0.8
a14:1.30.2.18.4.14.4.17.0.6
a15:1.30.2.18.4.14.4.17.0.4
a16:1.30.2.18.4.14.4.17.0.2
a17:1.30.2.18.4.14.4.16.0.2
a18:1.30.2.18.4.14.4.15.0.2
a19:1.30.2.18.4.14.4.14.0.10
a20:1.30.2.18.4.14.4.14.0.8
a21:1.30.2.18.4.14.4.14.0.6
a22:1.30.2.18.4.14.4.14.0.4
a23:1.30.2.18.4.14.4.14.0.2
a24:1.30.2.18.4.14.4.13.0.4
a25:1.30.2.18.4.14.4.13.0.2
a26:1.30.2.18.4.14.4.7.0.6
a27:1.30.2.18.4.14.4.12.0.8
a28:1.30.2.18.4.14.4.12.0.6
a29:1.30.2.18.4.14.4.12.0.4
a30:1.30.2.18.4.14.4.12.0.2
a31:1.30.2.18.4.14.4.11.0.4
a32:1.30.2.18.4.14.4.11.0.2
a33:1.30.2.18.4.14.4.9.0.16
a34:1.30.2.18.4.14.4.9.0.14
a35:1.30.2.18.4.14.4.9.0.12
a36:1.30.2.18.4.14.4.9.0.10
a37:1.30.2.18.4.14.4.9.0.8
a38:1.30.2.18.4.14.4.9.0.6
a39:1.30.2.18.4.14.4.9.0.4
a40:1.30.2.18.4.14.4.9.0.2
a41:1.30.2.18.4.14.4.8.0.16
a42:1.30.2.18.4.14.4.8.0.14
a43:1.30.2.18.4.14.4.8.0.12
a44:1.30.2.18.4.14.4.8.0.10
a45:1.30.2.18.4.14.4.8.0.8
a46:1.30.2.18.4.14.4.8.0.6
a47:1.30.2.18.4.14.4.8.0.4
a48:1.30.2.18.4.14.4.8.0.2
a49:1.30.2.18.4.14.4.7.0.4
a50:1.30.2.18.4.14.4.7.0.2
a51:1.30.2.18.4.14.4.6.0.2
a52:1.30.2.18.4.14.4.3.4.1.0.2
a53:1.30.2.18.4.14.4.5.0.2
a54:1.30.2.18.4.14.4.5.0.14
a55:1.30.2.18.4.14.4.5.0.12
a56:1.30.2.18.4.14.4.5.0.10
a57:1.30.2.18.4.14.4.5.0.8
a58:1.30.2.18.4.14.4.5.0.6
a59:1.30.2.18.4.14.4.5.0.4
a60:1.30.2.18.4.14.4.3.0.4
a61:1.30.2.18.4.14.4.3.0.2
a62:1.30.2.18.4.14.4.2.0.16
a63:1.30.2.18.4.14.4.2.0.14
a64:1.30.2.18.4.14.4.2.0.12
a65:1.30.2.18.4.14.4.2.0.10
a66:1.30.2.18.4.14.4.2.0.8
a67:1.30.2.18.4.14.4.2.0.6
a68:1.30.2.18.4.14.4.2.0.4
a69:1.30.2.18.4.14.4.2.0.2
a70:1.30.2.18.4.14.4.1.0.4
a71:1.30.2.18.4.14.4.1.0.2
a72:1.30.2.18.4.14.0.4
a73:1.30.2.18.4.14.0.2
a74:1.30.2.18.4.13.0.2
a75:1.30.2.18.4.11.0.4
a76:1.30.2.18.4.11.0.2
a77:1.30.2.18.4.10.0.2
a78:1.30.2.18.4.6.0.2
a79:1.30.2.18.4.3.0.4
a80:1.30.2.18.4.5.0.4
a81:1.30.2.18.4.5.0.2
a82:1.30.2.18.4.3.0.2
a83:1.30.2.18.2.8.0.2
a84:1.30.2.18.4.1.0.8
a85:1.30.2.18.4.1.0.6
a86:1.30.2.18.4.1.0.4
a87:1.30.2.18.4.1.0.2
a88:1.30.2.18.0.4
a89:1.30.2.18.0.2
a90:1.30.2.14.0.2
a91:1.31.0.4
a92:1.31.0.2
a93:1.30.2.5.0.14
a94:1.30.2.5.0.12
a95:1.30.2.5.0.10
a96:1.30.2.5.0.6
a97:1.30.2.5.0.4
a98:1.30.2.5.0.2
a99:1.30.2.4.0.2
a100:1.30.2.3.0.8
a101:1.30.2.3.0.6
a102:1.30.2.3.0.2
a103:1.30.2.3.0.4
a104:1.30.2.1.0.2
a105:1.30.0.2
new-syscall-branch:1.14.0.2
V6_0-branch:1.6.0.2;
locks; strict;
comment @ * @;
1.31
date 2000.07.06.19.46.55; author x; state Exp;
branches
1.31.4.1;
next 1.30;
1.30
date 2000.07.06.17.21.26; author x; state Exp;
branches
1.30.2.1;
next 1.14;
1.14
date 99.03.09.23.33.53; author x; state Exp;
branches
1.14.6.1;
next ;
1.14.6.1
date 99.03.17.05.07.10; author x; state Exp;
branches;
next ;
1.30.2.1
date 2000.12.13.20.13.52; author x; state Exp;
branches;
next 1.30.2.3;
1.30.2.3
date 2001.03.28.18.40.01; author x; state Exp;
branches;
next 1.30.2.4;
1.30.2.4
date 2001.08.21.21.14.44; author x; state Exp;
branches;
next 1.30.2.5;
1.30.2.5
date 2001.10.17.20.05.09; author x; state Exp;
branches
1.30.2.5.8.1;
next 1.30.2.14;
1.30.2.14
date 2002.06.13.17.02.53; author x; state Exp;
branches;
next 1.30.2.18;
1.30.2.18
date 2002.07.18.22.25.03; author x; state Exp;
branches;
next ;
1.30.2.5.8.1
date 2002.01.29.00.03.25; author x; state Exp;
branches;
next ;
1.31.4.1
date 2002.04.16.22.46.40; author x; state Exp;
branches;
next ;
desc
@@
1.31
log
@6.5.0 version string, on the trunk.
@
text
@
@
1.31.4.1
log
@
@
text
@d35 1
a35 1
@
1.30
log
@
@
text
@d35 1
a35 1
@
1.30.2.1
log
@
@
text
@d35 1
a35 1
@
1.30.2.3
log
@
@
text
@d35 1
a35 1
@
1.30.2.4
log
@
@
text
@d35 1
a35 1
@
1.30.2.5
log
@
@
text
@d35 1
a35 1
@
1.30.2.14
log
@
@
text
@d35 1
a35 1
@
1.30.2.18
log
@
@
text
@d35 1
a35 1
@
1.30.2.5.8.1
log
@
@
text
@d35 1
a35 1
@
1.14
log
@
@
text
@d25 43
a67 1
s
d72 1
a72 1
C
d77 6
d84 1
@
1.14.6.1
log
@
@
text
@d25 1
a25 1
@
^ permalink raw reply related
* Re: cvs -> git tools?
From: Jakub Narebski @ 2007-12-21 22:07 UTC (permalink / raw)
To: Gonzalo Garramuño; +Cc: git
In-Reply-To: <476C1D9E.4060700@advancedsl.com.ar>
Gonzalo Garramuño <ggarra@advancedsl.com.ar> writes:
> Are there any good websites that can host a git repository? Something
> equivalent to sourceforge but for git.
Check out the end of the GitProjects page on GitWiki:
http://git.or.cz/gitwiki/GitProjects
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: cvs -> git tools?
From: Jakub Narebski @ 2007-12-21 22:02 UTC (permalink / raw)
To: Gonzalo Garramuño; +Cc: git
In-Reply-To: <476C1D9E.4060700@advancedsl.com.ar>
Gonzalo Garramuño <ggarra@advancedsl.com.ar> writes:
> I was wondering if there were any tools to keep a mirror repository of
> CVS as a git repository.
>
> Basically, I would like to mirror a CVS repository (that I don't
> control) as a git "main" branch. This CVS repository is live and
> expected to remain so.
>
> I would then work on another git branch and would do merges from the
> main branch to mine as I see fit to develop some stuff.
>
> Is there anything like that? Basically, I'm looking for the
> equivalent of Tailor for Mercurial.
Tailor supports Git, too.
There are many CVS -> git tools: git-cvsimport (uses cvsps), parsecvs
(accesses ,v files directly), fromcvs (in Ruby), cvs2svn development
branch. But I think only git-cvsimport allows incremental import.
Another solution would be to set Git repository as a fake CVS
repository using git-cvsserver (now with beginning of authenticated
pserver access!).
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* [FIXED PATCH] git-describe: Add a --match option to limit considered tags.
From: Pierre Habouzit @ 2007-12-21 21:49 UTC (permalink / raw)
To: Junio C Hamano, git
In-Reply-To: <20071221212212.GB10318@artemis.madism.org>
[-- Attachment #1: Type: text/plain, Size: 3051 bytes --]
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
On Fri, Dec 21, 2007 at 09:22:12PM +0000, Pierre Habouzit wrote:
> On Fri, Dec 21, 2007 at 05:52:29PM +0000, Junio C Hamano wrote:
> > Does it work with "describe --contains" as well?
Okay, you're right … Here is an updated patch.
Documentation/git-describe.txt | 4 ++++
builtin-describe.c | 21 ++++++++++++++++-----
2 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt
index ac23e28..cb869e9 100644
--- a/Documentation/git-describe.txt
+++ b/Documentation/git-describe.txt
@@ -51,6 +51,10 @@ OPTIONS
being employed to standard error. The tag name will still
be printed to standard out.
+--match <pattern>::
+ Only consider tags matching the given pattern (can be used to avoid
+ leaking private tags made from the repository).
+
EXAMPLES
--------
diff --git a/builtin-describe.c b/builtin-describe.c
index 7a148a2..dd44df9 100644
--- a/builtin-describe.c
+++ b/builtin-describe.c
@@ -19,6 +19,7 @@ static int all; /* Default to annotated tags only */
static int tags; /* But allow any tags if --tags is specified */
static int abbrev = DEFAULT_ABBREV;
static int max_candidates = 10;
+const char *pattern = NULL;
struct commit_name {
int prio; /* annotated tag = 2, tag = 1, head = 0 */
@@ -57,9 +58,11 @@ static int get_name(const char *path, const unsigned char *sha1, int flag, void
* Otherwise only annotated tags are used.
*/
if (!prefixcmp(path, "refs/tags/")) {
- if (object->type == OBJ_TAG)
+ if (object->type == OBJ_TAG) {
prio = 2;
- else
+ if (pattern && fnmatch(pattern, path + 10, 0))
+ prio = 0;
+ } else
prio = 1;
}
else
@@ -253,7 +256,9 @@ int cmd_describe(int argc, const char **argv, const char *prefix)
OPT_BOOLEAN(0, "tags", &tags, "use any tag in .git/refs/tags"),
OPT__ABBREV(&abbrev),
OPT_INTEGER(0, "candidates", &max_candidates,
- "consider <n> most recent tags (default: 10)"),
+ "consider <n> most recent tags (default: 10)"),
+ OPT_STRING(0, "match", &pattern, "pattern",
+ "only consider tags matching <pattern>"),
OPT_END(),
};
@@ -266,12 +271,18 @@ int cmd_describe(int argc, const char **argv, const char *prefix)
save_commit_buffer = 0;
if (contains) {
- const char **args = xmalloc((4 + argc) * sizeof(char*));
+ const char **args = xmalloc((5 + argc) * sizeof(char*));
int i = 0;
args[i++] = "name-rev";
args[i++] = "--name-only";
- if (!all)
+ if (!all) {
args[i++] = "--tags";
+ if (pattern) {
+ char *s = xmalloc(strlen("--refs=refs/tags/") + strlen(pattern) + 1);
+ sprintf(s, "--refs=refs/tags/%s", pattern);
+ args[i++] = s;
+ }
+ }
memcpy(args + i, argv, argc * sizeof(char*));
args[i + argc] = NULL;
return cmd_name_rev(i + argc, args, prefix);
--
1.5.4.rc1.1097.gd122b-dirty
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: [PATCH] Allow selection of different cleanup modes for commit messages
From: Junio C Hamano @ 2007-12-21 21:43 UTC (permalink / raw)
To: Alex Riesen; +Cc: Linus Torvalds, git
In-Reply-To: <20071221173521.GA3494@steel.home>
Alex Riesen <raa.lkml@gmail.com> writes:
> The patch is on top of my previos patches. Junio, if you wish, I can
> squash and resend.
That would be a sane thing to do.
^ permalink raw reply
* Re: [PATCH v2] Make git send-email accept $EDITOR with arguments
From: Gustaf Hendeby @ 2007-12-21 21:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: luciano, git
Sorry Junio for the double, but I didn't mean to cut the CCs on this one.
On 2007-12-21 18:02, Junio C Hamano wrote:
> Gustaf Hendeby <hendeby@isy.liu.se> writes:
>
>> Junio, even if this is technically not a bug fix, it would be nice to
>> get this fix into the 1.5.4 so that the usage of $EDITOR becomes more
>> consistent throughout git.
>
> I can buy that, but at least a single line comment in front of that
> system() explaining why this is safe to do so would be beneficial. I
> suspect that somebody would propose moving $compse_filename inside
> $GIT_DIR, now people realized $compose_filename is currently "./.msg.$$",
> and $GIT_DIR could be anything. Quotemeta would probably be better as the
> code you are touching won't be affected by a future change to the value of
> that constant defined far away in the source.
Moving that file makes sense, I'll have a look at that, and do that as
well when I fix this patch. After a first look at it though, I was
surprised to learn that git send-email actually wont work outside a
repository. Ok, I can't really see any workflow where git send-email is
called from outside a git repository, but at the same time I don't see
why is should not be possible. Are there any special reason for this?
Thanks,
Gustaf
^ permalink raw reply
* Re: [PATCH] git-describe: Add a --match option to limit considered tags.
From: Pierre Habouzit @ 2007-12-21 21:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7ij87x5u.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1094 bytes --]
On Fri, Dec 21, 2007 at 05:52:29PM +0000, Junio C Hamano wrote:
> Does it work with "describe --contains" as well?
I think so, the idea here is that I give prio "0" to tags that don't
match, which unless you pass --all (which basically conflicts with
--match <foo> anyways) means that those are not added to the list of
tags that are considered. So I don't see why it would fail with
--contains.
That's a patch we "need" at work because we have a repository with
different products that share a _lot_ of code (and we're not confident
with submodules yet to switch) and we use git-describe to embed the
exact version of the code that was shipped to a client. Though it sucks
when the last tag shows another product name :)
I'd also like to use it in some scripts of mine for debian packaging
where I have quite a lot of private tags and only want to describe tags
that match 'debian-sid*'
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] git-tag: fix -l switch handling regression.
From: Pierre Habouzit @ 2007-12-21 21:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd4t0atzo.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 894 bytes --]
On Fri, Dec 21, 2007 at 04:32:43PM +0000, Junio C Hamano wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
>
> > Signed-off-by: Pierre Habouzit <madcoder@debian.org>
> > ---
> >
> > It seems that you didnt took that patch either, that IMHO gives a better
> > semantics to git tag -l than yours, while keeping backward
> > compatibility.
>
> I thought this depended on some other changes. As is, doesn't
> it break the t7004 test?
Well there are tests that test:
git tag -n xxx -l ...
or
git tag -n "" -l ...
but I think we agreed those test nothing legitimate, and that the
tests have to be removed. SO yes it hides another patch to cleanse t7004
from the broken tests.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH v2] Make git send-email accept $EDITOR with arguments
From: Junio C Hamano @ 2007-12-21 21:17 UTC (permalink / raw)
To: Gustaf Hendeby; +Cc: Jeff King, luciano, git, gitster
In-Reply-To: <476C2B2E.1080801@isy.liu.se>
Gustaf Hendeby <hendeby@isy.liu.se> writes:
> On 2007-12-21 20:23, Jeff King wrote:
>
>> I am fine with using the shell. Though keep in mind that the two
>> solutions will behave differently with
>>
>> EDITOR='foo; bar'
>>
>> That is, system("$editor $message") will actually invoke the shell,
>> whereas system(split(/ /, $editor), $message) will _just_ split on
>> whitespace. We should do whatever is consistent with the rest of the git
>> commands (off the top of my head, I don't know).
Personally, I think EDITOR='foo; bar' is a user shooting his
foot off which we do not care about.
> A quick look at the proposed solution to the similar problem with git
> commit, using code now in git tag, it seems it uses a split like
> solution, though taking " and ' quoting into consideration.
I think the easiest to read and compatible way is:
system('sh', '-c', '$0 $@', $editor, $filename)
^ permalink raw reply
* Re: [PATCH v2] Make git send-email accept $EDITOR with arguments
From: Gustaf Hendeby @ 2007-12-21 21:07 UTC (permalink / raw)
To: Jeff King; +Cc: luciano, git, gitster
In-Reply-To: <20071221192359.GA10660@coredump.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 1490 bytes --]
On 2007-12-21 20:23, Jeff King wrote:
> On Fri, Dec 21, 2007 at 04:23:11PM +0100, Gustaf Hendeby wrote:
>
>>> If you are going to do it that way, I suspect you want to quotemeta
>>> $compose_filename.
>> Generally that would be true, but is that really necessary when I know
>> $compose_filename is defined as:
>>
>> my $compose_filename = ".msg.$$";
>
> I know; it is just easier to see that it is correct with the quotemeta
> (and correct in the face of somebody changing the message later).
Point taken!
>
>> Or, should I take it that you prefer the version using split? I didn't
>> really feel good about the possibility of splitting paths with spaces
>> that came with that one though.
>
> I am fine with using the shell. Though keep in mind that the two
> solutions will behave differently with
>
> EDITOR='foo; bar'
>
> That is, system("$editor $message") will actually invoke the shell,
> whereas system(split(/ /, $editor), $message) will _just_ split on
> whitespace. We should do whatever is consistent with the rest of the git
> commands (off the top of my head, I don't know).
A quick look at the proposed solution to the similar problem with git
commit, using code now in git tag, it seems it uses a split like
solution, though taking " and ' quoting into consideration. On the top
of my head I can't come up with any other commands using $EDITOR. I'll
try to find some time the next couple of days to make a reasonable
equivalent solution here.
Thanks,
Gustaf
[-- Attachment #2: hendeby.vcf --]
[-- Type: text/x-vcard, Size: 378 bytes --]
begin:vcard
fn:Gustaf Hendeby
n:Hendeby;Gustaf
org;quoted-printable:Link=C3=B6ping University;Department of Electrical Engineering
adr;quoted-printable:;;;Link=C3=B6ping;;SE-581 83;Sweden
email;internet:hendeby@isy.liu.se
title:PhD Student
tel;work:+46 (0)13 282226
tel;fax:+46 (0)13 282622
x-mozilla-html:FALSE
url:http://www.control.isy.liu.se/~hendeby
version:2.1
end:vcard
^ permalink raw reply
* Re: cvs -> git tools?
From: Pascal Obry @ 2007-12-21 20:46 UTC (permalink / raw)
To: Gonzalo Garramuño; +Cc: git
In-Reply-To: <476C1D9E.4060700@advancedsl.com.ar>
Gonzalo,
> I was wondering if there were any tools to keep a mirror repository of
> CVS as a git repository.
I'm no expert on this, maybe cvsimport. I'll let other answer.
http://www.kernel.org/pub/software/scm/git/docs/git-cvsimport.html
> As a second question...
>
> Are there any good websites that can host a git repository? Something
> equivalent to sourceforge but for git.
Savannah support Git.
There is also http://repo.or.cz
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* cvs -> git tools?
From: Gonzalo Garramuño @ 2007-12-21 20:10 UTC (permalink / raw)
To: git
I was wondering if there were any tools to keep a mirror repository of
CVS as a git repository.
Basically, I would like to mirror a CVS repository (that I don't
control) as a git "main" branch. This CVS repository is live and
expected to remain so.
I would then work on another git branch and would do merges from the
main branch to mine as I see fit to develop some stuff.
Is there anything like that? Basically, I'm looking for the equivalent
of Tailor for Mercurial.
---
As a second question...
Are there any good websites that can host a git repository? Something
equivalent to sourceforge but for git.
--
Gonzalo Garramuño
ggarra@advancedsl.com.ar
AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy
^ permalink raw reply
* Re: [PATCH v0] sha1_name: grok <revision>:./<relative-path>
From: Nguyen Thai Ngoc Duy @ 2007-12-21 20:15 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Dana How, Linus Torvalds, Alex Riesen,
Jakub Narebski, git
In-Reply-To: <7vbq8k7x91.fsf@gitster.siamese.dyndns.org>
On Dec 22, 2007 12:50 AM, Junio C Hamano <gitster@pobox.com> wrote:
> "Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
>
> >> Note that this patch does not handle "../", and neither do I plan to.
> >
> > Junio's rc1 announcement got me to read this. It would be indeed
> > useful as I usually work in deep subdirs. However, from my user
> > perspective, the right approach is to make <treeish>:path always be
> > relative to current directory. If you want absolute path, use
> > <treeish>:/path. More intuitive but it breaks current behavior.
>
> I do not know if you followed the discussion thread, but the
> <treeish>:relative-path has been shown to be broken semantics,
> so even if it may be "intuitive", it is intuitive only to people
> who do not understand the brokenness. Please read the one that
> Dscho talks about windows drive letter and Linus agrees that is
> a good analogy.
>
> It might be possible to do <commit>:relative and apply that only
> to direct user input, but I do not think it is worth the
> compatibility and complexity hassle.
Argh! I missed that thread. Will shut up now :-X Thanks for the pointer.
--
Duy
^ permalink raw reply
* Failed binary detection.
From: David Brown @ 2007-12-21 19:50 UTC (permalink / raw)
To: Git
A coworker has a branch with some large binary files (video test streams).
Git doesn't seem to be detecting this file is binary, and is causing things
that try to generate diffs to fail.
Specifically, he is unable to rebase his branch, getting an error:
.dotest/patch:3241:LD := ld
fatal: corrupt patch at line 84682
Patch failed at 0001.
Line 84682 is in the middle of what appear to be the binary contents of the
large media file, with pluses inserted after newline.
Any advice on where to look or possibly how to fix this?
I was able to work around the problem by cherry picking the change instead
of using rebase. git-format-patch generates a patch that is corrupt in the
same way, which fails with 'git-am'.
Thanks,
Dave
^ permalink raw reply
* Re: [PATCH] Make "git stash" configurable
From: Junio C Hamano @ 2007-12-21 19:48 UTC (permalink / raw)
To: Steven Grimm
Cc: しらいしななこ, git
In-Reply-To: <2AB285BD-DA6E-49D1-B664-B1A8B552DD76@midwinter.com>
Steven Grimm <koreth@midwinter.com> writes:
> On Dec 21, 2007, at 2:22 AM, しらいしななこ wrote:
>
>> "git stash" without argument originally created an unnamed
>> stash, but some people felt this can be confusing to new
>> users. This introduces per-user config variable stash.quick to
>> control this behavior.
>
> This whole thing smells of indecision to me.
If you want to force me to decide, you know what the decision it
would be. Here are the guiding principles and decisions based
on them.
(1) A tool should be optimized for people who know what it does
and how to use it.
While forbidding "git stash" without argument and forcing
people who want to have a quick stash to type "git stash
save" may appear not to be adding too many keystrokes, it
actually is a regression. Because "git stash save" without
arguments make a much less descriptive stash than the
current quickie "git stash", doing so slows them down by
forcing them to think of what message to give.
The decision would be to keep "git stash" quickie stash
creation. An alternative decision could be to do nothing
when "git stash" is given, and make "git stash save" (and
"git stash create") without the actual message to come up
with a better default message.
(2) A tool should not change its behaviour too drastically
depending on who the user is.
Otherwise it makes it harder for people with mid-level
experience to teach less experienced people. The decision
would be that "stash.quick=ask" and "stash.quick=no" are
unacceptable.
(3) A tool should support safety for a mistaken use by who know
the tool (even they can make mistakes).
I listed this mostly because we made "git clean" to violate
principle (2) above. Even when you know what that command
does, it is easy to mean "make clean" and type "git clean"
by mistake. And "git clean" is very destructive --- there
is no "oops, I take it back". This principle has led us to
introduce clean.requireforce that defaults to true.
For "git stash", there is no "make stash" or "xyzzy stash"
that can easily induce mistyping. Even if it were typed by
mistake, there is no such destructive "oops, I cannot take
it back" problem with "git stash", either. "git stash
apply" will get you back to where you were. The decision
would again be that "stash.quick=no" is unwanted.
(4) A tool should support safety for clueless people when it is
reasonable.
Even though "I did not know what command foo does, so I
tried running it and it did something unexpected" is a
silly excuse to rob quickie "git stash" from people who
know better, we cannot avoid the fact that there are
clueless people. I think checking stash.iknowwhatitdoes to
detect first-time users, and explaining what it does to
them, may make sense. And we can take hints from the patch
that started this thread how to do this.
The decision here is that I am open to a change that
implements the one-time safety instruction.
Note that in the above guiding principles, I used "should" in
RFC2119/BCP0014 sense: there may exist valid reasons in
particular circumstances to ignore a particular item, but the
full implications must be understood and carefully weighed
before choosing a different course.
^ 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