* Re: problems with importing from cvs archive
From: Jakub Narebski @ 2007-12-02 9:39 UTC (permalink / raw)
To: Ed S. Peschko; +Cc: git
In-Reply-To: <20071202064613.GB25351@venus>
"Ed S. Peschko" <esp5@pge.com> writes:
> I'm trying to use git-cvsimport to import from a CVS archive, using:
>
> git-cvsimport -d $CVSROOT
>
> and am getting the following error:
>
> 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
[...]
> Or is this just a plain vanilla bug?
I guess that you might have been bitten by (just corrected, but not in
any released version yet) the bug in git-cvsimport (which is quite
old, and not very well maintained) when branches are packed.
You can either try last patch to cvsimport (it is in 'master'),
or unpack refs using "git reset --soft HEAD" when on given packed
branch,
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH 0/3] Call builtin functions directly, was Re: [PATCH] transport.c: call dash-less form of receive-pack and upload-pack on remote
From: Johannes Schindelin @ 2007-12-02 11:35 UTC (permalink / raw)
To: Junio C Hamano
Cc: Eyvind Bernhardsen, Nicolas Pitre, Nguyen Thai Ngoc Duy,
Jan Hudec, git
In-Reply-To: <7v3aul1xmt.fsf@gitster.siamese.dyndns.org>
Hi,
On Sat, 1 Dec 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Okay, I bit the apple and tried to move the builtins into the library,
> > and rename handle_internal_command into execv_git_builtin(), moving it
> > into exec-cmd.c.
> >
> > Big mistake.
>
> I really feel this should not go in.
Hmm.
My rationale was not only avoiding an exec() (which I would find worth it
on its own), but because this would be a non-verbal step towards
libification.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 6/6] builtin-commit: Add newline when showing which commit was created
From: Johannes Schindelin @ 2007-12-02 12:13 UTC (permalink / raw)
To: Jeff King; +Cc: git, krh, gitster
In-Reply-To: <20071202054030.GA393@coredump.intra.peff.net>
Hi,
On Sun, 2 Dec 2007, Jeff King wrote:
> On Sat, Dec 01, 2007 at 10:41:47PM +0000, Johannes Schindelin wrote:
>
> > Basically, I ran a test case in which the shell script was different from
> > the builtin version, and this was the patch that fixed it for me.
> >
> > Maybe it should have been
> >
> > if (log_tree_commit(&rev, commit))
> > printf("\n");
> >
> > at the end of print_summary() instead. Can you try if that fixes it for
> > you?
>
> No, it doesn't, unless you meant "if (!log_tree_commit(...". Of course,
> I can't get log_tree_commit to return anything but true anyway (either
> log_tree_diff shows something, or since we have set always_show_header,
> we end up calling show_log).
>
> It would be helpful if you could remember the test case, but perhaps
> that is not an option at this point.
IIRC it was "git commit -m bla".
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH 2/3] Avoid double exec() in execv_git_cmd()
From: Johannes Schindelin @ 2007-12-02 12:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1196579005-5662-2-git-send-email-gitster@pobox.com>
Hi,
On Sat, 1 Dec 2007, Junio C Hamano wrote:
> This avoids double exec() when execv_git_cmd() is used to spawn an
> external git command.
>
> For this, execv_git_cmd() needs to be able to tell what's built-in.
> This is done by introducing a new function git_builtin_command() that
> checks the list of built-in commands and returns a pointer to the
> cmd_struct if found. The same function is used from the git potty.
IMNSHO this does not buy us anything, compared to my patch series. Your
patch is larger, distributes the responsibility for the builtins to two
files instead of one, and since we control what is builtin and what not,
is not really less fragile with respect to what needs to be initialised.
Besides, we lose a great opportunity to go in the direction of
libification.
Ciao,
Dscho
^ permalink raw reply
* make test failure with latest master
From: A Large Angry SCM @ 2007-12-02 12:29 UTC (permalink / raw)
To: git; +Cc: gitster, peff
[Resent due to incorrect list address.]
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
* ok 4: pack refs
* ok 5: update cvs module
* 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
* ok 7: update cvs module
* 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
* Re: make test failure with latest master
From: Jakub Narebski @ 2007-12-02 12:52 UTC (permalink / raw)
To: A Large Angry SCM; +Cc: git, gitster, peff
In-Reply-To: <4752A53E.4030000@gmail.com>
A Large Angry SCM <gitzilla@gmail.com> writes:
> [Resent due to incorrect list address.]
>
> 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 ***
Trivial question: have you got cvs and cvsps installed?
--
Jakub Narebski
^ permalink raw reply
* [PATCH] Fixes for automatic prefix highlighting
From: Wincent Colaiuta @ 2007-12-02 13:44 UTC (permalink / raw)
To: git; +Cc: gitster, Wincent Colaiuta
These changes make the automatic prefix highlighting work with the "Add
untracked" subcommand in git-add--interactive by explicitly handling
arrays, hashes and strings internally (previously only arrays and hashes
were handled).
In addition, prefixes which have special meaning for list_and_choose
(things like "*" for "all" and "-" for "deselect) are explicitly
excluded (highlighting these prefixes would be misleading).
Signed-off-by: Wincent Colaiuta <win@wincent.com>
---
El 1/12/2007, a las 19:04, Junio C Hamano escribió:
> I've locally munged and pushed out the results before sending the
> message you are responding to. Sorry, I should have been clearer (and
> this is the second time with you if I recall correctly).
Sorry, Junio. I do fetch, inspect and integrate changes fairly
regularly, but I missed that one.
This patch which I am sending now applies on top of "next" (as fetched a
few minutes ago).
git-add--interactive.perl | 47 ++++++++++++++++++++++++++++----------------
1 files changed, 30 insertions(+), 17 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 23fd2f7..32fb9ea 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -193,7 +193,7 @@ sub find_unique_prefixes {
if ((ref $print) eq 'ARRAY') {
$print = $print->[0];
}
- else {
+ elsif ((ref $print) eq 'HASH') {
$print = $print->{VALUE};
}
update_trie(\%trie, $print);
@@ -230,12 +230,25 @@ sub find_unique_prefixes {
return @return;
}
+# filters out prefixes which have special meaning to list_and_choose()
+sub is_valid_prefix {
+ my $prefix = shift;
+ return (defined $prefix) &&
+ !($prefix =~ /[\s,]/) && # separators
+ !($prefix =~ /^-/) && # deselection
+ !($prefix =~ /^\d+/) && # selection
+ ($prefix ne '*'); # "all" wildcard
+}
+
# given a prefix/remainder tuple return a string with the prefix highlighted
# for now use square brackets; later might use ANSI colors (underline, bold)
sub highlight_prefix {
my $prefix = shift;
my $remainder = shift;
- return (defined $prefix) ? "[$prefix]$remainder" : $remainder;
+ return $remainder unless defined $prefix;
+ return is_valid_prefix($prefix) ?
+ "[$prefix]$remainder" :
+ "$prefix$remainder";
}
sub list_and_choose {
@@ -257,21 +270,21 @@ sub list_and_choose {
for ($i = 0; $i < @stuff; $i++) {
my $chosen = $chosen[$i] ? '*' : ' ';
my $print = $stuff[$i];
- if (ref $print) {
- if ((ref $print) eq 'ARRAY') {
- $print = @prefixes ?
- highlight_prefix(@{$prefixes[$i]}) :
- $print->[0];
- }
- else {
- my $value = @prefixes ?
- highlight_prefix(@{$prefixes[$i]}) :
- $print->{VALUE};
- $print = sprintf($status_fmt,
- $print->{INDEX},
- $print->{FILE},
- $value);
- }
+ my $ref = ref $print;
+ my $highlighted = highlight_prefix(@{$prefixes[$i]})
+ if @prefixes;
+ if ($ref eq 'ARRAY') {
+ $print = $highlighted || $print->[0];
+ }
+ elsif ($ref eq 'HASH') {
+ my $value = $highlighted || $print->{VALUE};
+ $print = sprintf($status_fmt,
+ $print->{INDEX},
+ $print->{FILE},
+ $value);
+ }
+ else {
+ $print = $highlighted || $print;
}
printf("%s%2d: %s", $chosen, $i+1, $print);
if (($opts->{LIST_FLAT}) &&
--
1.5.3.6.953.gdffc
^ permalink raw reply related
* Re: make test failure with latest master
From: A Large Angry SCM @ 2007-12-02 14:01 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, gitster, peff
In-Reply-To: <m3fxylw95y.fsf@roke.D-201>
Jakub Narebski wrote:
> A Large Angry SCM <gitzilla@gmail.com> writes:
>
>> [Resent due to incorrect list address.]
>>
>> 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 ***
>
> Trivial question: have you got cvs and cvsps installed?
>
Yes. With the following (rpm based) versions:
cvs-1.12.12-2.1
cvsps-1.99-155.2
cvsup-16.1h-173
viewcvs-1.0-11
^ permalink raw reply
* Difference in how "git status" and "git diff --name-only" lists filenames
From: Gustaf Hendeby @ 2007-12-02 14:04 UTC (permalink / raw)
To: git
A while ago 'git status' was patched to report relative pathnames. (I
like that change it makes cut'n'paste easier.) However, 'git diff
--name-only' and 'git diff --name-status' (other commands as well),
which gives in a sense similar output has not been changed the same
way. Is this intentionally, or just because no one has stepped up and
provided a patch? If the difference is to stay, maybe this should be
reflected in the help texts to avoid any confusion.
/Gustaf
^ permalink raw reply
* Re: [PATCH] Highlight keyboard shortcuts in git-add--interactive
From: Wincent Colaiuta @ 2007-12-02 14:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, dzwell, peff, Matthieu.Moy
In-Reply-To: <7vy7cf87jz.fsf@gitster.siamese.dyndns.org>
El 1/12/2007, a las 3:36, Junio C Hamano escribió:
> When list_and_choose() function is letting you choose more than one
> items, its prompt becomes ">> ", instead of "> " that is used for a
> singleton choice. To that prompt, you can say "3-7" (Add these 5
> items
> to the choice), "*" (I want all of them), "-2-4" (exclude 2 and 3
> and 4
> from the set I have chosen so far). These are also "hidden", and need
> to be documented, but that would be a separate patch.
I was just about to prepare some documentation for this when I saw
that it is already documented, and by none other than you, Junio! (see
6a5ad23d).
Unless by "documentation" you meant to somehow expose these in the
interface at runtime... something like this? (applied on top of the
patch I just sent to the list):
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 32fb9ea..e7b07ee 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -237,7 +237,8 @@ sub is_valid_prefix {
!($prefix =~ /[\s,]/) && # separators
!($prefix =~ /^-/) && # deselection
!($prefix =~ /^\d+/) && # selection
- ($prefix ne '*'); # "all" wildcard
+ ($prefix ne '*') && # "all" wildcard
+ ($prefix ne '?'); # prompt help
}
# given a prefix/remainder tuple return a string with the prefix
highlighted
@@ -308,7 +309,7 @@ sub list_and_choose {
print "> ";
}
else {
- print ">> ";
+ print " (?)>> ";
}
my $line = <STDIN>;
if (!$line) {
@@ -318,6 +319,10 @@ sub list_and_choose {
}
chomp $line;
last if $line eq '';
+ if ($line eq '?' && !$opts->{SINGLETON}) {
+ prompt_help_cmd();
+ next TOPLOOP;
+ }
for my $choice (split(/[\s,]+/, $line)) {
my $choose = 1;
my ($bottom, $top);
@@ -363,6 +368,19 @@ sub list_and_choose {
return @return;
}
+sub prompt_help_cmd {
+ print <<\EOF ;
+Prompt help:
+1 - select a single item
+3-5 - select a range of items
+2-3,6-9 - select multiple ranges
+foo - select item based on unique prefix
+-... - unselect specified items
+* - choose all items
+ - (empty) finish selecting
+EOF
+}
+
sub status_cmd {
list_and_choose({ LIST_ONLY => 1, HEADER => $status_head },
list_modified());
Cheers,
Wincent
^ permalink raw reply related
* [PATCH, next version] Add 'git fast-export', the sister of 'git fast-import'
From: Johannes Schindelin @ 2007-12-02 14:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzlwv6sxr.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 19337 bytes --]
This program dumps (parts of) a git repository in the format that
fast-import understands.
For clarity's sake, it does not use the 'inline' method of specifying
blobs in the commits, but builds the blobs before building the commits.
Since signed tags' signatures will not necessarily be valid (think
transformations after the export, or excluding revisions, changing
the history), there are 4 modes to handle them: abort (default),
ignore, warn and strip. The latter just turns the tags into
unsigned ones.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Fri, 30 Nov 2007, Junio C Hamano wrote:
> * js/fast-export (Sun Nov 25 22:37:20 2007 +0100) 1 commit
> - Add 'git fast-export', the sister of 'git fast-import'
>
> This needs something like
> 9e42d6a1c53dadd409fab11cc76e0eba9ec15365 (sha1_file.c: Fix
> size_t related printf format warnings) to compile, I think, but
> I haven't tried to fix it (parked in pu)
How about this instead?
(It uses ((uint32_t *)NULL) + number, which should be quite
portable.)
.gitignore | 1 +
Documentation/git-fast-export.txt | 83 ++++++++
Makefile | 1 +
builtin-fast-export.c | 410 +++++++++++++++++++++++++++++++++++++
builtin.h | 1 +
t/t9301-fast-export.sh | 124 +++++++++++
6 files changed, 620 insertions(+), 0 deletions(-)
create mode 100644 Documentation/git-fast-export.txt
create mode 100755 builtin-fast-export.c
create mode 100755 t/t9301-fast-export.sh
diff --git a/.gitignore b/.gitignore
index 6564618..8694d02 100644
--- a/.gitignore
+++ b/.gitignore
@@ -35,6 +35,7 @@ git-diff-files
git-diff-index
git-diff-tree
git-describe
+git-fast-export
git-fast-import
git-fetch
git-fetch--tool
diff --git a/Documentation/git-fast-export.txt b/Documentation/git-fast-export.txt
new file mode 100644
index 0000000..073ff7f
--- /dev/null
+++ b/Documentation/git-fast-export.txt
@@ -0,0 +1,83 @@
+git-fast-export(1)
+==================
+
+NAME
+----
+git-fast-export - Git data exporter
+
+
+SYNOPSIS
+--------
+'git-fast-export [options]' | 'git-fast-import'
+
+DESCRIPTION
+-----------
+This program dumps the given revisions in a form suitable to be piped
+into gitlink:git-fast-import[1].
+
+You can use it as a human readable bundle replacement (see
+gitlink:git-bundle[1]), or as a kind of an interactive
+gitlink:git-filter-branch[1].
+
+
+OPTIONS
+-------
+--progress=<n>::
+ Insert 'progress' statements every <n> objects, to be shown by
+ gitlink:git-fast-import[1] during import.
+
+--signed-tags=(ignore|warn|strip|abort)::
+ Specify how to handle signed tags. Since any transformation
+ after the export can change the tag names (which can also happen
+ when excluding revisions) the signatures will not match.
++
+When asking to 'abort' (which is the default), this program will die
+when encountering a signed tag. With 'strip', the tags will be made
+unsigned, with 'ignore', they will be silently ignored (i.e. not exported)
+and with 'warn', they will be exported, but you will see a warning.
+
+
+EXAMPLES
+--------
+
+-------------------------------------------------------------------
+$ git fast-export --all | (cd /empty/repository && git fast-import)
+-------------------------------------------------------------------
+
+This will export the whole repository and import it into the existing
+empty repository. Except for reencoding commits that are not in
+UTF-8, it would be a one-to-one mirror.
+
+-----------------------------------------------------
+$ git fast-export master~5..master |
+ sed "s|refs/heads/master|refs/heads/other|" |
+ git fast-import
+-----------------------------------------------------
+
+This makes a new branch called 'other' from 'master~5..master'
+(i.e. if 'master' has linear history, it will take the last 5 commits).
+
+Note that this assumes that none of the blobs and commit messages
+referenced by that revision range contains the string
+'refs/heads/master'.
+
+
+Limitations
+-----------
+
+Since gitlink:git-fast-import[1] cannot tag trees, you will not be
+able to export the linux-2.6.git repository completely, as it contains
+a tag referencing a tree instead of a commit.
+
+
+Author
+------
+Written by Johannes E. Schindelin <johannes.schindelin@gmx.de>.
+
+Documentation
+--------------
+Documentation by Johannes E. Schindelin <johannes.schindelin@gmx.de>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
diff --git a/Makefile b/Makefile
index 6b9131b..f9a62eb 100644
--- a/Makefile
+++ b/Makefile
@@ -338,6 +338,7 @@ BUILTIN_OBJS = \
builtin-diff-files.o \
builtin-diff-index.o \
builtin-diff-tree.o \
+ builtin-fast-export.o \
builtin-fetch.o \
builtin-fetch-pack.o \
builtin-fetch--tool.o \
diff --git a/builtin-fast-export.c b/builtin-fast-export.c
new file mode 100755
index 0000000..570bce6
--- /dev/null
+++ b/builtin-fast-export.c
@@ -0,0 +1,410 @@
+/*
+ * "git fast-export" builtin command
+ *
+ * Copyright (C) 2007 Johannes E. Schindelin
+ */
+#include "builtin.h"
+#include "cache.h"
+#include "commit.h"
+#include "object.h"
+#include "tag.h"
+#include "diff.h"
+#include "diffcore.h"
+#include "log-tree.h"
+#include "revision.h"
+#include "decorate.h"
+#include "path-list.h"
+#include "utf8.h"
+#include "parse-options.h"
+
+/*
+ * TODO:
+ * - tags (--signed-tags=(ignore|warn|strip|abort)
+ */
+
+static const char *fast_export_usage[] = {
+ "git-fast-export [rev-list-opts]",
+ NULL
+};
+
+static int progress;
+static enum { IGNORE, WARN, STRIP, ABORT } signed_tag_mode = ABORT;
+
+static int parse_opt_signed_tag_mode(const struct option *opt,
+ const char *arg, int unset)
+{
+ if (unset || !strcmp(arg, "abort"))
+ signed_tag_mode = ABORT;
+ else if (!strcmp(arg, "ignore"))
+ signed_tag_mode = IGNORE;
+ else if (!strcmp(arg, "warn"))
+ signed_tag_mode = WARN;
+ else if (!strcmp(arg, "strip"))
+ signed_tag_mode = STRIP;
+ else
+ return error("Unknown signed-tag mode: %s", arg);
+ return 0;
+}
+
+static struct decoration idnums;
+static uint32_t last_idnum;
+
+static int has_unshown_parent(struct commit *commit)
+{
+ struct commit_list *parent;
+
+ for (parent = commit->parents; parent; parent = parent->next)
+ if (!(parent->item->object.flags & SHOWN) &&
+ !(parent->item->object.flags & UNINTERESTING))
+ return 1;
+ return 0;
+}
+
+/* Since intptr_t is C99, we do not use it here */
+static void mark_object(struct object *object)
+{
+ last_idnum++;
+ add_decoration(&idnums, object, ((uint32_t *)NULL) + last_idnum);
+}
+
+static int get_object_mark(struct object *object)
+{
+ void *decoration = lookup_decoration(&idnums, object);
+ if (!decoration)
+ return 0;
+ return (uint32_t *)decoration - (uint32_t *)NULL;
+}
+
+static void show_progress(void)
+{
+ static int counter = 0;
+ if (!progress)
+ return;
+ if ((++counter % progress) == 0)
+ printf("progress %d objects\n", counter);
+}
+
+static void handle_object(const unsigned char *sha1)
+{
+ unsigned long size;
+ enum object_type type;
+ char *buf;
+ struct object *object;
+
+ if (is_null_sha1(sha1))
+ return;
+
+ object = parse_object(sha1);
+ if (!object)
+ die ("Could not read blob %s", sha1_to_hex(sha1));
+
+ if (object->flags & SHOWN)
+ return;
+
+ buf = read_sha1_file(sha1, &type, &size);
+ if (!buf)
+ die ("Could not read blob %s", sha1_to_hex(sha1));
+
+ mark_object(object);
+
+ printf("blob\nmark :%d\ndata %lu\n", last_idnum, size);
+ if (fwrite(buf, size, 1, stdout) != 1)
+ die ("Could not write blob %s", sha1_to_hex(sha1));
+ printf("\n");
+
+ show_progress();
+
+ object->flags |= SHOWN;
+ free(buf);
+}
+
+static void show_filemodify(struct diff_queue_struct *q,
+ struct diff_options *options, void *data)
+{
+ int i;
+ for (i = 0; i < q->nr; i++) {
+ struct diff_filespec *spec = q->queue[i]->two;
+ if (is_null_sha1(spec->sha1))
+ printf("D %s\n", spec->path);
+ else {
+ struct object *object = lookup_object(spec->sha1);
+ printf("M 0%06o :%d %s\n", spec->mode,
+ get_object_mark(object), spec->path);
+ }
+ }
+}
+
+static const char *find_encoding(const char *begin, const char *end)
+{
+ const char *needle = "\nencoding ";
+ char *bol, *eol;
+
+ bol = memmem(begin, end ? end - begin : strlen(begin),
+ needle, strlen(needle));
+ if (!bol)
+ return git_commit_encoding;
+ bol += strlen(needle);
+ eol = strchrnul(bol, '\n');
+ *eol = '\0';
+ return bol;
+}
+
+static void handle_commit(struct commit *commit, struct rev_info *rev)
+{
+ int saved_output_format = rev->diffopt.output_format;
+ const char *author, *author_end, *committer, *committer_end;
+ const char *encoding, *message;
+ char *reencoded = NULL;
+ struct commit_list *p;
+ int i;
+
+ rev->diffopt.output_format = DIFF_FORMAT_CALLBACK;
+
+ parse_commit(commit);
+ author = strstr(commit->buffer, "\nauthor ");
+ if (!author)
+ die ("Could not find author in commit %s",
+ sha1_to_hex(commit->object.sha1));
+ author++;
+ author_end = strchrnul(author, '\n');
+ committer = strstr(author_end, "\ncommitter ");
+ if (!committer)
+ die ("Could not find committer in commit %s",
+ sha1_to_hex(commit->object.sha1));
+ committer++;
+ committer_end = strchrnul(committer, '\n');
+ message = strstr(committer_end, "\n\n");
+ encoding = find_encoding(committer_end, message);
+ if (message)
+ message += 2;
+
+ if (commit->parents) {
+ parse_commit(commit->parents->item);
+ diff_tree_sha1(commit->parents->item->tree->object.sha1,
+ commit->tree->object.sha1, "", &rev->diffopt);
+ }
+ else
+ diff_root_tree_sha1(commit->tree->object.sha1,
+ "", &rev->diffopt);
+
+ for (i = 0; i < diff_queued_diff.nr; i++)
+ handle_object(diff_queued_diff.queue[i]->two->sha1);
+
+ mark_object(&commit->object);
+ if (!is_encoding_utf8(encoding))
+ reencoded = reencode_string(message, "UTF-8", encoding);
+ printf("commit %s\nmark :%d\n%.*s\n%.*s\ndata %u\n%s",
+ (const char *)commit->util, last_idnum,
+ (int)(author_end - author), author,
+ (int)(committer_end - committer), committer,
+ reencoded ? strlen(reencoded) : message ? strlen(message) : 0,
+ reencoded ? reencoded : message ? message : "");
+ if (reencoded)
+ free(reencoded);
+
+ for (i = 0, p = commit->parents; p; p = p->next) {
+ int mark = get_object_mark(&p->item->object);
+ if (!mark)
+ continue;
+ if (i == 0)
+ printf("from :%d\n", mark);
+ else if (i == 1)
+ printf("merge :%d", mark);
+ else
+ printf(" :%d", mark);
+ i++;
+ }
+ if (i > 1)
+ printf("\n");
+
+ log_tree_diff_flush(rev);
+ rev->diffopt.output_format = saved_output_format;
+
+ printf("\n");
+
+ show_progress();
+}
+
+static void handle_tail(struct object_array *commits, struct rev_info *revs)
+{
+ struct commit *commit;
+ while (commits->nr) {
+ commit = (struct commit *)commits->objects[commits->nr - 1].item;
+ if (has_unshown_parent(commit))
+ return;
+ handle_commit(commit, revs);
+ commits->nr--;
+ }
+}
+
+static void handle_tag(const char *name, struct tag *tag)
+{
+ unsigned long size;
+ enum object_type type;
+ char *buf;
+ const char *tagger, *tagger_end, *message;
+ size_t message_size = 0;
+
+ buf = read_sha1_file(tag->object.sha1, &type, &size);
+ if (!buf)
+ die ("Could not read tag %s", sha1_to_hex(tag->object.sha1));
+ message = memmem(buf, size, "\n\n", 2);
+ if (message) {
+ message += 2;
+ message_size = strlen(message);
+ }
+ tagger = memmem(buf, message ? message - buf : size, "\ntagger ", 8);
+ if (!tagger)
+ die ("No tagger for tag %s", sha1_to_hex(tag->object.sha1));
+ tagger++;
+ tagger_end = strchrnul(tagger, '\n');
+
+ /* handle signed tags */
+ if (message) {
+ const char *signature = strstr(message,
+ "\n-----BEGIN PGP SIGNATURE-----\n");
+ if (signature)
+ switch(signed_tag_mode) {
+ case ABORT:
+ die ("Encountered signed tag %s; use "
+ "--signed-tag=<mode> to handle it.",
+ sha1_to_hex(tag->object.sha1));
+ case WARN:
+ warning ("Exporting signed tag %s",
+ sha1_to_hex(tag->object.sha1));
+ /* fallthru */
+ case IGNORE:
+ break;
+ case STRIP:
+ message_size = signature + 1 - message;
+ break;
+ }
+ }
+
+ if (!prefixcmp(name, "refs/tags/"))
+ name += 10;
+ printf("tag %s\nfrom :%d\n%.*s\ndata %d\n%.*s\n",
+ name, get_object_mark(tag->tagged),
+ (int)(tagger_end - tagger), tagger,
+ (int)message_size, message_size, message ? message : "");
+}
+
+static void get_tags_and_duplicates(struct object_array *pending,
+ struct path_list *extra_refs)
+{
+ struct commit *commit;
+ struct tag *tag;
+ int i;
+
+ for (i = 0; i < pending->nr; i++) {
+ struct object_array_entry *e = pending->objects + i;
+ unsigned char sha1[20];
+ char *full_name;
+
+ if (dwim_ref(e->name, strlen(e->name), sha1, &full_name) != 1)
+ continue;
+
+ switch (e->item->type) {
+ case OBJ_COMMIT:
+ commit = (struct commit *)e->item;
+ break;
+ case OBJ_TAG:
+ tag = (struct tag *)e->item;
+ while (tag && tag->object.type == OBJ_TAG) {
+ path_list_insert(full_name, extra_refs)->util
+ = tag;
+ tag = (struct tag *)tag->tagged;
+ }
+ if (!tag)
+ die ("Tag %s points nowhere?", e->name);
+ switch(tag->object.type) {
+ case OBJ_COMMIT:
+ commit = (struct commit *)tag;
+ break;
+ case OBJ_BLOB:
+ handle_object(tag->object.sha1);
+ continue;
+ }
+ break;
+ default:
+ die ("Unexpected object of type %s",
+ typename(e->item->type));
+ }
+ if (commit->util)
+ /* more than one name for the same object */
+ path_list_insert(full_name, extra_refs)->util = commit;
+ else
+ commit->util = full_name;
+ }
+}
+
+static void handle_tags_and_duplicates(struct path_list *extra_refs)
+{
+ struct commit *commit;
+ int i;
+
+ for (i = extra_refs->nr - 1; i >= 0; i--) {
+ const char *name = extra_refs->items[i].path;
+ struct object *object = extra_refs->items[i].util;
+ switch (object->type) {
+ case OBJ_TAG:
+ handle_tag(name, (struct tag *)object);
+ break;
+ case OBJ_COMMIT:
+ /* create refs pointing to already seen commits */
+ commit = (struct commit *)object;
+ printf("reset %s\nfrom :%d\n\n", name,
+ get_object_mark(&commit->object));
+ show_progress();
+ break;
+ }
+ }
+}
+
+int cmd_fast_export(int argc, const char **argv, const char *prefix)
+{
+ struct rev_info revs;
+ struct object_array commits = { 0, 0, NULL };
+ struct path_list extra_refs = { NULL, 0, 0, 0 };
+ struct commit *commit;
+ struct option options[] = {
+ OPT_INTEGER(0, "progress", &progress,
+ "show progress after <n> objects"),
+ OPT_CALLBACK(0, "signed-tags", &signed_tag_mode, "mode",
+ "select handling of signed tags",
+ parse_opt_signed_tag_mode),
+ OPT_END()
+ };
+
+ /* we handle encodings */
+ git_config(git_default_config);
+
+ init_revisions(&revs, prefix);
+ argc = setup_revisions(argc, argv, &revs, NULL);
+ argc = parse_options(argc, argv, options, fast_export_usage, 0);
+ if (argc > 1)
+ usage_with_options (fast_export_usage, options);
+
+ get_tags_and_duplicates(&revs.pending, &extra_refs);
+
+ prepare_revision_walk(&revs);
+ revs.diffopt.format_callback = show_filemodify;
+ DIFF_OPT_SET(&revs.diffopt, RECURSIVE);
+ while ((commit = get_revision(&revs))) {
+ if (has_unshown_parent(commit)) {
+ struct commit_list *parent = commit->parents;
+ add_object_array(&commit->object, NULL, &commits);
+ for (; parent; parent = parent->next)
+ if (!parent->item->util)
+ parent->item->util = commit->util;
+ }
+ else {
+ handle_commit(commit, &revs);
+ handle_tail(&commits, &revs);
+ }
+ }
+
+ handle_tags_and_duplicates(&extra_refs);
+
+ return 0;
+}
diff --git a/builtin.h b/builtin.h
index 3055bcc..142ab63 100644
--- a/builtin.h
+++ b/builtin.h
@@ -33,6 +33,7 @@ extern int cmd_diff_files(int argc, const char **argv, const char *prefix);
extern int cmd_diff_index(int argc, const char **argv, const char *prefix);
extern int cmd_diff(int argc, const char **argv, const char *prefix);
extern int cmd_diff_tree(int argc, const char **argv, const char *prefix);
+extern int cmd_fast_export(int argc, const char **argv, const char *prefix);
extern int cmd_fetch(int argc, const char **argv, const char *prefix);
extern int cmd_fetch_pack(int argc, const char **argv, const char *prefix);
extern int cmd_fetch__tool(int argc, const char **argv, const char *prefix);
diff --git a/t/t9301-fast-export.sh b/t/t9301-fast-export.sh
new file mode 100755
index 0000000..59f6996
--- /dev/null
+++ b/t/t9301-fast-export.sh
@@ -0,0 +1,124 @@
+#!/bin/sh
+#
+# Copyright (c) 2007 Johannes E. Schindelin
+#
+
+test_description='git-fast-export'
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+
+ echo Wohlauf > file &&
+ git add file &&
+ test_tick &&
+ git commit -m initial &&
+ echo die Luft > file &&
+ echo geht frisch > file2 &&
+ git add file file2 &&
+ test_tick &&
+ git commit -m second &&
+ echo und > file2 &&
+ test_tick &&
+ git commit -m third file2 &&
+ test_tick &&
+ git tag rein &&
+ git checkout -b wer HEAD^ &&
+ echo lange > file2
+ test_tick &&
+ git commit -m sitzt file2 &&
+ test_tick &&
+ git tag -a -m valentin muss &&
+ git merge -s ours master
+
+'
+
+test_expect_success 'fast-export | fast-import' '
+
+ MASTER=$(git rev-parse --verify master) &&
+ REIN=$(git rev-parse --verify rein) &&
+ WER=$(git rev-parse --verify wer) &&
+ MUSS=$(git rev-parse --verify muss) &&
+ mkdir new &&
+ git --git-dir=new/.git init &&
+ git fast-export --all |
+ (cd new &&
+ git fast-import &&
+ test $MASTER = $(git rev-parse --verify refs/heads/master) &&
+ test $REIN = $(git rev-parse --verify refs/tags/rein) &&
+ test $WER = $(git rev-parse --verify refs/heads/wer) &&
+ test $MUSS = $(git rev-parse --verify refs/tags/muss))
+
+'
+
+test_expect_success 'fast-export master~2..master' '
+
+ git fast-export master~2..master |
+ sed "s/master/partial/" |
+ (cd new &&
+ git fast-import &&
+ test $MASTER != $(git rev-parse --verify refs/heads/partial) &&
+ git diff master..partial &&
+ git diff master^..partial^ &&
+ ! git rev-parse partial~2)
+
+'
+
+test_expect_success 'iso-8859-1' '
+
+ git config i18n.commitencoding ISO-8859-1 &&
+ # use author and committer name in ISO-8859-1 to match it.
+ . ../t3901-8859-1.txt &&
+ test_tick &&
+ echo rosten >file &&
+ git commit -s -m den file &&
+ git fast-export wer^..wer |
+ sed "s/wer/i18n/" |
+ (cd new &&
+ git fast-import &&
+ git cat-file commit i18n | grep "Áéí óú")
+
+'
+
+cat > signed-tag-import << EOF
+tag sign-your-name
+from $(git rev-parse HEAD)
+tagger C O Mitter <committer@example.com> 1112911993 -0700
+data 210
+A message for a sign
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v1.4.5 (GNU/Linux)
+
+fakedsignaturefakedsignaturefakedsignaturefakedsignaturfakedsign
+aturefakedsignaturefake=
+=/59v
+-----END PGP SIGNATURE-----
+EOF
+
+test_expect_success 'set up faked signed tag' '
+
+ cat signed-tag-import | git fast-import
+
+'
+
+test_expect_success 'signed-tags=abort' '
+
+ ! git fast-export --signed-tags=abort sign-your-name
+
+'
+
+test_expect_success 'signed-tags=ignore' '
+
+ git fast-export --signed-tags=ignore sign-your-name > output &&
+ grep PGP output
+
+'
+
+test_expect_success 'signed-tags=strip' '
+
+ git fast-export --signed-tags=strip sign-your-name > output &&
+ ! grep PGP output
+
+'
+
+test_done
+
--
1.5.3.6.2112.ge2263
^ permalink raw reply related
* Re: What's cooking in git.git (topics)
From: Johannes Schindelin @ 2007-12-02 14:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzlwv6sxr.fsf@gitster.siamese.dyndns.org>
Hi,
On Fri, 30 Nov 2007, Junio C Hamano wrote:
> * js/dashless (Fri Nov 30 12:08:20 2007 +0000) 1 commit
> - transport.c: call dash-less form of receive-pack and upload-pack
> on remote
>
> Not field tested by anybody nor came with any tests, but this is an
> important component to move git-foo commands out of user's PATH.
Please scratch that. It does not work, and what it should fix is better
done by your 3/3.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Wincent Colaiuta @ 2007-12-02 15:02 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Jeff King, Junio C Hamano, Andreas Ericsson, Nicolas Pitre,
Linus Torvalds, Nguyen Thai Ngoc Duy, Jan Hudec, git
In-Reply-To: <Pine.LNX.4.64.0711302306580.27959@racer.site>
El 1/12/2007, a las 0:10, Johannes Schindelin escribió:
> To me, it is mighty annoying anybody brings up that "144 commands"
> argument Linus was referring to, and if there is _any_ way to shut up
> those bikeshedders, I am all for it.
This is not a bikeshed argument and it is not an "idiotic
complaint" (to use Linus' phrase). It is a legitimate concern and a
*real* UI problem.
You and Linus don't care that there are 140+ Git commands and I
imagine that you know exactly what each of them does.
I don't really care either because although I don't know what every
single command does, I know what the 20 or 30 commands I personally
need for my own workflow do.
The problem is for *newcomers* to Git who sit down for the first time
and ask themselves, "Now, how do I...?". This is not an idiotic
complaint but a legitimate concern about a real UI problem.
Honestly, Johannes, do you think the following is a good UI?
$ git
Display all 148 possibilities? (y or n)
git* git-cvsimport* git-local-
fetch* git-peek-remote* git-show-index*
git-add* git-cvsserver* git-
log* git-prune* git-show-ref*
git-add--interactive* git-daemon* git-lost-
found* git-prune-packed* git-ssh-fetch*
git-am* git-describe* git-ls-
files* git-pull* git-ssh-pull*
git-annotate* git-diff* git-ls-
remote* git-push* git-ssh-push*
git-apply* git-diff-files* git-ls-
tree* git-quiltimport* git-ssh-upload*
git-applymbox git-diff-index* git-
mailinfo* git-read-tree* git-stash*
git-applypatch git-diff-tree* git-
mailsplit* git-rebase* git-status*
git-archimport* git-fast-import* git-
merge* git-rebase--interactive* git-stripspace*
git-archive* git-fetch* git-merge-
base* git-receive-pack* git-submodule*
git-bisect* git-fetch--tool* git-merge-
file* git-reflog* git-svn*
git-blame* git-fetch-pack* git-merge-
index* git-relink* git-svnimport
git-branch* git-filter-branch* git-merge-
octopus* git-remote* git-symbolic-ref*
git-bundle* git-fmt-merge-msg* git-merge-one-
file* git-repack* git-tag*
git-cat-file* git-for-each-ref* git-merge-
ours* git-repo-config* git-tar-tree*
git-check-attr* git-format-patch* git-merge-
recursive* git-request-pull* git-unpack-file*
git-check-ref-format* git-fsck* git-merge-
resolve* git-rerere* git-unpack-objects*
git-checkout* git-fsck-objects* git-merge-
stupid* git-reset* git-update-index*
git-checkout-index* git-gc* git-merge-
subtree* git-rev-list* git-update-ref*
git-cherry* git-get-tar-commit-id* git-merge-
tree* git-rev-parse* git-update-server-info*
git-cherry-pick* git-grep* git-
mergetool* git-revert* git-upload-archive*
git-citool git-gui/ git-
mktag* git-rm* git-upload-pack*
git-clean* git-hash-object* git-
mktree* git-runstatus* git-var*
git-clone* git-http-fetch* git-
mv* git-send-email* git-verify-pack*
git-commit* git-http-push* git-name-
rev* git-send-pack* git-verify-tag*
git-commit-tree* git-imap-send* git-pack-
objects* git-sh-setup* git-whatchanged*
git-config* git-index-pack* git-pack-
redundant* git-shell* git-write-tree*
git-convert-objects git-init* git-pack-
refs* git-shortlog* gitk
git-count-objects* git-init-db* git-parse-
remote* git-show*
git-cvsexportcommit* git-instaweb* git-patch-
id* git-show-branch*
Would you argue that this screenshot shows a sane UI?
<http://wincent.com/tmp/git-ui.png>
Note: I am not complaining about the *number* of commands; I myself
find them highly useful for scripting. I am saying that the
*visibility* of those commands is the problem. That's why I support
the efforts to move most of this stuff out of the default PATH. We're
not talking about getting rid of it, just about putting it somewhere
more appropriate in order to correct what is basically a *hideous*
user interface for the beginner.
Cheers,
Wincent
^ permalink raw reply
* Re: problems with importing from cvs archive
From: Jean-François Veillette @ 2007-12-02 15:14 UTC (permalink / raw)
To: Ed S. Peschko; +Cc: git
In-Reply-To: <20071202064613.GB25351@venus>
Le 07-12-02 à 01:46, Ed S. Peschko a écrit :
> All,
>
> I'm trying to use git-cvsimport to import from a CVS archive, using:
>
> git-cvsimport -d $CVSROOT
I was able to go further just by adding the verbose mode ( -v ) :
git cvsimport -v -d ...
give it a try,
- jfv
^ permalink raw reply
* Re: cannot see git-fetch result in gitk
From: Tilman Schmidt @ 2007-12-02 15:15 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3zlwuwmce.fsf@roke.D-201>
[-- Attachment #1: Type: text/plain, Size: 655 bytes --]
Am 01.12.2007 14:55 schrieb Jakub Narebski:
> Did you run just "gitk"? By default gitk displays only current branch,
Thanks, that explains it. It might be a good idea to mention that
in the manpage.
> while git-fetch changes remote-tracking branches only. Try
> "gitk --all", or "gitk origin/master ..." enumerating explicitely all
> remote branches.
Ok, thanks, will try that next time git-fetch actually finds something
to fetch. ;-)
--
Tilman Schmidt E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]
^ permalink raw reply
* gitk error: expected integer but got "Hamano"
From: Jing Xue @ 2007-12-02 16:02 UTC (permalink / raw)
To: git
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"
expected integer but got "Hamano"
while executing
"clock format $d -format $datetimeformat"
(procedure "formatdate" line 4)
invoked from within
"formatdate $date"
(procedure "drawcmittext" line 52)
invoked from within
"drawcmittext $id $row $col"
(procedure "drawcmitrow" line 34)
invoked from within
"drawcmitrow $r"
(procedure "drawcommits" line 57)
invoked from within
"drawcommits $row $endrow"
(procedure "drawfrac" line 10)
invoked from within
"drawfrac $f0 $f1"
(procedure "scrollcanv" line 3)
invoked from within
"scrollcanv .tf.histframe.csb 0.0613366 0.0636028"
I'd try to debug myself but my knowledge on tcl/tk is rather limited
(read: zero).
Cheers.
--
Jing Xue
^ permalink raw reply
* Corrupted (?) commit 6e6db85e confusing gitk
From: Steffen Prohaska @ 2007-12-02 16:06 UTC (permalink / raw)
To: Git Mailing List
When I run
gitk 6e6db85ea9423eea755cf5acf7a563c0d9559063
gitk complaints with 'Error: expected integer but got "Hamano"'.
I tracked the problem down to the raw content of the commit object.
The author line is lacking time and timezone information:
$ git-cat-file -p 6e6db85ea9423eea755cf5acf7a563c0d9559063
tree 5265f13d094e7c453a06f097add25eaefb843a79
parent d25430c5f88c7e7b4ce24c1b08e409f4345c4eb9
author Junio C Hamano <gitster@pobox.com>
committer Junio C Hamano <gitster@pobox.com> 1196466497 -0800
Run the specified perl in Documentation/
Makefile uses $(PERL_PATH) but Documentation/Makefile uses "perl";
that means the two Makefiles actually use two different
Perl installations.
Teach Documentation/Makefile to use PERL_PATH that is exported
from the
toplevel Makefile, and give a sane fallback for people who run
"make"
from Documentation directory.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitk fails to parse this because it expects the time to be
the second item from the end of a line (look for "set audate"
in function parsecommit of gitk). For the commit above, gitk
finds "Hamano" instead of the correct time.
I'm pretty convinced that the original commit is reported
correctly. I verified that with two different versions of git
(1.5.3.7.949.g2221a6 on mac and 1.5.3.6.1889.g98603 on mingw).
Both report the raw commit without time and timezone.
I'd like to conclude with some questions:
- Is this commit corrupted?
- How was the commit created?
- Should "git fsck" detect such corruption?
- Should gitk more gracefully handle corrupted commits?
I do not have solutions yet.
Steffen
^ permalink raw reply
* Re: Corrupted (?) commit 6e6db85e confusing gitk
From: Wincent Colaiuta @ 2007-12-02 16:12 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Git Mailing List
In-Reply-To: <5F1A20CC-7427-4E7A-AB95-E89C9FA17951@zib.de>
El 2/12/2007, a las 17:06, Steffen Prohaska escribió:
> When I run
>
> gitk 6e6db85ea9423eea755cf5acf7a563c0d9559063
>
> gitk complaints with 'Error: expected integer but got "Hamano"'.
>
> I tracked the problem down to the raw content of the commit object.
> The author line is lacking time and timezone information:
>
> $ git-cat-file -p 6e6db85ea9423eea755cf5acf7a563c0d9559063
> tree 5265f13d094e7c453a06f097add25eaefb843a79
> parent d25430c5f88c7e7b4ce24c1b08e409f4345c4eb9
> author Junio C Hamano <gitster@pobox.com>
> committer Junio C Hamano <gitster@pobox.com> 1196466497 -0800
Yeah, and:
$ git show 6e6db85ea9423eea755cf5acf7a563c0d9559063 | head -3
commit 6e6db85ea9423eea755cf5acf7a563c0d9559063
Author: Junio C Hamano <gitster@pobox.com>
Date: Thu Jan 1 00:00:00 1970 +0000
Cheers,
Wincent
^ permalink raw reply
* Re: make test failure with latest master
From: Jeff King @ 2007-12-02 16:34 UTC (permalink / raw)
To: A Large Angry SCM; +Cc: git, gitster
In-Reply-To: <4752A53E.4030000@gmail.com>
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.
-Peff
^ permalink raw reply
* [PATCH] gitk: Add workaround to handle corrupted author date
From: Steffen Prohaska @ 2007-12-02 16:36 UTC (permalink / raw)
To: git; +Cc: Steffen Prohaska
In-Reply-To: <5F1A20CC-7427-4E7A-AB95-E89C9FA17951@zib.de>
6e6db85ea9423eea755cf5acf7a563c0d9559063 contains a corrupted
author line, which is lacking the time and timezone information.
This commit adds a workaround to handle this situation. If the
time cannot be parsed, it is assumed to be 0 and the full line
is assumed to be the author's name.
---
gitk | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
This works around the issue for me. However, I don't think
this patch should be applied.
The best was if such a corrupted commit wouldn't enter the
repository in the first place. But once it is there, I think git
should verify the format of a commit and report an approriate
error. gitk could continue to assume well formed commits.
Steffen
diff --git a/gitk b/gitk
index 1da0b0a..873766c 100755
--- a/gitk
+++ b/gitk
@@ -439,7 +439,12 @@ proc parsecommit {id contents listed} {
set tag [lindex $line 0]
if {$tag == "author"} {
set audate [lindex $line end-1]
- set auname [lrange $line 1 end-2]
+ if {[catch {formatdate $audate}]} {
+ set audate 0
+ set auname [lrange $line 1 end]
+ } else {
+ set auname [lrange $line 1 end-2]
+ }
} elseif {$tag == "committer"} {
set comdate [lindex $line end-1]
set comname [lrange $line 1 end-2]
--
1.5.3.7.949.g2221a6
^ permalink raw reply related
* Re: gitk error: expected integer but got "Hamano"
From: Steffen Prohaska @ 2007-12-02 16:41 UTC (permalink / raw)
To: Jing Xue; +Cc: git
In-Reply-To: <20071202160204.GA13141@fawkes>
On Dec 2, 2007, at 5:02 PM, Jing Xue wrote:
>
> I'd try to debug myself but my knowledge on tcl/tk is rather limited
> (read: zero).
See my mail "Corrupted (?) commit 6e6db85e confusing gitk", which
describes the reason in detail.
Steffen
^ permalink raw reply
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Johannes Schindelin @ 2007-12-02 16:39 UTC (permalink / raw)
To: Wincent Colaiuta
Cc: Jeff King, Junio C Hamano, Andreas Ericsson, Nicolas Pitre,
Linus Torvalds, Nguyen Thai Ngoc Duy, Jan Hudec, git
In-Reply-To: <FFEBE8BB-E764-4DD0-A7DC-8CC01659D9BC@wincent.com>
Hi,
On Sun, 2 Dec 2007, Wincent Colaiuta wrote:
> El 1/12/2007, a las 0:10, Johannes Schindelin escribi?:
>
> > To me, it is mighty annoying anybody brings up that "144 commands"
> > argument Linus was referring to, and if there is _any_ way to shut up
> > those bikeshedders, I am all for it.
>
> This is not a bikeshed argument and it is not an "idiotic complaint" (to
> use Linus' phrase). It is a legitimate concern and a *real* UI problem.
>
> You and Linus don't care that there are 140+ Git commands and I imagine
> that you know exactly what each of them does.
Okay, how many executables are there in your /usr/bin/? Here there are
2973.
Guess what. I am not intimidated by that number.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 6/6] builtin-commit: Add newline when showing which commit was created
From: Jeff King @ 2007-12-02 16:54 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, krh, gitster
In-Reply-To: <Pine.LNX.4.64.0712021212490.27959@racer.site>
On Sun, Dec 02, 2007 at 12:13:07PM +0000, Johannes Schindelin wrote:
> > It would be helpful if you could remember the test case, but perhaps
> > that is not an option at this point.
>
> IIRC it was "git commit -m bla".
I have made several attempts to reproduce the problem, looked a bit
through the log-tree code, and checked the results of the t750* series
of tests; but I have found nothing. I think we are better off reverting,
which fixes every case I have seen; if the problem behavior comes back,
we will have figured out what causes it. And if it doesn't come back,
then the revert is the right thing. :)
-- >8 --
Revert "builtin-commit: Add newline when showing which commit was created"
This reverts commit 129fa606365c172d07a5d98bea9345277f221363.
We end up in most cases with an undesired extra newline. It
is possible that there is some corner case that requires the
newline, but there is no published test case. So let's fix
the known problem, and we can deal with the corner case if
and when there is a bug report.
---
builtin-commit.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index f6e8e44..118853d 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -660,7 +660,6 @@ static void print_summary(const char *prefix, const unsigned char *sha1)
printf("Created %scommit ", initial_commit ? "initial " : "");
log_tree_commit(&rev, commit);
- printf("\n");
}
int git_commit_config(const char *k, const char *v)
--
1.5.3.6.2094.g3713
^ permalink raw reply related
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Pascal Obry @ 2007-12-02 16:56 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Wincent Colaiuta, Jeff King, Junio C Hamano, Andreas Ericsson,
Nicolas Pitre, Linus Torvalds, Nguyen Thai Ngoc Duy, Jan Hudec,
git
In-Reply-To: <Pine.LNX.4.64.0712021637250.27959@racer.site>
Johannes Schindelin a écrit :
> Okay, how many executables are there in your /usr/bin/? Here there are
> 2973.
> Guess what. I am not intimidated by that number.
Good, and look in /usr/bin, all those 2973 binary are all disconnected.
Here we are speaking about a tool as a whole : Git.
And I agree that hiding some of them will probably help new comers. We
can also argue that a new comers should read some documentation :)
After all I'm not sure what's the right move !
At least let me say something constructive :) I'm a new comer to Git.
I've read many documentations before grabbing the system and I've not
been impressed by the number of binaries in /usr/bin... Because I've
almost never looked there. Most of the time I'm using "git <tab>" and
the bash completion feature is just right for me.
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
* git-merge --no-commit commits
From: Vegard Nossum @ 2007-12-02 16:57 UTC (permalink / raw)
To: git
Hi,
I am using git 1.5.3.4 and just did the following (v1 and v2 are
branches; v1 is a parent of v2):
git checkout v1
git merge --no-commit v2
It simply fast-forwarded AND committed even though I explicitly told
it not to. What gives?
Kind regards,
Vegard Nossum
^ 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