threads / patch / 11014

patchAdd 'git fast-export', the sister of 'git fast-import'

Subject: [PATCH] Add 'git fast-export', the sister of 'git fast-import'

## tl;dr

10 messages between Nov 25, 2007 and Nov 28, 2007. Diffs are folded; open one to read it.

replies: 9people: 4as markdown or json

Johannes Schindelin· Nov 25, 2007, 21:37 UTC · lore

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>
---
	This should be feature complete AFAICT.
 .gitignore                        |    1 +
 Documentation/git-fast-export.txt |   83 ++++++++
 Makefile                          |    1 +
 builtin-fast-export.c             |  407 +++++++++++++++++++++++++++++++++++++
 builtin.h                         |    1 +
 git.c                             |    1 +
 t/t9301-fast-export.sh            |  124 +++++++++++
 7 files changed, 618 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
Show changes to 7 files +618 −0

.gitignore, Documentation/git-fast-export.txt, Makefile, builtin-fast-export.c, builtin.h, git.c, 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 0719fb8..ebd12ed 100644
--- a/Makefile
+++ b/Makefile
@@ -337,6 +337,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..48d0c54
--- /dev/null
+++ b/builtin-fast-export.c
@@ -0,0 +1,407 @@
+/*
+ * "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, (void *)last_idnum);
+}
+
+static int get_object_mark(struct object *object)
+{
+	return (int)lookup_decoration(&idnums, object);
+}
+
+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,
+		author_end - author, author,
+		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),
+		tagger_end - tagger, tagger,
+		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/git.c b/git.c
index e48c2c9..db0e7c3 100644
--- a/git.c
+++ b/git.c
@@ -303,6 +303,7 @@ static void handle_internal_command(int argc, const char **argv)
 		{ "diff-files", cmd_diff_files },
 		{ "diff-index", cmd_diff_index, RUN_SETUP },
 		{ "diff-tree", cmd_diff_tree, RUN_SETUP },
+		{ "fast-export", cmd_fast_export, RUN_SETUP },
 		{ "fetch", cmd_fetch, RUN_SETUP },
 		{ "fetch-pack", cmd_fetch_pack, RUN_SETUP },
 		{ "fetch--tool", cmd_fetch__tool, RUN_SETUP },
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.1828.gd496
Junio C Hamano· Nov 26, 2007, 01:16 UTC · re: Johannes Schindelin · lore

Re: [PATCH] Add 'git fast-export', the sister of 'git fast-import'

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 31 quoted lines
> 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
> ...
> +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.
I am not sure if abort should be the default.

If a straight dump-restore is made without rewriting, the result will be identical to the original, right?

The reason I mention a straight dump-restore is because ...
> +$ git fast-export master~5..master |
> +	sed "s|refs/heads/master|refs/heads/other|" |
> +	git fast-import

... I find this a quite unrealistic example to assume that the data stream does not have some string and convert blindly without parsing.

On the other hand, we _could_ also have a separate filter that works on input stream for fast-import, but that filter should know what the fast-import input stream looks like (a simple sed does not cut it).

So unless the future direction is to deprecate filter-branch and replace it with such a fast-import based filter in between fast-export and fast-import, I think the use of fast-export is to make verbatim copy without munging the contents, which leads me to think --signed-tag option should default to "export it as-is".

... which seem to be missing from the available values to the option.
Show 10 quoted lines
> diff --git a/builtin-fast-export.c b/builtin-fast-export.c
> new file mode 100755
> index 0000000..48d0c54
> --- /dev/null
> +++ b/builtin-fast-export.c
> ...
> +/*
> + * TODO:
> + * - tags (--signed-tags=(ignore|warn|strip|abort)
> + */
This comment is stale?
Johannes Schindelin· Nov 26, 2007, 12:39 UTC · re: Junio C Hamano · lore

Re: [PATCH] Add 'git fast-export', the sister of 'git fast-import'

Hi,
On Sun, 25 Nov 2007, Junio C Hamano wrote:
Show 35 quoted lines
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > 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
> > ...
> > +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.
> 
> I am not sure if abort should be the default.
I tried to be conservative.
> If a straight dump-restore is made without rewriting, the result will be 
> identical to the original, right?
Yep.
Show 8 quoted lines
> The reason I mention a straight dump-restore is because ...
> 
> > +$ git fast-export master~5..master |
> > +	sed "s|refs/heads/master|refs/heads/other|" |
> > +	git fast-import
> 
> ... I find this a quite unrealistic example to assume that the data
> stream does not have some string and convert blindly without parsing.

