* [PATCH] Add 'git fast-export', the sister of 'git fast-import'
@ 2007-11-25 21:37 Johannes Schindelin
2007-11-26 1:16 ` Junio C Hamano
2007-11-27 2:08 ` Shawn O. Pearce
0 siblings, 2 replies; 10+ messages in thread
From: Johannes Schindelin @ 2007-11-25 21:37 UTC (permalink / raw)
To: git, gitster
[-- Attachment #1: Type: TEXT/PLAIN, Size: 19296 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>
---
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
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
^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH] Add 'git fast-export', the sister of 'git fast-import'
2007-11-25 21:37 [PATCH] Add 'git fast-export', the sister of 'git fast-import' Johannes Schindelin
@ 2007-11-26 1:16 ` Junio C Hamano
2007-11-26 12:39 ` Johannes Schindelin
2007-11-27 2:08 ` Shawn O. Pearce
1 sibling, 1 reply; 10+ messages in thread
From: Junio C Hamano @ 2007-11-26 1:16 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
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.
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.
> 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?
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] Add 'git fast-export', the sister of 'git fast-import'
2007-11-26 1:16 ` Junio C Hamano
@ 2007-11-26 12:39 ` Johannes Schindelin
2007-11-26 17:55 ` Junio C Hamano
0 siblings, 1 reply; 10+ messages in thread
From: Johannes Schindelin @ 2007-11-26 12:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Hi,
On Sun, 25 Nov 2007, Junio C Hamano wrote:
> 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.
> 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.
> 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?
> > 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] Add 'git fast-export', the sister of 'git fast-import'
2007-11-26 12:39 ` Johannes Schindelin
@ 2007-11-26 17:55 ` Junio C Hamano
2007-11-27 12:14 ` Johannes Schindelin
0 siblings, 1 reply; 10+ messages in thread
From: Junio C Hamano @ 2007-11-26 17:55 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
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?
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] Add 'git fast-export', the sister of 'git fast-import'
2007-11-26 17:55 ` Junio C Hamano
@ 2007-11-27 12:14 ` Johannes Schindelin
0 siblings, 0 replies; 10+ messages in thread
From: Johannes Schindelin @ 2007-11-27 12:14 UTC (permalink / raw)
To: Junio C Hamano, spearce; +Cc: git
Hi,
[Shawn Cc'ed, since it affects fast-import]
On Mon, 26 Nov 2007, Junio C Hamano wrote:
> 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.
> 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] Add 'git fast-export', the sister of 'git fast-import'
2007-11-25 21:37 [PATCH] Add 'git fast-export', the sister of 'git fast-import' Johannes Schindelin
2007-11-26 1:16 ` Junio C Hamano
@ 2007-11-27 2:08 ` Shawn O. Pearce
2007-11-27 11:31 ` Johannes Schindelin
1 sibling, 1 reply; 10+ messages in thread
From: Shawn O. Pearce @ 2007-11-27 2:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
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.
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] Add 'git fast-export', the sister of 'git fast-import'
2007-11-27 2:08 ` Shawn O. Pearce
@ 2007-11-27 11:31 ` Johannes Schindelin
2007-11-27 23:40 ` Jakub Narebski
0 siblings, 1 reply; 10+ messages in thread
From: Johannes Schindelin @ 2007-11-27 11:31 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, gitster
Hi,
On Mon, 26 Nov 2007, Shawn O. Pearce wrote:
> 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.
> 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] Add 'git fast-export', the sister of 'git fast-import'
2007-11-27 11:31 ` Johannes Schindelin
@ 2007-11-27 23:40 ` Jakub Narebski
2007-11-28 12:22 ` Johannes Schindelin
0 siblings, 1 reply; 10+ messages in thread
From: Jakub Narebski @ 2007-11-27 23:40 UTC (permalink / raw)
To: git
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...
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] Add 'git fast-export', the sister of 'git fast-import'
2007-11-27 23:40 ` Jakub Narebski
@ 2007-11-28 12:22 ` Johannes Schindelin
2007-11-28 12:56 ` Jakub Narebski
0 siblings, 1 reply; 10+ messages in thread
From: Johannes Schindelin @ 2007-11-28 12:22 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Shawn O. Pearce, git
Hi,
On Wed, 28 Nov 2007, Jakub Narebski wrote:
> 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] Add 'git fast-export', the sister of 'git fast-import'
2007-11-28 12:22 ` Johannes Schindelin
@ 2007-11-28 12:56 ` Jakub Narebski
0 siblings, 0 replies; 10+ messages in thread
From: Jakub Narebski @ 2007-11-28 12:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn O. Pearce, git
Johannes Schindelin wrote:
> On Wed, 28 Nov 2007, Jakub Narebski wrote:
>> 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
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2007-11-28 12:56 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-11-25 21:37 [PATCH] Add 'git fast-export', the sister of 'git fast-import' Johannes Schindelin
2007-11-26 1:16 ` Junio C Hamano
2007-11-26 12:39 ` Johannes Schindelin
2007-11-26 17:55 ` Junio C Hamano
2007-11-27 12:14 ` Johannes Schindelin
2007-11-27 2:08 ` Shawn O. Pearce
2007-11-27 11:31 ` Johannes Schindelin
2007-11-27 23:40 ` Jakub Narebski
2007-11-28 12:22 ` Johannes Schindelin
2007-11-28 12:56 ` Jakub Narebski
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).