That's what the warning after the example is about. For quick and dirty operations, it is quite adequate.

Besides, I have the feeling that some people are more comfortable dumping the whole repository into a file, editing it, and fast-importing it. That is what I referred to when I said "think of it as kind of an interactive filter-branch".

> On the other hand, we _could_ also have a separate filter that works on 
> input stream for fast-import, but that filter should know what the 
> fast-import input stream looks like (a simple sed does not cut it).
I agree that for most serious operations sed is not good enough.
Show 7 quoted lines
> So unless the future direction is to deprecate filter-branch and replace 
> it with such a fast-import based filter in between fast-export and 
> fast-import, I think the use of fast-export is to make verbatim copy 
> without munging the contents, which leads me to think --signed-tag 
> option should default to "export it as-is".
> 
> ... which seem to be missing from the available values to the option.

You mean something like "--signed-tag=warn 2> /dev/null"? How about a "--signed-tag=quiet" mode?

Show 12 quoted lines
> > diff --git a/builtin-fast-export.c b/builtin-fast-export.c
> > new file mode 100755
> > index 0000000..48d0c54
> > --- /dev/null
> > +++ b/builtin-fast-export.c
> > ...
> > +/*
> > + * TODO:
> > + * - tags (--signed-tags=(ignore|warn|strip|abort)
> > + */
> 
> This comment is stale?
Correct.

Ciao, Dscho

Junio C Hamano· Nov 26, 2007, 17:55 UTC · re: Johannes Schindelin · lore

Re: [PATCH] Add 'git fast-export', the sister of 'git fast-import'

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 12 quoted lines
> On Sun, 25 Nov 2007, Junio C Hamano wrote:
>
>> I am not sure if abort should be the default.
>
> I tried to be conservative.
>
>> If a straight dump-restore is made without rewriting, the result will be 
>> identical to the original, right?
>
> Yep.
> ...
> I agree that for most serious operations sed is not good enough.

My comment was more about the perception from a new user (not a "new git user", but a "new fast-export and fast-import user").

When you see a command pair foo-export and foo-import, and it is advertised that you can pipe them together, a new user would first try a straight dump-restore, and would see the warning even though he did not do any editing on the stream.

	Huh?  Why does a tag signature become invalid because of merely
	exporting and then importing?  What is this warning about?

You would explain "yeah in your trial run you did not edit but the command pair is to allow you editing the contents in between, and if you do that, the object names might change.".

If the default were "straight copy", then the user will not get an invalid signature on his trial run, but will get an invalid signature when he rewrites the object stream. You would get a message on the list like this:

	Hello, I tried fast-export piped to fast-import so that I can
	rewrite my repository, but I am getting invalid signature on
	signed tags.  It does not seem to happen if I do not edit but
	just use the fast-export output without modification.  What am I
	doing wrong?

And that is the time the explanation first becomes useful. IOW, you are warning at the wrong place. "It may or may not corrupt the signature, I do not know. Because it depends on what you are going to do with my output, I cannot know. I am warning you anyway to cover my backside".

I am wondering if fast-import input syntax can be extended to allow checking inconsistencies. A command to import a tag could take an additional object name and tell it to warn if the name of the tagged object (the one sent with "from:%d\n" part) is different from that object name. At that point, you know the object was rewritten and the signature is invalid, and the choice of warning, stripping or aborting becomes a useful thing to have.

Johannes Schindelin· Nov 27, 2007, 12:14 UTC · re: Junio C Hamano · lore

Re: [PATCH] Add 'git fast-export', the sister of 'git fast-import'

Hi,
[Shawn Cc'ed, since it affects fast-import]
On Mon, 26 Nov 2007, Junio C Hamano wrote:
Show 25 quoted lines
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > On Sun, 25 Nov 2007, Junio C Hamano wrote:
> >
> >> I am not sure if abort should be the default.
> >
> > I tried to be conservative.
> >
> >> If a straight dump-restore is made without rewriting, the result will 
> >> be identical to the original, right?
> >
> > Yep.
> > ...
> > I agree that for most serious operations sed is not good enough.
> 
> My comment was more about the perception from a new user (not a "new git
> user", but a "new fast-export and fast-import user").
> 
> When you see a command pair foo-export and foo-import, and it is
> advertised that you can pipe them together, a new user would first try a
> straight dump-restore, and would see the warning even though he did not
> do any editing on the stream.
> 
> 	Huh?  Why does a tag signature become invalid because of merely
> 	exporting and then importing?  What is this warning about?
Okay, I did not see that.
Show 27 quoted lines
> You would explain "yeah in your trial run you did not edit but the
> command pair is to allow you editing the contents in between, and if you
> do that, the object names might change.".
> 
> If the default were "straight copy", then the user will not get an
> invalid signature on his trial run, but will get an invalid signature
> when he rewrites the object stream.  You would get a message on the list
> like this:
> 
> 	Hello, I tried fast-export piped to fast-import so that I can
> 	rewrite my repository, but I am getting invalid signature on
> 	signed tags.  It does not seem to happen if I do not edit but
> 	just use the fast-export output without modification.  What am I
> 	doing wrong?
> 
> And that is the time the explanation first becomes useful.  IOW, you are
> warning at the wrong place.  "It may or may not corrupt the signature, I
> do not know.  Because it depends on what you are going to do with my
> output, I cannot know.  I am warning you anyway to cover my backside".
> 
> I am wondering if fast-import input syntax can be extended to allow
> checking inconsistencies.  A command to import a tag could take an
> additional object name and tell it to warn if the name of the tagged
> object (the one sent with "from:%d\n" part) is different from that
> object name.  At that point, you know the object was rewritten and the
> signature is invalid, and the choice of warning, stripping or aborting
> becomes a useful thing to have.

Why not check by default? Whenever there is a tag message containing the magic BEGIN line, it should check and at least warn if it does not match...

Ciao, Dscho

Shawn O. Pearce· Nov 27, 2007, 02:08 UTC · re: Johannes Schindelin · lore

Re: [PATCH] Add 'git fast-export', the sister of 'git fast-import'

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> This program dumps (parts of) a git repository in the format that
> fast-import understands.
...
Show 7 quoted lines
> +-------------------------------------------------------------------
> +$ 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.
WTF?

Why are you reencoding the commits on output in fast-export? Why aren't you dumping them raw to the stream? fast-import takes them raw. Oh, it doesn't have a way to set the encoding header. DOH.

I think this should be prefixed by fast-import patch to teach it something like "encoding N" as a subcommand of commit, so that you can feed data in a non UTF-8 encoding and get it to include the proper encoding header in the commit object it creates. That way a pipeline like the above really does create a duplicate repository, with the same commit SHA-1s, even if the commits weren't in UTF-8.

-- 
Shawn.
Johannes Schindelin· Nov 27, 2007, 11:31 UTC · re: Shawn O. Pearce · lore

Re: [PATCH] Add 'git fast-export', the sister of 'git fast-import'

Hi,
On Mon, 26 Nov 2007, Shawn O. Pearce wrote:
Show 17 quoted lines
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > This program dumps (parts of) a git repository in the format that
> > fast-import understands.
> ...
> > +-------------------------------------------------------------------
> > +$ 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.
> 
> WTF?
> 
> Why are you reencoding the commits on output in fast-export? Why aren't 
> you dumping them raw to the stream?  fast-import takes them raw.  Oh, it 
> doesn't have a way to set the encoding header. DOH.
Not only that... FTFD:

~ Commit messages are free-form and are not interpreted by Git. ~ Currently they must be encoded in UTF-8, as fast-import does not permit ~ other encodings to be specified.

So the documentation stated very much that I _had_ to do it that way.
Show 6 quoted lines
> I think this should be prefixed by fast-import patch to teach it 
> something like "encoding N" as a subcommand of commit, so that you can 
> feed data in a non UTF-8 encoding and get it to include the proper 
> encoding header in the commit object it creates.  That way a pipeline 
> like the above really does create a duplicate repository, with the same 
> commit SHA-1s, even if the commits weren't in UTF-8.

IMHO it's not worth that hassle. People who want to use fast-import usually want something fast which works, and not bother with specifying encodings.

Further, if you go down that road, some people will want to be able to say "that commit is KOI-8, this one is UTF-8, and the third is encoded in pre-Christian Tibetan runes."

But maybe I am wrong.

Ciao, Dscho

Jakub Narebski· Nov 27, 2007, 23:40 UTC · re: Johannes Schindelin · lore

Re: [PATCH] Add 'git fast-export', the sister of 'git fast-import'

Johannes Schindelin wrote:
> On Mon, 26 Nov 2007, Shawn O. Pearce wrote:
Show 10 quoted lines
>> I think this should be prefixed by fast-import patch to teach it 
>> something like "encoding N" as a subcommand of commit, so that you can 
>> feed data in a non UTF-8 encoding and get it to include the proper 
>> encoding header in the commit object it creates.  That way a pipeline 
>> like the above really does create a duplicate repository, with the same 
>> commit SHA-1s, even if the commits weren't in UTF-8.
> 
> IMHO it's not worth that hassle.  People who want to use fast-import 
> usually want something fast which works, and not bother with specifying 
> encodings.

Well, when I am converting some repository which uses legacy encoding (not utf-8), I'd like to use this git feature of specifying encoding; actually, to be generic, it could be any header which would be added to all created commit objects.

Yes, I could reencode commit messages...

P.S. One nice use of proposed (at one time) 'note' header would be to save revision identifier from the version control system you import (CVS revision number, Subversion sequential revision number, etc.).

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
Johannes Schindelin· Nov 28, 2007, 12:22 UTC · re: Jakub Narebski · lore

Re: [PATCH] Add 'git fast-export', the sister of 'git fast-import'

Hi,
On Wed, 28 Nov 2007, Jakub Narebski wrote:
Show 21 quoted lines
> Johannes Schindelin wrote:
> 
> > On Mon, 26 Nov 2007, Shawn O. Pearce wrote:
> 
> >> I think this should be prefixed by fast-import patch to teach it 
> >> something like "encoding N" as a subcommand of commit, so that you 
> >> can feed data in a non UTF-8 encoding and get it to include the 
> >> proper encoding header in the commit object it creates.  That way a 
> >> pipeline like the above really does create a duplicate repository, 
> >> with the same commit SHA-1s, even if the commits weren't in UTF-8.
> > 
> > IMHO it's not worth that hassle.  People who want to use fast-import 
> > usually want something fast which works, and not bother with 
> > specifying encodings.
> 
> Well, when I am converting some repository which uses legacy encoding 
> (not utf-8), I'd like to use this git feature of specifying encoding; 
> actually, to be generic, it could be any header which would be added to 
> all created commit objects.
> 
> Yes, I could reencode commit messages...
Right.
> P.S. One nice use of proposed (at one time) 'note' header would be to 
> save revision identifier from the version control system you import (CVS 
> revision number, Subversion sequential revision number, etc.).

Why not put it into the commit message? It is not information that git uses, so it does not belong into the commit header IMO. (IIRC I made the same point already at the time 'note' was discussed.)

Ciao, Dscho

Jakub Narebski· Nov 28, 2007, 12:56 UTC · re: Johannes Schindelin · lore

Re: [PATCH] Add 'git fast-export', the sister of 'git fast-import'

Johannes Schindelin wrote:
> On Wed, 28 Nov 2007, Jakub Narebski wrote:
Show 11 quoted lines
>> Yes, I could reencode commit messages...
> 
> Right.
> 
>> P.S. One nice use of proposed (at one time) 'note' header would be to 
>> save revision identifier from the version control system you import (CVS 
>> revision number, Subversion sequential revision number, etc.).
> 
> Why not put it into the commit message?  It is not information that git 
> uses, so it does not belong into the commit header IMO.  (IIRC I made the 
> same point already at the time 'note' was discussed.)

There are no problems if communication is only in one direction, i.e. if it is only import to git repository. If communication is two-directional, for example importing CVS repository into git and using git-cvsserver, or using Subversion repository with the help of git-svn, you would want commit messages preserved exactly. This includes not adding information about original revision id to commit message, and not recoding commit message to other encoding.

Just a thought...
-- 
Jakub Narebski
Poland

← back to recent threads