2007-12-02 22:14:13 +08:00
|
|
|
/*
|
|
|
|
* "git fast-export" builtin command
|
|
|
|
*
|
|
|
|
* Copyright (C) 2007 Johannes E. Schindelin
|
|
|
|
*/
|
|
|
|
#include "builtin.h"
|
2017-06-15 02:07:36 +08:00
|
|
|
#include "config.h"
|
2023-03-21 14:25:54 +08:00
|
|
|
#include "gettext.h"
|
2023-02-24 08:09:27 +08:00
|
|
|
#include "hex.h"
|
2015-06-22 22:03:05 +08:00
|
|
|
#include "refs.h"
|
2018-05-17 06:57:48 +08:00
|
|
|
#include "refspec.h"
|
2023-04-11 15:41:53 +08:00
|
|
|
#include "object-file.h"
|
2023-05-16 14:34:06 +08:00
|
|
|
#include "object-store-ll.h"
|
2007-12-02 22:14:13 +08:00
|
|
|
#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"
|
2008-07-22 02:03:49 +08:00
|
|
|
#include "string-list.h"
|
2007-12-02 22:14:13 +08:00
|
|
|
#include "utf8.h"
|
|
|
|
#include "parse-options.h"
|
fast-export: quote paths in output
Many pathnames in a fast-import stream need to be quoted. In
particular:
1. Pathnames at the end of an "M" or "D" line need quoting
if they contain a LF or start with double-quote.
2. Pathnames on a "C" or "R" line need quoting as above,
but also if they contain spaces.
For (1), we weren't quoting at all. For (2), we put
double-quotes around the paths to handle spaces, but ignored
the possibility that they would need further quoting.
This patch checks whether each pathname needs c-style
quoting, and uses it. This is slightly overkill for (1),
which doesn't actually need to quote many characters that
vanilla c-style quoting does. However, it shouldn't hurt, as
any implementation needs to be ready to handle quoted
strings anyway.
In addition to adding a test, we have to tweak a test which
blindly assumed that case (2) would always use
double-quotes, whether it needed to or not.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-06 06:36:22 +08:00
|
|
|
#include "quote.h"
|
2014-04-21 02:59:24 +08:00
|
|
|
#include "remote.h"
|
2014-08-28 01:01:28 +08:00
|
|
|
#include "blob.h"
|
2007-12-02 22:14:13 +08:00
|
|
|
|
|
|
|
static const char *fast_export_usage[] = {
|
2022-02-01 06:07:49 +08:00
|
|
|
N_("git fast-export [<rev-list-opts>]"),
|
2007-12-02 22:14:13 +08:00
|
|
|
NULL
|
|
|
|
};
|
|
|
|
|
|
|
|
static int progress;
|
parse-options: prefer opt->value to globals in callbacks
We have several parse-options callbacks that ignore their "opt"
parameters entirely. This is a little unusual, as we'd normally put the
result of the parsing into opt->value. In the case of these callbacks,
though, they directly manipulate global variables instead (and in
most cases the caller sets opt->value to NULL in the OPT_CALLBACK
declaration).
The immediate symptom we'd like to deal with is that the unused "opt"
variables trigger -Wunused-parameter. But how to fix that is debatable.
One option is to annotate them with UNUSED. But another is to have the
caller pass in the appropriate variable via opt->value, and use it. That
has the benefit of making the callbacks reusable (in theory at least),
and makes it clear from the OPT_CALLBACK declaration which variables
will be affected (doubly so for the cases in builtin/fast-export.c,
where we do set opt->value, but it is completely ignored!).
The slight downside is that we lose type safety, since they're now
passing through void pointers.
I went with the "just use them" approach here. The loss of type safety
is unfortunate, but that is already an issue with most of the other
callbacks. If we want to try to address that, we should do so more
consistently (and this patch would prepare these callbacks for whatever
we choose to do there).
Note that in the cases in builtin/fast-export.c, we are passing
anonymous enums. We'll have to give them names so that we can declare
the appropriate pointer type within the callbacks.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-01 05:21:07 +08:00
|
|
|
static enum signed_tag_mode { SIGNED_TAG_ABORT, VERBATIM, WARN, WARN_STRIP, STRIP } signed_tag_mode = SIGNED_TAG_ABORT;
|
|
|
|
static enum tag_of_filtered_mode { TAG_FILTERING_ABORT, DROP, REWRITE } tag_of_filtered_mode = TAG_FILTERING_ABORT;
|
|
|
|
static enum reencode_mode { REENCODE_ABORT, REENCODE_YES, REENCODE_NO } reencode_mode = REENCODE_ABORT;
|
2008-12-20 08:00:27 +08:00
|
|
|
static int fake_missing_tagger;
|
2011-07-16 21:03:33 +08:00
|
|
|
static int use_done_feature;
|
2009-07-28 10:20:22 +08:00
|
|
|
static int no_data;
|
2010-07-18 01:00:51 +08:00
|
|
|
static int full_tree;
|
fast-export: add --reference-excluded-parents option
git filter-branch has a nifty feature allowing you to rewrite, e.g. just
the last 8 commits of a linear history
git filter-branch $OPTIONS HEAD~8..HEAD
If you try the same with git fast-export, you instead get a history of
only 8 commits, with HEAD~7 being rewritten into a root commit. There
are two alternatives:
1) Don't use the negative revision specification, and when you're
filtering the output to make modifications to the last 8 commits,
just be careful to not modify any earlier commits somehow.
2) First run 'git fast-export --export-marks=somefile HEAD~8', then
run 'git fast-export --import-marks=somefile HEAD~8..HEAD'.
Both are more error prone than I'd like (the first for obvious reasons;
with the second option I have sometimes accidentally included too many
revisions in the first command and then found that the corresponding
extra revisions were not exported by the second command and thus were
not modified as I expected). Also, both are poor from a performance
perspective.
Add a new --reference-excluded-parents option which will cause
fast-export to refer to commits outside the specified rev-list-args
range by their sha1sum. Such a stream will only be useful in a
repository which already contains the necessary commits (much like the
restriction imposed when using --no-data).
Note from Peff:
I think we might be able to do a little more optimization here. If
we're exporting HEAD^..HEAD and there's an object in HEAD^ which is
unchanged in HEAD, I think we'd still print it (because it would not
be marked SHOWN), but we could omit it (by walking the tree of the
boundary commits and marking them shown). I don't think it's a
blocker for what you're doing here, but just a possible future
optimization.
Signed-off-by: Elijah Newren <newren@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-16 15:59:54 +08:00
|
|
|
static int reference_excluded_commits;
|
2018-11-16 15:59:56 +08:00
|
|
|
static int show_original_ids;
|
2019-10-04 04:27:07 +08:00
|
|
|
static int mark_tags;
|
2013-09-01 15:05:47 +08:00
|
|
|
static struct string_list extra_refs = STRING_LIST_INIT_NODUP;
|
2018-11-16 15:59:53 +08:00
|
|
|
static struct string_list tag_refs = STRING_LIST_INIT_NODUP;
|
2018-05-17 06:57:59 +08:00
|
|
|
static struct refspec refspecs = REFSPEC_INIT_FETCH;
|
2014-08-28 01:01:28 +08:00
|
|
|
static int anonymize;
|
2020-06-26 03:48:32 +08:00
|
|
|
static struct hashmap anonymized_seeds;
|
2018-05-19 13:28:24 +08:00
|
|
|
static struct revision_sources revision_sources;
|
2007-12-02 22:14:13 +08:00
|
|
|
|
|
|
|
static int parse_opt_signed_tag_mode(const struct option *opt,
|
|
|
|
const char *arg, int unset)
|
|
|
|
{
|
parse-options: prefer opt->value to globals in callbacks
We have several parse-options callbacks that ignore their "opt"
parameters entirely. This is a little unusual, as we'd normally put the
result of the parsing into opt->value. In the case of these callbacks,
though, they directly manipulate global variables instead (and in
most cases the caller sets opt->value to NULL in the OPT_CALLBACK
declaration).
The immediate symptom we'd like to deal with is that the unused "opt"
variables trigger -Wunused-parameter. But how to fix that is debatable.
One option is to annotate them with UNUSED. But another is to have the
caller pass in the appropriate variable via opt->value, and use it. That
has the benefit of making the callbacks reusable (in theory at least),
and makes it clear from the OPT_CALLBACK declaration which variables
will be affected (doubly so for the cases in builtin/fast-export.c,
where we do set opt->value, but it is completely ignored!).
The slight downside is that we lose type safety, since they're now
passing through void pointers.
I went with the "just use them" approach here. The loss of type safety
is unfortunate, but that is already an issue with most of the other
callbacks. If we want to try to address that, we should do so more
consistently (and this patch would prepare these callbacks for whatever
we choose to do there).
Note that in the cases in builtin/fast-export.c, we are passing
anonymous enums. We'll have to give them names so that we can declare
the appropriate pointer type within the callbacks.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-01 05:21:07 +08:00
|
|
|
enum signed_tag_mode *val = opt->value;
|
|
|
|
|
2007-12-02 22:14:13 +08:00
|
|
|
if (unset || !strcmp(arg, "abort"))
|
parse-options: prefer opt->value to globals in callbacks
We have several parse-options callbacks that ignore their "opt"
parameters entirely. This is a little unusual, as we'd normally put the
result of the parsing into opt->value. In the case of these callbacks,
though, they directly manipulate global variables instead (and in
most cases the caller sets opt->value to NULL in the OPT_CALLBACK
declaration).
The immediate symptom we'd like to deal with is that the unused "opt"
variables trigger -Wunused-parameter. But how to fix that is debatable.
One option is to annotate them with UNUSED. But another is to have the
caller pass in the appropriate variable via opt->value, and use it. That
has the benefit of making the callbacks reusable (in theory at least),
and makes it clear from the OPT_CALLBACK declaration which variables
will be affected (doubly so for the cases in builtin/fast-export.c,
where we do set opt->value, but it is completely ignored!).
The slight downside is that we lose type safety, since they're now
passing through void pointers.
I went with the "just use them" approach here. The loss of type safety
is unfortunate, but that is already an issue with most of the other
callbacks. If we want to try to address that, we should do so more
consistently (and this patch would prepare these callbacks for whatever
we choose to do there).
Note that in the cases in builtin/fast-export.c, we are passing
anonymous enums. We'll have to give them names so that we can declare
the appropriate pointer type within the callbacks.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-01 05:21:07 +08:00
|
|
|
*val = SIGNED_TAG_ABORT;
|
2007-12-04 06:44:39 +08:00
|
|
|
else if (!strcmp(arg, "verbatim") || !strcmp(arg, "ignore"))
|
parse-options: prefer opt->value to globals in callbacks
We have several parse-options callbacks that ignore their "opt"
parameters entirely. This is a little unusual, as we'd normally put the
result of the parsing into opt->value. In the case of these callbacks,
though, they directly manipulate global variables instead (and in
most cases the caller sets opt->value to NULL in the OPT_CALLBACK
declaration).
The immediate symptom we'd like to deal with is that the unused "opt"
variables trigger -Wunused-parameter. But how to fix that is debatable.
One option is to annotate them with UNUSED. But another is to have the
caller pass in the appropriate variable via opt->value, and use it. That
has the benefit of making the callbacks reusable (in theory at least),
and makes it clear from the OPT_CALLBACK declaration which variables
will be affected (doubly so for the cases in builtin/fast-export.c,
where we do set opt->value, but it is completely ignored!).
The slight downside is that we lose type safety, since they're now
passing through void pointers.
I went with the "just use them" approach here. The loss of type safety
is unfortunate, but that is already an issue with most of the other
callbacks. If we want to try to address that, we should do so more
consistently (and this patch would prepare these callbacks for whatever
we choose to do there).
Note that in the cases in builtin/fast-export.c, we are passing
anonymous enums. We'll have to give them names so that we can declare
the appropriate pointer type within the callbacks.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-01 05:21:07 +08:00
|
|
|
*val = VERBATIM;
|
2007-12-02 22:14:13 +08:00
|
|
|
else if (!strcmp(arg, "warn"))
|
parse-options: prefer opt->value to globals in callbacks
We have several parse-options callbacks that ignore their "opt"
parameters entirely. This is a little unusual, as we'd normally put the
result of the parsing into opt->value. In the case of these callbacks,
though, they directly manipulate global variables instead (and in
most cases the caller sets opt->value to NULL in the OPT_CALLBACK
declaration).
The immediate symptom we'd like to deal with is that the unused "opt"
variables trigger -Wunused-parameter. But how to fix that is debatable.
One option is to annotate them with UNUSED. But another is to have the
caller pass in the appropriate variable via opt->value, and use it. That
has the benefit of making the callbacks reusable (in theory at least),
and makes it clear from the OPT_CALLBACK declaration which variables
will be affected (doubly so for the cases in builtin/fast-export.c,
where we do set opt->value, but it is completely ignored!).
The slight downside is that we lose type safety, since they're now
passing through void pointers.
I went with the "just use them" approach here. The loss of type safety
is unfortunate, but that is already an issue with most of the other
callbacks. If we want to try to address that, we should do so more
consistently (and this patch would prepare these callbacks for whatever
we choose to do there).
Note that in the cases in builtin/fast-export.c, we are passing
anonymous enums. We'll have to give them names so that we can declare
the appropriate pointer type within the callbacks.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-01 05:21:07 +08:00
|
|
|
*val = WARN;
|
2013-04-14 18:57:06 +08:00
|
|
|
else if (!strcmp(arg, "warn-strip"))
|
parse-options: prefer opt->value to globals in callbacks
We have several parse-options callbacks that ignore their "opt"
parameters entirely. This is a little unusual, as we'd normally put the
result of the parsing into opt->value. In the case of these callbacks,
though, they directly manipulate global variables instead (and in
most cases the caller sets opt->value to NULL in the OPT_CALLBACK
declaration).
The immediate symptom we'd like to deal with is that the unused "opt"
variables trigger -Wunused-parameter. But how to fix that is debatable.
One option is to annotate them with UNUSED. But another is to have the
caller pass in the appropriate variable via opt->value, and use it. That
has the benefit of making the callbacks reusable (in theory at least),
and makes it clear from the OPT_CALLBACK declaration which variables
will be affected (doubly so for the cases in builtin/fast-export.c,
where we do set opt->value, but it is completely ignored!).
The slight downside is that we lose type safety, since they're now
passing through void pointers.
I went with the "just use them" approach here. The loss of type safety
is unfortunate, but that is already an issue with most of the other
callbacks. If we want to try to address that, we should do so more
consistently (and this patch would prepare these callbacks for whatever
we choose to do there).
Note that in the cases in builtin/fast-export.c, we are passing
anonymous enums. We'll have to give them names so that we can declare
the appropriate pointer type within the callbacks.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-01 05:21:07 +08:00
|
|
|
*val = WARN_STRIP;
|
2007-12-02 22:14:13 +08:00
|
|
|
else if (!strcmp(arg, "strip"))
|
parse-options: prefer opt->value to globals in callbacks
We have several parse-options callbacks that ignore their "opt"
parameters entirely. This is a little unusual, as we'd normally put the
result of the parsing into opt->value. In the case of these callbacks,
though, they directly manipulate global variables instead (and in
most cases the caller sets opt->value to NULL in the OPT_CALLBACK
declaration).
The immediate symptom we'd like to deal with is that the unused "opt"
variables trigger -Wunused-parameter. But how to fix that is debatable.
One option is to annotate them with UNUSED. But another is to have the
caller pass in the appropriate variable via opt->value, and use it. That
has the benefit of making the callbacks reusable (in theory at least),
and makes it clear from the OPT_CALLBACK declaration which variables
will be affected (doubly so for the cases in builtin/fast-export.c,
where we do set opt->value, but it is completely ignored!).
The slight downside is that we lose type safety, since they're now
passing through void pointers.
I went with the "just use them" approach here. The loss of type safety
is unfortunate, but that is already an issue with most of the other
callbacks. If we want to try to address that, we should do so more
consistently (and this patch would prepare these callbacks for whatever
we choose to do there).
Note that in the cases in builtin/fast-export.c, we are passing
anonymous enums. We'll have to give them names so that we can declare
the appropriate pointer type within the callbacks.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-01 05:21:07 +08:00
|
|
|
*val = STRIP;
|
2007-12-02 22:14:13 +08:00
|
|
|
else
|
2013-04-12 22:05:55 +08:00
|
|
|
return error("Unknown signed-tags mode: %s", arg);
|
2007-12-02 22:14:13 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-06-26 12:48:31 +08:00
|
|
|
static int parse_opt_tag_of_filtered_mode(const struct option *opt,
|
|
|
|
const char *arg, int unset)
|
|
|
|
{
|
parse-options: prefer opt->value to globals in callbacks
We have several parse-options callbacks that ignore their "opt"
parameters entirely. This is a little unusual, as we'd normally put the
result of the parsing into opt->value. In the case of these callbacks,
though, they directly manipulate global variables instead (and in
most cases the caller sets opt->value to NULL in the OPT_CALLBACK
declaration).
The immediate symptom we'd like to deal with is that the unused "opt"
variables trigger -Wunused-parameter. But how to fix that is debatable.
One option is to annotate them with UNUSED. But another is to have the
caller pass in the appropriate variable via opt->value, and use it. That
has the benefit of making the callbacks reusable (in theory at least),
and makes it clear from the OPT_CALLBACK declaration which variables
will be affected (doubly so for the cases in builtin/fast-export.c,
where we do set opt->value, but it is completely ignored!).
The slight downside is that we lose type safety, since they're now
passing through void pointers.
I went with the "just use them" approach here. The loss of type safety
is unfortunate, but that is already an issue with most of the other
callbacks. If we want to try to address that, we should do so more
consistently (and this patch would prepare these callbacks for whatever
we choose to do there).
Note that in the cases in builtin/fast-export.c, we are passing
anonymous enums. We'll have to give them names so that we can declare
the appropriate pointer type within the callbacks.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-01 05:21:07 +08:00
|
|
|
enum tag_of_filtered_mode *val = opt->value;
|
|
|
|
|
2009-06-26 12:48:31 +08:00
|
|
|
if (unset || !strcmp(arg, "abort"))
|
parse-options: prefer opt->value to globals in callbacks
We have several parse-options callbacks that ignore their "opt"
parameters entirely. This is a little unusual, as we'd normally put the
result of the parsing into opt->value. In the case of these callbacks,
though, they directly manipulate global variables instead (and in
most cases the caller sets opt->value to NULL in the OPT_CALLBACK
declaration).
The immediate symptom we'd like to deal with is that the unused "opt"
variables trigger -Wunused-parameter. But how to fix that is debatable.
One option is to annotate them with UNUSED. But another is to have the
caller pass in the appropriate variable via opt->value, and use it. That
has the benefit of making the callbacks reusable (in theory at least),
and makes it clear from the OPT_CALLBACK declaration which variables
will be affected (doubly so for the cases in builtin/fast-export.c,
where we do set opt->value, but it is completely ignored!).
The slight downside is that we lose type safety, since they're now
passing through void pointers.
I went with the "just use them" approach here. The loss of type safety
is unfortunate, but that is already an issue with most of the other
callbacks. If we want to try to address that, we should do so more
consistently (and this patch would prepare these callbacks for whatever
we choose to do there).
Note that in the cases in builtin/fast-export.c, we are passing
anonymous enums. We'll have to give them names so that we can declare
the appropriate pointer type within the callbacks.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-01 05:21:07 +08:00
|
|
|
*val = TAG_FILTERING_ABORT;
|
2009-06-26 12:48:31 +08:00
|
|
|
else if (!strcmp(arg, "drop"))
|
parse-options: prefer opt->value to globals in callbacks
We have several parse-options callbacks that ignore their "opt"
parameters entirely. This is a little unusual, as we'd normally put the
result of the parsing into opt->value. In the case of these callbacks,
though, they directly manipulate global variables instead (and in
most cases the caller sets opt->value to NULL in the OPT_CALLBACK
declaration).
The immediate symptom we'd like to deal with is that the unused "opt"
variables trigger -Wunused-parameter. But how to fix that is debatable.
One option is to annotate them with UNUSED. But another is to have the
caller pass in the appropriate variable via opt->value, and use it. That
has the benefit of making the callbacks reusable (in theory at least),
and makes it clear from the OPT_CALLBACK declaration which variables
will be affected (doubly so for the cases in builtin/fast-export.c,
where we do set opt->value, but it is completely ignored!).
The slight downside is that we lose type safety, since they're now
passing through void pointers.
I went with the "just use them" approach here. The loss of type safety
is unfortunate, but that is already an issue with most of the other
callbacks. If we want to try to address that, we should do so more
consistently (and this patch would prepare these callbacks for whatever
we choose to do there).
Note that in the cases in builtin/fast-export.c, we are passing
anonymous enums. We'll have to give them names so that we can declare
the appropriate pointer type within the callbacks.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-01 05:21:07 +08:00
|
|
|
*val = DROP;
|
2009-06-26 12:48:31 +08:00
|
|
|
else if (!strcmp(arg, "rewrite"))
|
parse-options: prefer opt->value to globals in callbacks
We have several parse-options callbacks that ignore their "opt"
parameters entirely. This is a little unusual, as we'd normally put the
result of the parsing into opt->value. In the case of these callbacks,
though, they directly manipulate global variables instead (and in
most cases the caller sets opt->value to NULL in the OPT_CALLBACK
declaration).
The immediate symptom we'd like to deal with is that the unused "opt"
variables trigger -Wunused-parameter. But how to fix that is debatable.
One option is to annotate them with UNUSED. But another is to have the
caller pass in the appropriate variable via opt->value, and use it. That
has the benefit of making the callbacks reusable (in theory at least),
and makes it clear from the OPT_CALLBACK declaration which variables
will be affected (doubly so for the cases in builtin/fast-export.c,
where we do set opt->value, but it is completely ignored!).
The slight downside is that we lose type safety, since they're now
passing through void pointers.
I went with the "just use them" approach here. The loss of type safety
is unfortunate, but that is already an issue with most of the other
callbacks. If we want to try to address that, we should do so more
consistently (and this patch would prepare these callbacks for whatever
we choose to do there).
Note that in the cases in builtin/fast-export.c, we are passing
anonymous enums. We'll have to give them names so that we can declare
the appropriate pointer type within the callbacks.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-01 05:21:07 +08:00
|
|
|
*val = REWRITE;
|
2009-06-26 12:48:31 +08:00
|
|
|
else
|
|
|
|
return error("Unknown tag-of-filtered mode: %s", arg);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-05-14 12:31:02 +08:00
|
|
|
static int parse_opt_reencode_mode(const struct option *opt,
|
|
|
|
const char *arg, int unset)
|
|
|
|
{
|
parse-options: prefer opt->value to globals in callbacks
We have several parse-options callbacks that ignore their "opt"
parameters entirely. This is a little unusual, as we'd normally put the
result of the parsing into opt->value. In the case of these callbacks,
though, they directly manipulate global variables instead (and in
most cases the caller sets opt->value to NULL in the OPT_CALLBACK
declaration).
The immediate symptom we'd like to deal with is that the unused "opt"
variables trigger -Wunused-parameter. But how to fix that is debatable.
One option is to annotate them with UNUSED. But another is to have the
caller pass in the appropriate variable via opt->value, and use it. That
has the benefit of making the callbacks reusable (in theory at least),
and makes it clear from the OPT_CALLBACK declaration which variables
will be affected (doubly so for the cases in builtin/fast-export.c,
where we do set opt->value, but it is completely ignored!).
The slight downside is that we lose type safety, since they're now
passing through void pointers.
I went with the "just use them" approach here. The loss of type safety
is unfortunate, but that is already an issue with most of the other
callbacks. If we want to try to address that, we should do so more
consistently (and this patch would prepare these callbacks for whatever
we choose to do there).
Note that in the cases in builtin/fast-export.c, we are passing
anonymous enums. We'll have to give them names so that we can declare
the appropriate pointer type within the callbacks.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-01 05:21:07 +08:00
|
|
|
enum reencode_mode *val = opt->value;
|
|
|
|
|
2019-05-14 12:31:02 +08:00
|
|
|
if (unset) {
|
parse-options: prefer opt->value to globals in callbacks
We have several parse-options callbacks that ignore their "opt"
parameters entirely. This is a little unusual, as we'd normally put the
result of the parsing into opt->value. In the case of these callbacks,
though, they directly manipulate global variables instead (and in
most cases the caller sets opt->value to NULL in the OPT_CALLBACK
declaration).
The immediate symptom we'd like to deal with is that the unused "opt"
variables trigger -Wunused-parameter. But how to fix that is debatable.
One option is to annotate them with UNUSED. But another is to have the
caller pass in the appropriate variable via opt->value, and use it. That
has the benefit of making the callbacks reusable (in theory at least),
and makes it clear from the OPT_CALLBACK declaration which variables
will be affected (doubly so for the cases in builtin/fast-export.c,
where we do set opt->value, but it is completely ignored!).
The slight downside is that we lose type safety, since they're now
passing through void pointers.
I went with the "just use them" approach here. The loss of type safety
is unfortunate, but that is already an issue with most of the other
callbacks. If we want to try to address that, we should do so more
consistently (and this patch would prepare these callbacks for whatever
we choose to do there).
Note that in the cases in builtin/fast-export.c, we are passing
anonymous enums. We'll have to give them names so that we can declare
the appropriate pointer type within the callbacks.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-01 05:21:07 +08:00
|
|
|
*val = REENCODE_ABORT;
|
2019-05-14 12:31:02 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
switch (git_parse_maybe_bool(arg)) {
|
|
|
|
case 0:
|
parse-options: prefer opt->value to globals in callbacks
We have several parse-options callbacks that ignore their "opt"
parameters entirely. This is a little unusual, as we'd normally put the
result of the parsing into opt->value. In the case of these callbacks,
though, they directly manipulate global variables instead (and in
most cases the caller sets opt->value to NULL in the OPT_CALLBACK
declaration).
The immediate symptom we'd like to deal with is that the unused "opt"
variables trigger -Wunused-parameter. But how to fix that is debatable.
One option is to annotate them with UNUSED. But another is to have the
caller pass in the appropriate variable via opt->value, and use it. That
has the benefit of making the callbacks reusable (in theory at least),
and makes it clear from the OPT_CALLBACK declaration which variables
will be affected (doubly so for the cases in builtin/fast-export.c,
where we do set opt->value, but it is completely ignored!).
The slight downside is that we lose type safety, since they're now
passing through void pointers.
I went with the "just use them" approach here. The loss of type safety
is unfortunate, but that is already an issue with most of the other
callbacks. If we want to try to address that, we should do so more
consistently (and this patch would prepare these callbacks for whatever
we choose to do there).
Note that in the cases in builtin/fast-export.c, we are passing
anonymous enums. We'll have to give them names so that we can declare
the appropriate pointer type within the callbacks.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-01 05:21:07 +08:00
|
|
|
*val = REENCODE_NO;
|
2019-05-14 12:31:02 +08:00
|
|
|
break;
|
|
|
|
case 1:
|
parse-options: prefer opt->value to globals in callbacks
We have several parse-options callbacks that ignore their "opt"
parameters entirely. This is a little unusual, as we'd normally put the
result of the parsing into opt->value. In the case of these callbacks,
though, they directly manipulate global variables instead (and in
most cases the caller sets opt->value to NULL in the OPT_CALLBACK
declaration).
The immediate symptom we'd like to deal with is that the unused "opt"
variables trigger -Wunused-parameter. But how to fix that is debatable.
One option is to annotate them with UNUSED. But another is to have the
caller pass in the appropriate variable via opt->value, and use it. That
has the benefit of making the callbacks reusable (in theory at least),
and makes it clear from the OPT_CALLBACK declaration which variables
will be affected (doubly so for the cases in builtin/fast-export.c,
where we do set opt->value, but it is completely ignored!).
The slight downside is that we lose type safety, since they're now
passing through void pointers.
I went with the "just use them" approach here. The loss of type safety
is unfortunate, but that is already an issue with most of the other
callbacks. If we want to try to address that, we should do so more
consistently (and this patch would prepare these callbacks for whatever
we choose to do there).
Note that in the cases in builtin/fast-export.c, we are passing
anonymous enums. We'll have to give them names so that we can declare
the appropriate pointer type within the callbacks.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-01 05:21:07 +08:00
|
|
|
*val = REENCODE_YES;
|
2019-05-14 12:31:02 +08:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
if (!strcasecmp(arg, "abort"))
|
parse-options: prefer opt->value to globals in callbacks
We have several parse-options callbacks that ignore their "opt"
parameters entirely. This is a little unusual, as we'd normally put the
result of the parsing into opt->value. In the case of these callbacks,
though, they directly manipulate global variables instead (and in
most cases the caller sets opt->value to NULL in the OPT_CALLBACK
declaration).
The immediate symptom we'd like to deal with is that the unused "opt"
variables trigger -Wunused-parameter. But how to fix that is debatable.
One option is to annotate them with UNUSED. But another is to have the
caller pass in the appropriate variable via opt->value, and use it. That
has the benefit of making the callbacks reusable (in theory at least),
and makes it clear from the OPT_CALLBACK declaration which variables
will be affected (doubly so for the cases in builtin/fast-export.c,
where we do set opt->value, but it is completely ignored!).
The slight downside is that we lose type safety, since they're now
passing through void pointers.
I went with the "just use them" approach here. The loss of type safety
is unfortunate, but that is already an issue with most of the other
callbacks. If we want to try to address that, we should do so more
consistently (and this patch would prepare these callbacks for whatever
we choose to do there).
Note that in the cases in builtin/fast-export.c, we are passing
anonymous enums. We'll have to give them names so that we can declare
the appropriate pointer type within the callbacks.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-01 05:21:07 +08:00
|
|
|
*val = REENCODE_ABORT;
|
2019-05-14 12:31:02 +08:00
|
|
|
else
|
|
|
|
return error("Unknown reencoding mode: %s", arg);
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2007-12-02 22:14:13 +08:00
|
|
|
static struct decoration idnums;
|
|
|
|
static uint32_t last_idnum;
|
2014-08-28 01:01:28 +08:00
|
|
|
struct anonymized_entry {
|
|
|
|
struct hashmap_entry hash;
|
2023-03-23 01:37:17 +08:00
|
|
|
char *anon;
|
2020-06-23 23:24:58 +08:00
|
|
|
const char orig[FLEX_ARRAY];
|
2020-06-23 23:24:56 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
struct anonymized_entry_key {
|
|
|
|
struct hashmap_entry hash;
|
|
|
|
const char *orig;
|
|
|
|
size_t orig_len;
|
2014-08-28 01:01:28 +08:00
|
|
|
};
|
|
|
|
|
2022-08-26 01:09:48 +08:00
|
|
|
static int anonymized_entry_cmp(const void *cmp_data UNUSED,
|
2019-10-07 07:30:37 +08:00
|
|
|
const struct hashmap_entry *eptr,
|
|
|
|
const struct hashmap_entry *entry_or_key,
|
2020-06-23 23:24:56 +08:00
|
|
|
const void *keydata)
|
2014-08-28 01:01:28 +08:00
|
|
|
{
|
2019-10-07 07:30:37 +08:00
|
|
|
const struct anonymized_entry *a, *b;
|
|
|
|
|
|
|
|
a = container_of(eptr, const struct anonymized_entry, hash);
|
2020-06-23 23:24:56 +08:00
|
|
|
if (keydata) {
|
|
|
|
const struct anonymized_entry_key *key = keydata;
|
|
|
|
int equal = !strncmp(a->orig, key->orig, key->orig_len) &&
|
|
|
|
!a->orig[key->orig_len];
|
|
|
|
return !equal;
|
|
|
|
}
|
2019-10-07 07:30:37 +08:00
|
|
|
|
2020-06-23 23:24:56 +08:00
|
|
|
b = container_of(entry_or_key, const struct anonymized_entry, hash);
|
|
|
|
return strcmp(a->orig, b->orig);
|
2014-08-28 01:01:28 +08:00
|
|
|
}
|
|
|
|
|
2023-03-23 01:40:51 +08:00
|
|
|
static struct anonymized_entry *add_anonymized_entry(struct hashmap *map,
|
|
|
|
unsigned hash,
|
|
|
|
const char *orig, size_t len,
|
|
|
|
char *anon)
|
|
|
|
{
|
|
|
|
struct anonymized_entry *ret, *old;
|
|
|
|
|
|
|
|
if (!map->cmpfn)
|
|
|
|
hashmap_init(map, anonymized_entry_cmp, NULL, 0);
|
|
|
|
|
|
|
|
FLEX_ALLOC_MEM(ret, orig, orig, len);
|
|
|
|
hashmap_entry_init(&ret->hash, hash);
|
|
|
|
ret->anon = anon;
|
|
|
|
old = hashmap_put_entry(map, ret, hash);
|
|
|
|
|
|
|
|
if (old) {
|
|
|
|
free(old->anon);
|
|
|
|
free(old);
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2014-08-28 01:01:28 +08:00
|
|
|
/*
|
|
|
|
* Basically keep a cache of X->Y so that we can repeatedly replace
|
|
|
|
* the same anonymized string with another. The actual generation
|
|
|
|
* is farmed out to the generate function.
|
|
|
|
*/
|
2020-06-23 23:24:54 +08:00
|
|
|
static const char *anonymize_str(struct hashmap *map,
|
fast-export: drop data parameter from anonymous generators
The anonymization code has a specific generator callback for each type
of data (e.g., one for paths, one for oids, and so on). These all take a
"data" parameter, but none of them use it for anything. Which is not
surprising, as the point is to generate a new name independent of any
input, and each function keeps its own static counter.
We added the extra pointer in d5bf91fde44 (fast-export: add a "data"
callback parameter to anonymize_str(), 2020-06-23) to handle
--anonymize-map parsing, but that turned out to be awkward itself, and
was recently dropped.
So let's get rid of this "data" parameter that nobody is using, both
from the generators and from anonymize_str() which plumbed it through.
This simplifies the code, and makes -Wunused-parameter happier.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-23 01:42:51 +08:00
|
|
|
char *(*generate)(void),
|
|
|
|
const char *orig, size_t len)
|
2014-08-28 01:01:28 +08:00
|
|
|
{
|
2020-06-23 23:24:56 +08:00
|
|
|
struct anonymized_entry_key key;
|
|
|
|
struct anonymized_entry *ret;
|
2014-08-28 01:01:28 +08:00
|
|
|
|
2020-06-23 23:24:54 +08:00
|
|
|
hashmap_entry_init(&key.hash, memhash(orig, len));
|
2014-08-28 01:01:28 +08:00
|
|
|
key.orig = orig;
|
2020-06-23 23:24:54 +08:00
|
|
|
key.orig_len = len;
|
2014-08-28 01:01:28 +08:00
|
|
|
|
2020-06-26 03:48:32 +08:00
|
|
|
/* First check if it's a token the user configured manually... */
|
2023-03-23 01:38:04 +08:00
|
|
|
ret = hashmap_get_entry(&anonymized_seeds, &key, hash, &key);
|
2020-06-26 03:48:32 +08:00
|
|
|
|
|
|
|
/* ...otherwise check if we've already seen it in this context... */
|
|
|
|
if (!ret)
|
|
|
|
ret = hashmap_get_entry(map, &key, hash, &key);
|
|
|
|
|
|
|
|
/* ...and finally generate a new mapping if necessary */
|
2023-03-23 01:40:51 +08:00
|
|
|
if (!ret)
|
|
|
|
ret = add_anonymized_entry(map, key.hash.hash,
|
fast-export: drop data parameter from anonymous generators
The anonymization code has a specific generator callback for each type
of data (e.g., one for paths, one for oids, and so on). These all take a
"data" parameter, but none of them use it for anything. Which is not
surprising, as the point is to generate a new name independent of any
input, and each function keeps its own static counter.
We added the extra pointer in d5bf91fde44 (fast-export: add a "data"
callback parameter to anonymize_str(), 2020-06-23) to handle
--anonymize-map parsing, but that turned out to be awkward itself, and
was recently dropped.
So let's get rid of this "data" parameter that nobody is using, both
from the generators and from anonymize_str() which plumbed it through.
This simplifies the code, and makes -Wunused-parameter happier.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-23 01:42:51 +08:00
|
|
|
orig, len, generate());
|
2014-08-28 01:01:28 +08:00
|
|
|
|
|
|
|
return ret->anon;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We anonymize each component of a path individually,
|
|
|
|
* so that paths a/b and a/c will share a common root.
|
|
|
|
* The paths are cached via anonymize_mem so that repeated
|
|
|
|
* lookups for "a" will yield the same value.
|
|
|
|
*/
|
|
|
|
static void anonymize_path(struct strbuf *out, const char *path,
|
|
|
|
struct hashmap *map,
|
fast-export: drop data parameter from anonymous generators
The anonymization code has a specific generator callback for each type
of data (e.g., one for paths, one for oids, and so on). These all take a
"data" parameter, but none of them use it for anything. Which is not
surprising, as the point is to generate a new name independent of any
input, and each function keeps its own static counter.
We added the extra pointer in d5bf91fde44 (fast-export: add a "data"
callback parameter to anonymize_str(), 2020-06-23) to handle
--anonymize-map parsing, but that turned out to be awkward itself, and
was recently dropped.
So let's get rid of this "data" parameter that nobody is using, both
from the generators and from anonymize_str() which plumbed it through.
This simplifies the code, and makes -Wunused-parameter happier.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-23 01:42:51 +08:00
|
|
|
char *(*generate)(void))
|
2014-08-28 01:01:28 +08:00
|
|
|
{
|
|
|
|
while (*path) {
|
|
|
|
const char *end_of_component = strchrnul(path, '/');
|
|
|
|
size_t len = end_of_component - path;
|
fast-export: drop data parameter from anonymous generators
The anonymization code has a specific generator callback for each type
of data (e.g., one for paths, one for oids, and so on). These all take a
"data" parameter, but none of them use it for anything. Which is not
surprising, as the point is to generate a new name independent of any
input, and each function keeps its own static counter.
We added the extra pointer in d5bf91fde44 (fast-export: add a "data"
callback parameter to anonymize_str(), 2020-06-23) to handle
--anonymize-map parsing, but that turned out to be awkward itself, and
was recently dropped.
So let's get rid of this "data" parameter that nobody is using, both
from the generators and from anonymize_str() which plumbed it through.
This simplifies the code, and makes -Wunused-parameter happier.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-23 01:42:51 +08:00
|
|
|
const char *c = anonymize_str(map, generate, path, len);
|
2020-06-23 23:24:54 +08:00
|
|
|
strbuf_addstr(out, c);
|
2014-08-28 01:01:28 +08:00
|
|
|
path = end_of_component;
|
|
|
|
if (*path)
|
|
|
|
strbuf_addch(out, *path++);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-05-10 05:06:46 +08:00
|
|
|
static inline void *mark_to_ptr(uint32_t mark)
|
2007-12-02 22:14:13 +08:00
|
|
|
{
|
2018-05-10 05:06:46 +08:00
|
|
|
return (void *)(uintptr_t)mark;
|
2008-06-11 19:17:04 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline uint32_t ptr_to_mark(void * mark)
|
|
|
|
{
|
2018-05-10 05:06:46 +08:00
|
|
|
return (uint32_t)(uintptr_t)mark;
|
2008-06-11 19:17:04 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline void mark_object(struct object *object, uint32_t mark)
|
|
|
|
{
|
|
|
|
add_decoration(&idnums, object, mark_to_ptr(mark));
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void mark_next_object(struct object *object)
|
|
|
|
{
|
|
|
|
mark_object(object, ++last_idnum);
|
2007-12-02 22:14:13 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static int get_object_mark(struct object *object)
|
|
|
|
{
|
|
|
|
void *decoration = lookup_decoration(&idnums, object);
|
|
|
|
if (!decoration)
|
|
|
|
return 0;
|
2008-06-11 19:17:04 +08:00
|
|
|
return ptr_to_mark(decoration);
|
2007-12-02 22:14:13 +08:00
|
|
|
}
|
|
|
|
|
2018-11-16 15:59:51 +08:00
|
|
|
static struct commit *rewrite_commit(struct commit *p)
|
|
|
|
{
|
|
|
|
for (;;) {
|
|
|
|
if (p->parents && p->parents->next)
|
|
|
|
break;
|
|
|
|
if (p->object.flags & UNINTERESTING)
|
|
|
|
break;
|
|
|
|
if (!(p->object.flags & TREESAME))
|
|
|
|
break;
|
|
|
|
if (!p->parents)
|
|
|
|
return NULL;
|
|
|
|
p = p->parents->item;
|
|
|
|
}
|
|
|
|
return p;
|
|
|
|
}
|
|
|
|
|
2007-12-02 22:14:13 +08:00
|
|
|
static void show_progress(void)
|
|
|
|
{
|
|
|
|
static int counter = 0;
|
|
|
|
if (!progress)
|
|
|
|
return;
|
|
|
|
if ((++counter % progress) == 0)
|
|
|
|
printf("progress %d objects\n", counter);
|
|
|
|
}
|
|
|
|
|
2014-08-28 01:01:28 +08:00
|
|
|
/*
|
|
|
|
* Ideally we would want some transformation of the blob data here
|
|
|
|
* that is unreversible, but would still be the same size and have
|
|
|
|
* the same data relationship to other blobs (so that we get the same
|
|
|
|
* delta and packing behavior as the original). But the first and last
|
|
|
|
* requirements there are probably mutually exclusive, so let's take
|
|
|
|
* the easy way out for now, and just generate arbitrary content.
|
|
|
|
*
|
|
|
|
* There's no need to cache this result with anonymize_mem, since
|
|
|
|
* we already handle blob content caching with marks.
|
|
|
|
*/
|
|
|
|
static char *anonymize_blob(unsigned long *size)
|
|
|
|
{
|
|
|
|
static int counter;
|
|
|
|
struct strbuf out = STRBUF_INIT;
|
|
|
|
strbuf_addf(&out, "anonymous blob %d", counter++);
|
|
|
|
*size = out.len;
|
|
|
|
return strbuf_detach(&out, NULL);
|
|
|
|
}
|
|
|
|
|
2017-02-22 07:47:23 +08:00
|
|
|
static void export_blob(const struct object_id *oid)
|
2007-12-02 22:14:13 +08:00
|
|
|
{
|
|
|
|
unsigned long size;
|
|
|
|
enum object_type type;
|
|
|
|
char *buf;
|
|
|
|
struct object *object;
|
2013-03-17 16:38:57 +08:00
|
|
|
int eaten;
|
2007-12-02 22:14:13 +08:00
|
|
|
|
2009-07-28 10:20:22 +08:00
|
|
|
if (no_data)
|
|
|
|
return;
|
|
|
|
|
2017-02-22 07:47:23 +08:00
|
|
|
if (is_null_oid(oid))
|
2007-12-02 22:14:13 +08:00
|
|
|
return;
|
|
|
|
|
2019-06-20 15:41:14 +08:00
|
|
|
object = lookup_object(the_repository, oid);
|
2013-03-17 16:38:57 +08:00
|
|
|
if (object && object->flags & SHOWN)
|
2007-12-02 22:14:13 +08:00
|
|
|
return;
|
|
|
|
|
2014-08-28 01:01:28 +08:00
|
|
|
if (anonymize) {
|
|
|
|
buf = anonymize_blob(&size);
|
2018-06-29 09:21:55 +08:00
|
|
|
object = (struct object *)lookup_blob(the_repository, oid);
|
2014-08-28 01:01:28 +08:00
|
|
|
eaten = 0;
|
|
|
|
} else {
|
2023-03-28 21:58:50 +08:00
|
|
|
buf = repo_read_object_file(the_repository, oid, &type, &size);
|
2014-08-28 01:01:28 +08:00
|
|
|
if (!buf)
|
2018-07-21 15:49:19 +08:00
|
|
|
die("could not read blob %s", oid_to_hex(oid));
|
2020-01-31 04:32:23 +08:00
|
|
|
if (check_object_signature(the_repository, oid, buf, size,
|
2022-02-05 07:48:32 +08:00
|
|
|
type) < 0)
|
2018-11-16 15:59:46 +08:00
|
|
|
die("oid mismatch in blob %s", oid_to_hex(oid));
|
2018-06-29 09:21:53 +08:00
|
|
|
object = parse_object_buffer(the_repository, oid, type,
|
|
|
|
size, buf, &eaten);
|
2014-08-28 01:01:28 +08:00
|
|
|
}
|
|
|
|
|
2013-03-17 16:38:57 +08:00
|
|
|
if (!object)
|
2017-02-22 07:47:23 +08:00
|
|
|
die("Could not read blob %s", oid_to_hex(oid));
|
2007-12-02 22:14:13 +08:00
|
|
|
|
2008-06-11 19:17:04 +08:00
|
|
|
mark_next_object(object);
|
2007-12-02 22:14:13 +08:00
|
|
|
|
2018-11-16 15:59:56 +08:00
|
|
|
printf("blob\nmark :%"PRIu32"\n", last_idnum);
|
|
|
|
if (show_original_ids)
|
|
|
|
printf("original-oid %s\n", oid_to_hex(oid));
|
2019-01-05 05:33:33 +08:00
|
|
|
printf("data %"PRIuMAX"\n", (uintmax_t)size);
|
2007-12-12 06:01:28 +08:00
|
|
|
if (size && fwrite(buf, size, 1, stdout) != 1)
|
2018-07-21 15:49:19 +08:00
|
|
|
die_errno("could not write blob '%s'", oid_to_hex(oid));
|
2007-12-02 22:14:13 +08:00
|
|
|
printf("\n");
|
|
|
|
|
|
|
|
show_progress();
|
|
|
|
|
|
|
|
object->flags |= SHOWN;
|
2013-03-17 16:38:57 +08:00
|
|
|
if (!eaten)
|
|
|
|
free(buf);
|
2007-12-02 22:14:13 +08:00
|
|
|
}
|
|
|
|
|
2010-07-09 21:10:55 +08:00
|
|
|
static int depth_first(const void *a_, const void *b_)
|
|
|
|
{
|
|
|
|
const struct diff_filepair *a = *((const struct diff_filepair **)a_);
|
|
|
|
const struct diff_filepair *b = *((const struct diff_filepair **)b_);
|
|
|
|
const char *name_a, *name_b;
|
|
|
|
int len_a, len_b, len;
|
|
|
|
int cmp;
|
|
|
|
|
|
|
|
name_a = a->one ? a->one->path : a->two->path;
|
|
|
|
name_b = b->one ? b->one->path : b->two->path;
|
|
|
|
|
|
|
|
len_a = strlen(name_a);
|
|
|
|
len_b = strlen(name_b);
|
|
|
|
len = (len_a < len_b) ? len_a : len_b;
|
|
|
|
|
|
|
|
/* strcmp will sort 'd' before 'd/e', we want 'd/e' before 'd' */
|
|
|
|
cmp = memcmp(name_a, name_b, len);
|
|
|
|
if (cmp)
|
|
|
|
return cmp;
|
2010-09-08 03:33:02 +08:00
|
|
|
cmp = len_b - len_a;
|
|
|
|
if (cmp)
|
|
|
|
return cmp;
|
|
|
|
/*
|
|
|
|
* Move 'R'ename entries last so that all references of the file
|
|
|
|
* appear in the output before it is renamed (e.g., when a file
|
|
|
|
* was copied and renamed in the same commit).
|
|
|
|
*/
|
|
|
|
return (a->status == 'R') - (b->status == 'R');
|
2010-07-09 21:10:55 +08:00
|
|
|
}
|
|
|
|
|
2014-08-28 01:01:28 +08:00
|
|
|
static void print_path_1(const char *path)
|
fast-export: quote paths in output
Many pathnames in a fast-import stream need to be quoted. In
particular:
1. Pathnames at the end of an "M" or "D" line need quoting
if they contain a LF or start with double-quote.
2. Pathnames on a "C" or "R" line need quoting as above,
but also if they contain spaces.
For (1), we weren't quoting at all. For (2), we put
double-quotes around the paths to handle spaces, but ignored
the possibility that they would need further quoting.
This patch checks whether each pathname needs c-style
quoting, and uses it. This is slightly overkill for (1),
which doesn't actually need to quote many characters that
vanilla c-style quoting does. However, it shouldn't hurt, as
any implementation needs to be ready to handle quoted
strings anyway.
In addition to adding a test, we have to tweak a test which
blindly assumed that case (2) would always use
double-quotes, whether it needed to or not.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-06 06:36:22 +08:00
|
|
|
{
|
|
|
|
int need_quote = quote_c_style(path, NULL, NULL, 0);
|
|
|
|
if (need_quote)
|
|
|
|
quote_c_style(path, NULL, stdout, 0);
|
2012-06-28 05:58:01 +08:00
|
|
|
else if (strchr(path, ' '))
|
|
|
|
printf("\"%s\"", path);
|
fast-export: quote paths in output
Many pathnames in a fast-import stream need to be quoted. In
particular:
1. Pathnames at the end of an "M" or "D" line need quoting
if they contain a LF or start with double-quote.
2. Pathnames on a "C" or "R" line need quoting as above,
but also if they contain spaces.
For (1), we weren't quoting at all. For (2), we put
double-quotes around the paths to handle spaces, but ignored
the possibility that they would need further quoting.
This patch checks whether each pathname needs c-style
quoting, and uses it. This is slightly overkill for (1),
which doesn't actually need to quote many characters that
vanilla c-style quoting does. However, it shouldn't hurt, as
any implementation needs to be ready to handle quoted
strings anyway.
In addition to adding a test, we have to tweak a test which
blindly assumed that case (2) would always use
double-quotes, whether it needed to or not.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-06 06:36:22 +08:00
|
|
|
else
|
|
|
|
printf("%s", path);
|
|
|
|
}
|
|
|
|
|
fast-export: drop data parameter from anonymous generators
The anonymization code has a specific generator callback for each type
of data (e.g., one for paths, one for oids, and so on). These all take a
"data" parameter, but none of them use it for anything. Which is not
surprising, as the point is to generate a new name independent of any
input, and each function keeps its own static counter.
We added the extra pointer in d5bf91fde44 (fast-export: add a "data"
callback parameter to anonymize_str(), 2020-06-23) to handle
--anonymize-map parsing, but that turned out to be awkward itself, and
was recently dropped.
So let's get rid of this "data" parameter that nobody is using, both
from the generators and from anonymize_str() which plumbed it through.
This simplifies the code, and makes -Wunused-parameter happier.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-23 01:42:51 +08:00
|
|
|
static char *anonymize_path_component(void)
|
2014-08-28 01:01:28 +08:00
|
|
|
{
|
|
|
|
static int counter;
|
|
|
|
struct strbuf out = STRBUF_INIT;
|
|
|
|
strbuf_addf(&out, "path%d", counter++);
|
2020-06-23 23:24:54 +08:00
|
|
|
return strbuf_detach(&out, NULL);
|
2014-08-28 01:01:28 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void print_path(const char *path)
|
|
|
|
{
|
|
|
|
if (!anonymize)
|
|
|
|
print_path_1(path);
|
|
|
|
else {
|
|
|
|
static struct hashmap paths;
|
|
|
|
static struct strbuf anon = STRBUF_INIT;
|
|
|
|
|
|
|
|
anonymize_path(&anon, path, &paths, anonymize_path_component);
|
|
|
|
print_path_1(anon.buf);
|
|
|
|
strbuf_reset(&anon);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
fast-export: drop data parameter from anonymous generators
The anonymization code has a specific generator callback for each type
of data (e.g., one for paths, one for oids, and so on). These all take a
"data" parameter, but none of them use it for anything. Which is not
surprising, as the point is to generate a new name independent of any
input, and each function keeps its own static counter.
We added the extra pointer in d5bf91fde44 (fast-export: add a "data"
callback parameter to anonymize_str(), 2020-06-23) to handle
--anonymize-map parsing, but that turned out to be awkward itself, and
was recently dropped.
So let's get rid of this "data" parameter that nobody is using, both
from the generators and from anonymize_str() which plumbed it through.
This simplifies the code, and makes -Wunused-parameter happier.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-23 01:42:51 +08:00
|
|
|
static char *generate_fake_oid(void)
|
2014-08-28 01:01:28 +08:00
|
|
|
{
|
2018-11-16 15:59:46 +08:00
|
|
|
static uint32_t counter = 1; /* avoid null oid */
|
|
|
|
const unsigned hashsz = the_hash_algo->rawsz;
|
2020-09-25 03:22:29 +08:00
|
|
|
struct object_id oid;
|
2020-06-23 23:24:51 +08:00
|
|
|
char *hex = xmallocz(GIT_MAX_HEXSZ);
|
|
|
|
|
2020-09-25 03:22:29 +08:00
|
|
|
oidclr(&oid);
|
|
|
|
put_be32(oid.hash + hashsz - 4, counter++);
|
|
|
|
return oid_to_hex_r(hex, &oid);
|
2014-08-28 01:01:28 +08:00
|
|
|
}
|
|
|
|
|
2020-06-23 23:24:51 +08:00
|
|
|
static const char *anonymize_oid(const char *oid_hex)
|
2014-08-28 01:01:28 +08:00
|
|
|
{
|
2018-11-16 15:59:46 +08:00
|
|
|
static struct hashmap objs;
|
2020-06-23 23:24:51 +08:00
|
|
|
size_t len = strlen(oid_hex);
|
fast-export: drop data parameter from anonymous generators
The anonymization code has a specific generator callback for each type
of data (e.g., one for paths, one for oids, and so on). These all take a
"data" parameter, but none of them use it for anything. Which is not
surprising, as the point is to generate a new name independent of any
input, and each function keeps its own static counter.
We added the extra pointer in d5bf91fde44 (fast-export: add a "data"
callback parameter to anonymize_str(), 2020-06-23) to handle
--anonymize-map parsing, but that turned out to be awkward itself, and
was recently dropped.
So let's get rid of this "data" parameter that nobody is using, both
from the generators and from anonymize_str() which plumbed it through.
This simplifies the code, and makes -Wunused-parameter happier.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-23 01:42:51 +08:00
|
|
|
return anonymize_str(&objs, generate_fake_oid, oid_hex, len);
|
2014-08-28 01:01:28 +08:00
|
|
|
}
|
|
|
|
|
2007-12-02 22:14:13 +08:00
|
|
|
static void show_filemodify(struct diff_queue_struct *q,
|
2022-12-13 19:13:48 +08:00
|
|
|
struct diff_options *options UNUSED, void *data)
|
2007-12-02 22:14:13 +08:00
|
|
|
{
|
|
|
|
int i;
|
2017-09-21 07:55:02 +08:00
|
|
|
struct string_list *changed = data;
|
2010-07-09 21:10:55 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Handle files below a directory first, in case they are all deleted
|
|
|
|
* and the directory changes to a file or symlink.
|
|
|
|
*/
|
2016-09-29 23:27:31 +08:00
|
|
|
QSORT(q->queue, q->nr, depth_first);
|
2010-07-09 21:10:55 +08:00
|
|
|
|
2007-12-02 22:14:13 +08:00
|
|
|
for (i = 0; i < q->nr; i++) {
|
2008-07-27 04:52:54 +08:00
|
|
|
struct diff_filespec *ospec = q->queue[i]->one;
|
2007-12-02 22:14:13 +08:00
|
|
|
struct diff_filespec *spec = q->queue[i]->two;
|
2008-07-27 04:52:54 +08:00
|
|
|
|
|
|
|
switch (q->queue[i]->status) {
|
|
|
|
case DIFF_STATUS_DELETED:
|
fast-export: quote paths in output
Many pathnames in a fast-import stream need to be quoted. In
particular:
1. Pathnames at the end of an "M" or "D" line need quoting
if they contain a LF or start with double-quote.
2. Pathnames on a "C" or "R" line need quoting as above,
but also if they contain spaces.
For (1), we weren't quoting at all. For (2), we put
double-quotes around the paths to handle spaces, but ignored
the possibility that they would need further quoting.
This patch checks whether each pathname needs c-style
quoting, and uses it. This is slightly overkill for (1),
which doesn't actually need to quote many characters that
vanilla c-style quoting does. However, it shouldn't hurt, as
any implementation needs to be ready to handle quoted
strings anyway.
In addition to adding a test, we have to tweak a test which
blindly assumed that case (2) would always use
double-quotes, whether it needed to or not.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-06 06:36:22 +08:00
|
|
|
printf("D ");
|
|
|
|
print_path(spec->path);
|
2017-09-21 07:55:02 +08:00
|
|
|
string_list_insert(changed, spec->path);
|
fast-export: quote paths in output
Many pathnames in a fast-import stream need to be quoted. In
particular:
1. Pathnames at the end of an "M" or "D" line need quoting
if they contain a LF or start with double-quote.
2. Pathnames on a "C" or "R" line need quoting as above,
but also if they contain spaces.
For (1), we weren't quoting at all. For (2), we put
double-quotes around the paths to handle spaces, but ignored
the possibility that they would need further quoting.
This patch checks whether each pathname needs c-style
quoting, and uses it. This is slightly overkill for (1),
which doesn't actually need to quote many characters that
vanilla c-style quoting does. However, it shouldn't hurt, as
any implementation needs to be ready to handle quoted
strings anyway.
In addition to adding a test, we have to tweak a test which
blindly assumed that case (2) would always use
double-quotes, whether it needed to or not.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-06 06:36:22 +08:00
|
|
|
putchar('\n');
|
2008-07-27 04:52:54 +08:00
|
|
|
break;
|
|
|
|
|
|
|
|
case DIFF_STATUS_COPIED:
|
|
|
|
case DIFF_STATUS_RENAMED:
|
2017-09-21 07:55:02 +08:00
|
|
|
/*
|
|
|
|
* If a change in the file corresponding to ospec->path
|
|
|
|
* has been observed, we cannot trust its contents
|
|
|
|
* because the diff is calculated based on the prior
|
|
|
|
* contents, not the current contents. So, declare a
|
|
|
|
* copy or rename only if there was no change observed.
|
|
|
|
*/
|
|
|
|
if (!string_list_has_string(changed, ospec->path)) {
|
|
|
|
printf("%c ", q->queue[i]->status);
|
|
|
|
print_path(ospec->path);
|
|
|
|
putchar(' ');
|
|
|
|
print_path(spec->path);
|
|
|
|
string_list_insert(changed, spec->path);
|
|
|
|
putchar('\n');
|
|
|
|
|
convert "oidcmp() == 0" to oideq()
Using the more restrictive oideq() should, in the long run,
give the compiler more opportunities to optimize these
callsites. For now, this conversion should be a complete
noop with respect to the generated code.
The result is also perhaps a little more readable, as it
avoids the "zero is equal" idiom. Since it's so prevalent in
C, I think seasoned programmers tend not to even notice it
anymore, but it can sometimes make for awkward double
negations (e.g., we can drop a few !!oidcmp() instances
here).
This patch was generated almost entirely by the included
coccinelle patch. This mechanical conversion should be
completely safe, because we check explicitly for cases where
oidcmp() is compared to 0, which is what oideq() is doing
under the hood. Note that we don't have to catch "!oidcmp()"
separately; coccinelle's standard isomorphisms make sure the
two are treated equivalently.
I say "almost" because I did hand-edit the coccinelle output
to fix up a few style violations (it mostly keeps the
original formatting, but sometimes unwraps long lines).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-29 05:22:40 +08:00
|
|
|
if (oideq(&ospec->oid, &spec->oid) &&
|
2017-09-21 07:55:02 +08:00
|
|
|
ospec->mode == spec->mode)
|
|
|
|
break;
|
|
|
|
}
|
2008-07-27 04:52:54 +08:00
|
|
|
/* fallthrough */
|
|
|
|
|
|
|
|
case DIFF_STATUS_TYPE_CHANGED:
|
|
|
|
case DIFF_STATUS_MODIFIED:
|
|
|
|
case DIFF_STATUS_ADDED:
|
2008-07-19 20:21:24 +08:00
|
|
|
/*
|
|
|
|
* Links refer to objects in another repositories;
|
|
|
|
* output the SHA-1 verbatim.
|
|
|
|
*/
|
2009-07-28 10:20:22 +08:00
|
|
|
if (no_data || S_ISGITLINK(spec->mode))
|
fast-export: quote paths in output
Many pathnames in a fast-import stream need to be quoted. In
particular:
1. Pathnames at the end of an "M" or "D" line need quoting
if they contain a LF or start with double-quote.
2. Pathnames on a "C" or "R" line need quoting as above,
but also if they contain spaces.
For (1), we weren't quoting at all. For (2), we put
double-quotes around the paths to handle spaces, but ignored
the possibility that they would need further quoting.
This patch checks whether each pathname needs c-style
quoting, and uses it. This is slightly overkill for (1),
which doesn't actually need to quote many characters that
vanilla c-style quoting does. However, it shouldn't hurt, as
any implementation needs to be ready to handle quoted
strings anyway.
In addition to adding a test, we have to tweak a test which
blindly assumed that case (2) would always use
double-quotes, whether it needed to or not.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-06 06:36:22 +08:00
|
|
|
printf("M %06o %s ", spec->mode,
|
2020-06-23 23:24:51 +08:00
|
|
|
anonymize ?
|
|
|
|
anonymize_oid(oid_to_hex(&spec->oid)) :
|
|
|
|
oid_to_hex(&spec->oid));
|
2008-07-19 20:21:24 +08:00
|
|
|
else {
|
2018-06-29 09:21:52 +08:00
|
|
|
struct object *object = lookup_object(the_repository,
|
2019-06-20 15:41:14 +08:00
|
|
|
&spec->oid);
|
fast-export: quote paths in output
Many pathnames in a fast-import stream need to be quoted. In
particular:
1. Pathnames at the end of an "M" or "D" line need quoting
if they contain a LF or start with double-quote.
2. Pathnames on a "C" or "R" line need quoting as above,
but also if they contain spaces.
For (1), we weren't quoting at all. For (2), we put
double-quotes around the paths to handle spaces, but ignored
the possibility that they would need further quoting.
This patch checks whether each pathname needs c-style
quoting, and uses it. This is slightly overkill for (1),
which doesn't actually need to quote many characters that
vanilla c-style quoting does. However, it shouldn't hurt, as
any implementation needs to be ready to handle quoted
strings anyway.
In addition to adding a test, we have to tweak a test which
blindly assumed that case (2) would always use
double-quotes, whether it needed to or not.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-06 06:36:22 +08:00
|
|
|
printf("M %06o :%d ", spec->mode,
|
|
|
|
get_object_mark(object));
|
2008-07-19 20:21:24 +08:00
|
|
|
}
|
fast-export: quote paths in output
Many pathnames in a fast-import stream need to be quoted. In
particular:
1. Pathnames at the end of an "M" or "D" line need quoting
if they contain a LF or start with double-quote.
2. Pathnames on a "C" or "R" line need quoting as above,
but also if they contain spaces.
For (1), we weren't quoting at all. For (2), we put
double-quotes around the paths to handle spaces, but ignored
the possibility that they would need further quoting.
This patch checks whether each pathname needs c-style
quoting, and uses it. This is slightly overkill for (1),
which doesn't actually need to quote many characters that
vanilla c-style quoting does. However, it shouldn't hurt, as
any implementation needs to be ready to handle quoted
strings anyway.
In addition to adding a test, we have to tweak a test which
blindly assumed that case (2) would always use
double-quotes, whether it needed to or not.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-06 06:36:22 +08:00
|
|
|
print_path(spec->path);
|
2017-09-21 07:55:02 +08:00
|
|
|
string_list_insert(changed, spec->path);
|
fast-export: quote paths in output
Many pathnames in a fast-import stream need to be quoted. In
particular:
1. Pathnames at the end of an "M" or "D" line need quoting
if they contain a LF or start with double-quote.
2. Pathnames on a "C" or "R" line need quoting as above,
but also if they contain spaces.
For (1), we weren't quoting at all. For (2), we put
double-quotes around the paths to handle spaces, but ignored
the possibility that they would need further quoting.
This patch checks whether each pathname needs c-style
quoting, and uses it. This is slightly overkill for (1),
which doesn't actually need to quote many characters that
vanilla c-style quoting does. However, it shouldn't hurt, as
any implementation needs to be ready to handle quoted
strings anyway.
In addition to adding a test, we have to tweak a test which
blindly assumed that case (2) would always use
double-quotes, whether it needed to or not.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-06 06:36:22 +08:00
|
|
|
putchar('\n');
|
2008-07-27 04:52:54 +08:00
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
|
|
|
die("Unexpected comparison status '%c' for %s, %s",
|
|
|
|
q->queue[i]->status,
|
|
|
|
ospec->path ? ospec->path : "none",
|
|
|
|
spec->path ? spec->path : "none");
|
2007-12-02 22:14:13 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
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)
|
2019-05-14 12:31:01 +08:00
|
|
|
return NULL;
|
2007-12-02 22:14:13 +08:00
|
|
|
bol += strlen(needle);
|
|
|
|
eol = strchrnul(bol, '\n');
|
|
|
|
*eol = '\0';
|
|
|
|
return bol;
|
|
|
|
}
|
|
|
|
|
fast-export: drop data parameter from anonymous generators
The anonymization code has a specific generator callback for each type
of data (e.g., one for paths, one for oids, and so on). These all take a
"data" parameter, but none of them use it for anything. Which is not
surprising, as the point is to generate a new name independent of any
input, and each function keeps its own static counter.
We added the extra pointer in d5bf91fde44 (fast-export: add a "data"
callback parameter to anonymize_str(), 2020-06-23) to handle
--anonymize-map parsing, but that turned out to be awkward itself, and
was recently dropped.
So let's get rid of this "data" parameter that nobody is using, both
from the generators and from anonymize_str() which plumbed it through.
This simplifies the code, and makes -Wunused-parameter happier.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-23 01:42:51 +08:00
|
|
|
static char *anonymize_ref_component(void)
|
2014-08-28 01:01:28 +08:00
|
|
|
{
|
|
|
|
static int counter;
|
|
|
|
struct strbuf out = STRBUF_INIT;
|
|
|
|
strbuf_addf(&out, "ref%d", counter++);
|
2020-06-23 23:24:54 +08:00
|
|
|
return strbuf_detach(&out, NULL);
|
2014-08-28 01:01:28 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static const char *anonymize_refname(const char *refname)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* If any of these prefixes is found, we will leave it intact
|
|
|
|
* so that tags remain tags and so forth.
|
|
|
|
*/
|
|
|
|
static const char *prefixes[] = {
|
|
|
|
"refs/heads/",
|
|
|
|
"refs/tags/",
|
|
|
|
"refs/remotes/",
|
|
|
|
"refs/"
|
|
|
|
};
|
|
|
|
static struct hashmap refs;
|
|
|
|
static struct strbuf anon = STRBUF_INIT;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
strbuf_reset(&anon);
|
|
|
|
for (i = 0; i < ARRAY_SIZE(prefixes); i++) {
|
|
|
|
if (skip_prefix(refname, prefixes[i], &refname)) {
|
|
|
|
strbuf_addstr(&anon, prefixes[i]);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
anonymize_path(&anon, refname, &refs, anonymize_ref_component);
|
|
|
|
return anon.buf;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We do not even bother to cache commit messages, as they are unlikely
|
|
|
|
* to be repeated verbatim, and it is not that interesting when they are.
|
|
|
|
*/
|
2023-03-23 01:43:22 +08:00
|
|
|
static char *anonymize_commit_message(void)
|
2014-08-28 01:01:28 +08:00
|
|
|
{
|
|
|
|
static int counter;
|
|
|
|
return xstrfmt("subject %d\n\nbody\n", counter++);
|
|
|
|
}
|
|
|
|
|
fast-export: drop data parameter from anonymous generators
The anonymization code has a specific generator callback for each type
of data (e.g., one for paths, one for oids, and so on). These all take a
"data" parameter, but none of them use it for anything. Which is not
surprising, as the point is to generate a new name independent of any
input, and each function keeps its own static counter.
We added the extra pointer in d5bf91fde44 (fast-export: add a "data"
callback parameter to anonymize_str(), 2020-06-23) to handle
--anonymize-map parsing, but that turned out to be awkward itself, and
was recently dropped.
So let's get rid of this "data" parameter that nobody is using, both
from the generators and from anonymize_str() which plumbed it through.
This simplifies the code, and makes -Wunused-parameter happier.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-23 01:42:51 +08:00
|
|
|
static char *anonymize_ident(void)
|
2014-08-28 01:01:28 +08:00
|
|
|
{
|
|
|
|
static int counter;
|
|
|
|
struct strbuf out = STRBUF_INIT;
|
|
|
|
strbuf_addf(&out, "User %d <user%d@example.com>", counter, counter);
|
|
|
|
counter++;
|
2020-06-23 23:24:54 +08:00
|
|
|
return strbuf_detach(&out, NULL);
|
2014-08-28 01:01:28 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Our strategy here is to anonymize the names and email addresses,
|
|
|
|
* but keep timestamps intact, as they influence things like traversal
|
|
|
|
* order (and by themselves should not be too revealing).
|
|
|
|
*/
|
|
|
|
static void anonymize_ident_line(const char **beg, const char **end)
|
|
|
|
{
|
2020-06-23 23:25:01 +08:00
|
|
|
static struct hashmap idents;
|
2014-08-28 01:01:28 +08:00
|
|
|
static struct strbuf buffers[] = { STRBUF_INIT, STRBUF_INIT };
|
|
|
|
static unsigned which_buffer;
|
|
|
|
|
|
|
|
struct strbuf *out;
|
|
|
|
struct ident_split split;
|
|
|
|
const char *end_of_header;
|
|
|
|
|
|
|
|
out = &buffers[which_buffer++];
|
|
|
|
which_buffer %= ARRAY_SIZE(buffers);
|
|
|
|
strbuf_reset(out);
|
|
|
|
|
|
|
|
/* skip "committer", "author", "tagger", etc */
|
|
|
|
end_of_header = strchr(*beg, ' ');
|
|
|
|
if (!end_of_header)
|
2018-05-02 17:38:39 +08:00
|
|
|
BUG("malformed line fed to anonymize_ident_line: %.*s",
|
2014-08-28 01:01:28 +08:00
|
|
|
(int)(*end - *beg), *beg);
|
|
|
|
end_of_header++;
|
|
|
|
strbuf_add(out, *beg, end_of_header - *beg);
|
|
|
|
|
|
|
|
if (!split_ident_line(&split, end_of_header, *end - end_of_header) &&
|
|
|
|
split.date_begin) {
|
|
|
|
const char *ident;
|
|
|
|
size_t len;
|
|
|
|
|
|
|
|
len = split.mail_end - split.name_begin;
|
2020-06-23 23:24:54 +08:00
|
|
|
ident = anonymize_str(&idents, anonymize_ident,
|
fast-export: drop data parameter from anonymous generators
The anonymization code has a specific generator callback for each type
of data (e.g., one for paths, one for oids, and so on). These all take a
"data" parameter, but none of them use it for anything. Which is not
surprising, as the point is to generate a new name independent of any
input, and each function keeps its own static counter.
We added the extra pointer in d5bf91fde44 (fast-export: add a "data"
callback parameter to anonymize_str(), 2020-06-23) to handle
--anonymize-map parsing, but that turned out to be awkward itself, and
was recently dropped.
So let's get rid of this "data" parameter that nobody is using, both
from the generators and from anonymize_str() which plumbed it through.
This simplifies the code, and makes -Wunused-parameter happier.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-23 01:42:51 +08:00
|
|
|
split.name_begin, len);
|
2020-06-23 23:24:54 +08:00
|
|
|
strbuf_addstr(out, ident);
|
2014-08-28 01:01:28 +08:00
|
|
|
strbuf_addch(out, ' ');
|
|
|
|
strbuf_add(out, split.date_begin, split.tz_end - split.date_begin);
|
|
|
|
} else {
|
|
|
|
strbuf_addstr(out, "Malformed Ident <malformed@example.com> 0 -0000");
|
|
|
|
}
|
|
|
|
|
|
|
|
*beg = out->buf;
|
|
|
|
*end = out->buf + out->len;
|
|
|
|
}
|
|
|
|
|
2017-09-21 07:55:02 +08:00
|
|
|
static void handle_commit(struct commit *commit, struct rev_info *rev,
|
|
|
|
struct string_list *paths_of_changed_objects)
|
2007-12-02 22:14:13 +08:00
|
|
|
{
|
|
|
|
int saved_output_format = rev->diffopt.output_format;
|
2014-06-11 05:41:51 +08:00
|
|
|
const char *commit_buffer;
|
2007-12-02 22:14:13 +08:00
|
|
|
const char *author, *author_end, *committer, *committer_end;
|
|
|
|
const char *encoding, *message;
|
|
|
|
char *reencoded = NULL;
|
|
|
|
struct commit_list *p;
|
2014-08-28 01:01:28 +08:00
|
|
|
const char *refname;
|
2007-12-02 22:14:13 +08:00
|
|
|
int i;
|
|
|
|
|
|
|
|
rev->diffopt.output_format = DIFF_FORMAT_CALLBACK;
|
|
|
|
|
2013-10-24 16:53:46 +08:00
|
|
|
parse_commit_or_die(commit);
|
2023-03-28 21:58:48 +08:00
|
|
|
commit_buffer = repo_get_commit_buffer(the_repository, commit, NULL);
|
2014-06-11 05:41:51 +08:00
|
|
|
author = strstr(commit_buffer, "\nauthor ");
|
2007-12-02 22:14:13 +08:00
|
|
|
if (!author)
|
2018-07-21 15:49:19 +08:00
|
|
|
die("could not find author in commit %s",
|
|
|
|
oid_to_hex(&commit->object.oid));
|
2007-12-02 22:14:13 +08:00
|
|
|
author++;
|
|
|
|
author_end = strchrnul(author, '\n');
|
|
|
|
committer = strstr(author_end, "\ncommitter ");
|
|
|
|
if (!committer)
|
2018-07-21 15:49:19 +08:00
|
|
|
die("could not find committer in commit %s",
|
|
|
|
oid_to_hex(&commit->object.oid));
|
2007-12-02 22:14:13 +08:00
|
|
|
committer++;
|
|
|
|
committer_end = strchrnul(committer, '\n');
|
|
|
|
message = strstr(committer_end, "\n\n");
|
|
|
|
encoding = find_encoding(committer_end, message);
|
|
|
|
if (message)
|
|
|
|
message += 2;
|
|
|
|
|
2009-03-26 07:53:23 +08:00
|
|
|
if (commit->parents &&
|
fast-export: add --reference-excluded-parents option
git filter-branch has a nifty feature allowing you to rewrite, e.g. just
the last 8 commits of a linear history
git filter-branch $OPTIONS HEAD~8..HEAD
If you try the same with git fast-export, you instead get a history of
only 8 commits, with HEAD~7 being rewritten into a root commit. There
are two alternatives:
1) Don't use the negative revision specification, and when you're
filtering the output to make modifications to the last 8 commits,
just be careful to not modify any earlier commits somehow.
2) First run 'git fast-export --export-marks=somefile HEAD~8', then
run 'git fast-export --import-marks=somefile HEAD~8..HEAD'.
Both are more error prone than I'd like (the first for obvious reasons;
with the second option I have sometimes accidentally included too many
revisions in the first command and then found that the corresponding
extra revisions were not exported by the second command and thus were
not modified as I expected). Also, both are poor from a performance
perspective.
Add a new --reference-excluded-parents option which will cause
fast-export to refer to commits outside the specified rev-list-args
range by their sha1sum. Such a stream will only be useful in a
repository which already contains the necessary commits (much like the
restriction imposed when using --no-data).
Note from Peff:
I think we might be able to do a little more optimization here. If
we're exporting HEAD^..HEAD and there's an object in HEAD^ which is
unchanged in HEAD, I think we'd still print it (because it would not
be marked SHOWN), but we could omit it (by walking the tree of the
boundary commits and marking them shown). I don't think it's a
blocker for what you're doing here, but just a possible future
optimization.
Signed-off-by: Elijah Newren <newren@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-16 15:59:54 +08:00
|
|
|
(get_object_mark(&commit->parents->item->object) != 0 ||
|
|
|
|
reference_excluded_commits) &&
|
2010-07-18 01:00:50 +08:00
|
|
|
!full_tree) {
|
2013-10-24 16:53:46 +08:00
|
|
|
parse_commit_or_die(commit->parents->item);
|
2018-04-07 03:09:38 +08:00
|
|
|
diff_tree_oid(get_commit_tree_oid(commit->parents->item),
|
|
|
|
get_commit_tree_oid(commit), "", &rev->diffopt);
|
2007-12-02 22:14:13 +08:00
|
|
|
}
|
|
|
|
else
|
2018-04-07 03:09:38 +08:00
|
|
|
diff_root_tree_oid(get_commit_tree_oid(commit),
|
2017-05-31 01:30:57 +08:00
|
|
|
"", &rev->diffopt);
|
2007-12-02 22:14:13 +08:00
|
|
|
|
2008-07-19 20:21:24 +08:00
|
|
|
/* Export the referenced blobs, and remember the marks. */
|
2007-12-02 22:14:13 +08:00
|
|
|
for (i = 0; i < diff_queued_diff.nr; i++)
|
2008-07-19 20:21:24 +08:00
|
|
|
if (!S_ISGITLINK(diff_queued_diff.queue[i]->two->mode))
|
2017-02-22 07:47:23 +08:00
|
|
|
export_blob(&diff_queued_diff.queue[i]->two->oid);
|
2007-12-02 22:14:13 +08:00
|
|
|
|
2018-05-19 13:28:24 +08:00
|
|
|
refname = *revision_sources_at(&revision_sources, commit);
|
2018-11-16 15:59:53 +08:00
|
|
|
/*
|
|
|
|
* FIXME: string_list_remove() below for each ref is overall
|
|
|
|
* O(N^2). Compared to a history walk and diffing trees, this is
|
|
|
|
* just lost in the noise in practice. However, theoretically a
|
|
|
|
* repo may have enough refs for this to become slow.
|
|
|
|
*/
|
|
|
|
string_list_remove(&extra_refs, refname, 0);
|
2014-08-28 01:01:28 +08:00
|
|
|
if (anonymize) {
|
|
|
|
refname = anonymize_refname(refname);
|
|
|
|
anonymize_ident_line(&committer, &committer_end);
|
|
|
|
anonymize_ident_line(&author, &author_end);
|
|
|
|
}
|
|
|
|
|
2008-06-11 19:17:04 +08:00
|
|
|
mark_next_object(&commit->object);
|
2019-05-14 12:31:02 +08:00
|
|
|
if (anonymize) {
|
2023-03-23 01:43:22 +08:00
|
|
|
reencoded = anonymize_commit_message();
|
2019-05-14 12:31:02 +08:00
|
|
|
} else if (encoding) {
|
|
|
|
switch(reencode_mode) {
|
|
|
|
case REENCODE_YES:
|
|
|
|
reencoded = reencode_string(message, "UTF-8", encoding);
|
|
|
|
break;
|
|
|
|
case REENCODE_NO:
|
|
|
|
break;
|
|
|
|
case REENCODE_ABORT:
|
|
|
|
die("Encountered commit-specific encoding %s in commit "
|
|
|
|
"%s; use --reencode=[yes|no] to handle it",
|
|
|
|
encoding, oid_to_hex(&commit->object.oid));
|
|
|
|
}
|
|
|
|
}
|
2008-06-13 12:38:55 +08:00
|
|
|
if (!commit->parents)
|
2014-08-28 01:01:28 +08:00
|
|
|
printf("reset %s\n", refname);
|
2018-11-16 15:59:56 +08:00
|
|
|
printf("commit %s\nmark :%"PRIu32"\n", refname, last_idnum);
|
|
|
|
if (show_original_ids)
|
|
|
|
printf("original-oid %s\n", oid_to_hex(&commit->object.oid));
|
2019-05-14 12:31:00 +08:00
|
|
|
printf("%.*s\n%.*s\n",
|
2007-12-02 22:14:13 +08:00
|
|
|
(int)(author_end - author), author,
|
2019-05-14 12:31:00 +08:00
|
|
|
(int)(committer_end - committer), committer);
|
|
|
|
if (!reencoded && encoding)
|
|
|
|
printf("encoding %s\n", encoding);
|
|
|
|
printf("data %u\n%s",
|
2007-12-02 22:14:13 +08:00
|
|
|
(unsigned)(reencoded
|
|
|
|
? strlen(reencoded) : message
|
|
|
|
? strlen(message) : 0),
|
|
|
|
reencoded ? reencoded : message ? message : "");
|
Avoid unnecessary "if-before-free" tests.
This change removes all obvious useless if-before-free tests.
E.g., it replaces code like this:
if (some_expression)
free (some_expression);
with the now-equivalent:
free (some_expression);
It is equivalent not just because POSIX has required free(NULL)
to work for a long time, but simply because it has worked for
so long that no reasonable porting target fails the test.
Here's some evidence from nearly 1.5 years ago:
http://www.winehq.org/pipermail/wine-patches/2006-October/031544.html
FYI, the change below was prepared by running the following:
git ls-files -z | xargs -0 \
perl -0x3b -pi -e \
's/\bif\s*\(\s*(\S+?)(?:\s*!=\s*NULL)?\s*\)\s+(free\s*\(\s*\1\s*\))/$2/s'
Note however, that it doesn't handle brace-enclosed blocks like
"if (x) { free (x); }". But that's ok, since there were none like
that in git sources.
Beware: if you do use the above snippet, note that it can
produce syntactically invalid C code. That happens when the
affected "if"-statement has a matching "else".
E.g., it would transform this
if (x)
free (x);
else
foo ();
into this:
free (x);
else
foo ();
There were none of those here, either.
If you're interested in automating detection of the useless
tests, you might like the useless-if-before-free script in gnulib:
[it *does* detect brace-enclosed free statements, and has a --name=S
option to make it detect free-like functions with different names]
http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=blob;f=build-aux/useless-if-before-free
Addendum:
Remove one more (in imap-send.c), spotted by Jean-Luc Herren <jlh@gmx.ch>.
Signed-off-by: Jim Meyering <meyering@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-01 01:26:32 +08:00
|
|
|
free(reencoded);
|
2023-03-28 21:58:48 +08:00
|
|
|
repo_unuse_commit_buffer(the_repository, commit, commit_buffer);
|
2007-12-02 22:14:13 +08:00
|
|
|
|
|
|
|
for (i = 0, p = commit->parents; p; p = p->next) {
|
fast-export: add --reference-excluded-parents option
git filter-branch has a nifty feature allowing you to rewrite, e.g. just
the last 8 commits of a linear history
git filter-branch $OPTIONS HEAD~8..HEAD
If you try the same with git fast-export, you instead get a history of
only 8 commits, with HEAD~7 being rewritten into a root commit. There
are two alternatives:
1) Don't use the negative revision specification, and when you're
filtering the output to make modifications to the last 8 commits,
just be careful to not modify any earlier commits somehow.
2) First run 'git fast-export --export-marks=somefile HEAD~8', then
run 'git fast-export --import-marks=somefile HEAD~8..HEAD'.
Both are more error prone than I'd like (the first for obvious reasons;
with the second option I have sometimes accidentally included too many
revisions in the first command and then found that the corresponding
extra revisions were not exported by the second command and thus were
not modified as I expected). Also, both are poor from a performance
perspective.
Add a new --reference-excluded-parents option which will cause
fast-export to refer to commits outside the specified rev-list-args
range by their sha1sum. Such a stream will only be useful in a
repository which already contains the necessary commits (much like the
restriction imposed when using --no-data).
Note from Peff:
I think we might be able to do a little more optimization here. If
we're exporting HEAD^..HEAD and there's an object in HEAD^ which is
unchanged in HEAD, I think we'd still print it (because it would not
be marked SHOWN), but we could omit it (by walking the tree of the
boundary commits and marking them shown). I don't think it's a
blocker for what you're doing here, but just a possible future
optimization.
Signed-off-by: Elijah Newren <newren@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-16 15:59:54 +08:00
|
|
|
struct object *obj = &p->item->object;
|
|
|
|
int mark = get_object_mark(obj);
|
|
|
|
|
|
|
|
if (!mark && !reference_excluded_commits)
|
2007-12-02 22:14:13 +08:00
|
|
|
continue;
|
|
|
|
if (i == 0)
|
fast-export: add --reference-excluded-parents option
git filter-branch has a nifty feature allowing you to rewrite, e.g. just
the last 8 commits of a linear history
git filter-branch $OPTIONS HEAD~8..HEAD
If you try the same with git fast-export, you instead get a history of
only 8 commits, with HEAD~7 being rewritten into a root commit. There
are two alternatives:
1) Don't use the negative revision specification, and when you're
filtering the output to make modifications to the last 8 commits,
just be careful to not modify any earlier commits somehow.
2) First run 'git fast-export --export-marks=somefile HEAD~8', then
run 'git fast-export --import-marks=somefile HEAD~8..HEAD'.
Both are more error prone than I'd like (the first for obvious reasons;
with the second option I have sometimes accidentally included too many
revisions in the first command and then found that the corresponding
extra revisions were not exported by the second command and thus were
not modified as I expected). Also, both are poor from a performance
perspective.
Add a new --reference-excluded-parents option which will cause
fast-export to refer to commits outside the specified rev-list-args
range by their sha1sum. Such a stream will only be useful in a
repository which already contains the necessary commits (much like the
restriction imposed when using --no-data).
Note from Peff:
I think we might be able to do a little more optimization here. If
we're exporting HEAD^..HEAD and there's an object in HEAD^ which is
unchanged in HEAD, I think we'd still print it (because it would not
be marked SHOWN), but we could omit it (by walking the tree of the
boundary commits and marking them shown). I don't think it's a
blocker for what you're doing here, but just a possible future
optimization.
Signed-off-by: Elijah Newren <newren@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-16 15:59:54 +08:00
|
|
|
printf("from ");
|
|
|
|
else
|
|
|
|
printf("merge ");
|
|
|
|
if (mark)
|
|
|
|
printf(":%d\n", mark);
|
2007-12-02 22:14:13 +08:00
|
|
|
else
|
2020-06-23 23:24:51 +08:00
|
|
|
printf("%s\n",
|
|
|
|
anonymize ?
|
|
|
|
anonymize_oid(oid_to_hex(&obj->oid)) :
|
|
|
|
oid_to_hex(&obj->oid));
|
2007-12-02 22:14:13 +08:00
|
|
|
i++;
|
|
|
|
}
|
|
|
|
|
2010-07-18 01:00:50 +08:00
|
|
|
if (full_tree)
|
|
|
|
printf("deleteall\n");
|
2007-12-02 22:14:13 +08:00
|
|
|
log_tree_diff_flush(rev);
|
2017-09-21 07:55:02 +08:00
|
|
|
string_list_clear(paths_of_changed_objects, 0);
|
2007-12-02 22:14:13 +08:00
|
|
|
rev->diffopt.output_format = saved_output_format;
|
|
|
|
|
|
|
|
printf("\n");
|
|
|
|
|
|
|
|
show_progress();
|
|
|
|
}
|
|
|
|
|
fast-export: drop data parameter from anonymous generators
The anonymization code has a specific generator callback for each type
of data (e.g., one for paths, one for oids, and so on). These all take a
"data" parameter, but none of them use it for anything. Which is not
surprising, as the point is to generate a new name independent of any
input, and each function keeps its own static counter.
We added the extra pointer in d5bf91fde44 (fast-export: add a "data"
callback parameter to anonymize_str(), 2020-06-23) to handle
--anonymize-map parsing, but that turned out to be awkward itself, and
was recently dropped.
So let's get rid of this "data" parameter that nobody is using, both
from the generators and from anonymize_str() which plumbed it through.
This simplifies the code, and makes -Wunused-parameter happier.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-23 01:42:51 +08:00
|
|
|
static char *anonymize_tag(void)
|
2014-08-28 01:01:28 +08:00
|
|
|
{
|
|
|
|
static int counter;
|
|
|
|
struct strbuf out = STRBUF_INIT;
|
|
|
|
strbuf_addf(&out, "tag message %d", counter++);
|
2020-06-23 23:24:54 +08:00
|
|
|
return strbuf_detach(&out, NULL);
|
2014-08-28 01:01:28 +08:00
|
|
|
}
|
|
|
|
|
2007-12-02 22:14:13 +08:00
|
|
|
|
|
|
|
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;
|
2009-06-26 12:48:28 +08:00
|
|
|
struct object *tagged;
|
2009-06-26 12:48:31 +08:00
|
|
|
int tagged_mark;
|
|
|
|
struct commit *p;
|
2009-06-26 12:48:28 +08:00
|
|
|
|
2013-07-29 16:18:21 +08:00
|
|
|
/* Trees have no identifier in fast-export output, thus we have no way
|
2009-06-26 12:48:28 +08:00
|
|
|
* to output tags of trees, tags of tags of trees, etc. Simply omit
|
|
|
|
* such tags.
|
|
|
|
*/
|
|
|
|
tagged = tag->tagged;
|
|
|
|
while (tagged->type == OBJ_TAG) {
|
|
|
|
tagged = ((struct tag *)tagged)->tagged;
|
|
|
|
}
|
|
|
|
if (tagged->type == OBJ_TREE) {
|
|
|
|
warning("Omitting tag %s,\nsince tags of trees (or tags of tags of trees, etc.) are not supported.",
|
2015-11-10 10:22:28 +08:00
|
|
|
oid_to_hex(&tag->object.oid));
|
2009-06-26 12:48:28 +08:00
|
|
|
return;
|
|
|
|
}
|
2007-12-02 22:14:13 +08:00
|
|
|
|
2023-03-28 21:58:50 +08:00
|
|
|
buf = repo_read_object_file(the_repository, &tag->object.oid, &type,
|
|
|
|
&size);
|
2007-12-02 22:14:13 +08:00
|
|
|
if (!buf)
|
2018-07-21 15:49:19 +08:00
|
|
|
die("could not read tag %s", oid_to_hex(&tag->object.oid));
|
2007-12-02 22:14:13 +08:00
|
|
|
message = memmem(buf, size, "\n\n", 2);
|
|
|
|
if (message) {
|
|
|
|
message += 2;
|
|
|
|
message_size = strlen(message);
|
|
|
|
}
|
|
|
|
tagger = memmem(buf, message ? message - buf : size, "\ntagger ", 8);
|
2008-12-20 08:00:27 +08:00
|
|
|
if (!tagger) {
|
|
|
|
if (fake_missing_tagger)
|
|
|
|
tagger = "tagger Unspecified Tagger "
|
|
|
|
"<unspecified-tagger> 0 +0000";
|
|
|
|
else
|
|
|
|
tagger = "";
|
|
|
|
tagger_end = tagger + strlen(tagger);
|
|
|
|
} else {
|
|
|
|
tagger++;
|
|
|
|
tagger_end = strchrnul(tagger, '\n');
|
2014-08-28 01:01:28 +08:00
|
|
|
if (anonymize)
|
|
|
|
anonymize_ident_line(&tagger, &tagger_end);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (anonymize) {
|
|
|
|
name = anonymize_refname(name);
|
|
|
|
if (message) {
|
|
|
|
static struct hashmap tags;
|
2020-06-23 23:24:54 +08:00
|
|
|
message = anonymize_str(&tags, anonymize_tag,
|
fast-export: drop data parameter from anonymous generators
The anonymization code has a specific generator callback for each type
of data (e.g., one for paths, one for oids, and so on). These all take a
"data" parameter, but none of them use it for anything. Which is not
surprising, as the point is to generate a new name independent of any
input, and each function keeps its own static counter.
We added the extra pointer in d5bf91fde44 (fast-export: add a "data"
callback parameter to anonymize_str(), 2020-06-23) to handle
--anonymize-map parsing, but that turned out to be awkward itself, and
was recently dropped.
So let's get rid of this "data" parameter that nobody is using, both
from the generators and from anonymize_str() which plumbed it through.
This simplifies the code, and makes -Wunused-parameter happier.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-23 01:42:51 +08:00
|
|
|
message, message_size);
|
2021-08-31 23:55:54 +08:00
|
|
|
message_size = strlen(message);
|
2014-08-28 01:01:28 +08:00
|
|
|
}
|
2008-12-20 08:00:27 +08:00
|
|
|
}
|
2007-12-02 22:14:13 +08:00
|
|
|
|
|
|
|
/* handle signed tags */
|
|
|
|
if (message) {
|
|
|
|
const char *signature = strstr(message,
|
|
|
|
"\n-----BEGIN PGP SIGNATURE-----\n");
|
|
|
|
if (signature)
|
|
|
|
switch(signed_tag_mode) {
|
2018-11-16 15:59:49 +08:00
|
|
|
case SIGNED_TAG_ABORT:
|
2018-07-21 15:49:19 +08:00
|
|
|
die("encountered signed tag %s; use "
|
|
|
|
"--signed-tags=<mode> to handle it",
|
|
|
|
oid_to_hex(&tag->object.oid));
|
2007-12-02 22:14:13 +08:00
|
|
|
case WARN:
|
2018-07-21 15:49:19 +08:00
|
|
|
warning("exporting signed tag %s",
|
|
|
|
oid_to_hex(&tag->object.oid));
|
2007-12-02 22:14:13 +08:00
|
|
|
/* fallthru */
|
2007-12-04 06:44:39 +08:00
|
|
|
case VERBATIM:
|
2007-12-02 22:14:13 +08:00
|
|
|
break;
|
2013-04-14 18:57:06 +08:00
|
|
|
case WARN_STRIP:
|
2018-07-21 15:49:19 +08:00
|
|
|
warning("stripping signature from tag %s",
|
|
|
|
oid_to_hex(&tag->object.oid));
|
2013-04-14 18:57:06 +08:00
|
|
|
/* fallthru */
|
2007-12-02 22:14:13 +08:00
|
|
|
case STRIP:
|
|
|
|
message_size = signature + 1 - message;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-06-26 12:48:31 +08:00
|
|
|
/* handle tag->tagged having been filtered out due to paths specified */
|
|
|
|
tagged = tag->tagged;
|
|
|
|
tagged_mark = get_object_mark(tagged);
|
|
|
|
if (!tagged_mark) {
|
|
|
|
switch(tag_of_filtered_mode) {
|
2018-11-16 15:59:49 +08:00
|
|
|
case TAG_FILTERING_ABORT:
|
2018-07-21 15:49:19 +08:00
|
|
|
die("tag %s tags unexported object; use "
|
|
|
|
"--tag-of-filtered-object=<mode> to handle it",
|
|
|
|
oid_to_hex(&tag->object.oid));
|
2009-06-26 12:48:31 +08:00
|
|
|
case DROP:
|
|
|
|
/* Ignore this tag altogether */
|
2017-05-04 21:57:33 +08:00
|
|
|
free(buf);
|
2009-06-26 12:48:31 +08:00
|
|
|
return;
|
|
|
|
case REWRITE:
|
2019-10-04 04:27:09 +08:00
|
|
|
if (tagged->type == OBJ_TAG && !mark_tags) {
|
|
|
|
die(_("Error: Cannot export nested tags unless --mark-tags is specified."));
|
|
|
|
} else if (tagged->type == OBJ_COMMIT) {
|
|
|
|
p = rewrite_commit((struct commit *)tagged);
|
|
|
|
if (!p) {
|
|
|
|
printf("reset %s\nfrom %s\n\n",
|
2021-04-26 09:02:56 +08:00
|
|
|
name, oid_to_hex(null_oid()));
|
2019-10-04 04:27:09 +08:00
|
|
|
free(buf);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
tagged_mark = get_object_mark(&p->object);
|
|
|
|
} else {
|
|
|
|
/* tagged->type is either OBJ_BLOB or OBJ_TAG */
|
|
|
|
tagged_mark = get_object_mark(tagged);
|
2009-06-26 12:48:31 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-10-04 04:27:09 +08:00
|
|
|
if (tagged->type == OBJ_TAG) {
|
|
|
|
printf("reset %s\nfrom %s\n\n",
|
2021-04-26 09:02:56 +08:00
|
|
|
name, oid_to_hex(null_oid()));
|
2019-10-04 04:27:09 +08:00
|
|
|
}
|
2020-01-31 03:35:46 +08:00
|
|
|
skip_prefix(name, "refs/tags/", &name);
|
2019-09-25 09:39:58 +08:00
|
|
|
printf("tag %s\n", name);
|
2019-10-04 04:27:07 +08:00
|
|
|
if (mark_tags) {
|
|
|
|
mark_next_object(&tag->object);
|
|
|
|
printf("mark :%"PRIu32"\n", last_idnum);
|
|
|
|
}
|
2019-09-25 09:39:58 +08:00
|
|
|
if (tagged_mark)
|
|
|
|
printf("from :%d\n", tagged_mark);
|
|
|
|
else
|
|
|
|
printf("from %s\n", oid_to_hex(&tagged->oid));
|
|
|
|
|
2018-11-16 15:59:56 +08:00
|
|
|
if (show_original_ids)
|
|
|
|
printf("original-oid %s\n", oid_to_hex(&tag->object.oid));
|
|
|
|
printf("%.*s%sdata %d\n%.*s\n",
|
2007-12-02 22:14:13 +08:00
|
|
|
(int)(tagger_end - tagger), tagger,
|
2008-12-20 08:00:27 +08:00
|
|
|
tagger == tagger_end ? "" : "\n",
|
2007-12-02 22:14:13 +08:00
|
|
|
(int)message_size, (int)message_size, message ? message : "");
|
2017-05-04 21:57:33 +08:00
|
|
|
free(buf);
|
2007-12-02 22:14:13 +08:00
|
|
|
}
|
|
|
|
|
2013-09-01 15:05:48 +08:00
|
|
|
static struct commit *get_commit(struct rev_cmdline_entry *e, char *full_name)
|
|
|
|
{
|
|
|
|
switch (e->item->type) {
|
|
|
|
case OBJ_COMMIT:
|
|
|
|
return (struct commit *)e->item;
|
|
|
|
case OBJ_TAG: {
|
|
|
|
struct tag *tag = (struct tag *)e->item;
|
|
|
|
|
|
|
|
/* handle nested tags */
|
|
|
|
while (tag && tag->object.type == OBJ_TAG) {
|
2018-06-29 09:21:51 +08:00
|
|
|
parse_object(the_repository, &tag->object.oid);
|
2018-11-16 15:59:53 +08:00
|
|
|
string_list_append(&tag_refs, full_name)->util = tag;
|
2013-09-01 15:05:48 +08:00
|
|
|
tag = (struct tag *)tag->tagged;
|
|
|
|
}
|
|
|
|
if (!tag)
|
|
|
|
die("Tag %s points nowhere?", e->name);
|
|
|
|
return (struct commit *)tag;
|
|
|
|
}
|
|
|
|
default:
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-09-01 15:05:47 +08:00
|
|
|
static void get_tags_and_duplicates(struct rev_cmdline_info *info)
|
2007-12-02 22:14:13 +08:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
fast-export: don't handle uninteresting refs
They have been marked as UNINTERESTING for a reason, lets respect
that. Currently the first ref is handled properly, but not the
rest. Assuming that all the refs point at the same commit in the
following example:
% git fast-export master ^uninteresting ^foo ^bar
reset refs/heads/bar
from :0
reset refs/heads/foo
from :0
reset refs/heads/uninteresting
from :0
% git fast-export ^uninteresting ^foo ^bar master
reset refs/heads/master
from :0
reset refs/heads/bar
from :0
reset refs/heads/foo
from :0
Clearly this is wrong; the negative refs should be ignored.
After this patch:
% git fast-export ^uninteresting ^foo ^bar master
# nothing
% git fast-export master ^uninteresting ^foo ^bar
# nothing
And even more, it would only happen if the ref is pointing to exactly
the same commit, but not otherwise:
% git fast-export ^next next
reset refs/heads/next
from :0
% git fast-export ^next next^{commit}
# nothing
% git fast-export ^next next~0
# nothing
% git fast-export ^next next~1
# nothing
% git fast-export ^next next~2
# nothing
The reason this happens is that before traversing the commits,
fast-export checks if any of the refs point to the same object, and any
duplicated ref gets added to a list in order to issue 'reset' commands
after the traversing. Unfortunately, it's not even checking if the
commit is flagged as UNINTERESTING. The fix of course, is to check it.
However, in order to do it properly we need to get the UNINTERESTING
flag from the command line, not from the commit object, because
"^foo bar" will mark the commit 'bar' uninteresting if foo and bar
points at the same commit. rev_cmdline_info, which was introduced
exactly to handle this situation, contains all the information we
need for get_tags_and_duplicates(), plus the ref flag. This way the
rest of the positive refs will remain untouched; it's only the
negative ones that change in behavior.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-29 06:23:59 +08:00
|
|
|
for (i = 0; i < info->nr; i++) {
|
|
|
|
struct rev_cmdline_entry *e = info->rev + i;
|
2017-02-22 07:47:23 +08:00
|
|
|
struct object_id oid;
|
2012-11-29 06:11:08 +08:00
|
|
|
struct commit *commit;
|
2007-12-02 22:14:13 +08:00
|
|
|
char *full_name;
|
|
|
|
|
fast-export: don't handle uninteresting refs
They have been marked as UNINTERESTING for a reason, lets respect
that. Currently the first ref is handled properly, but not the
rest. Assuming that all the refs point at the same commit in the
following example:
% git fast-export master ^uninteresting ^foo ^bar
reset refs/heads/bar
from :0
reset refs/heads/foo
from :0
reset refs/heads/uninteresting
from :0
% git fast-export ^uninteresting ^foo ^bar master
reset refs/heads/master
from :0
reset refs/heads/bar
from :0
reset refs/heads/foo
from :0
Clearly this is wrong; the negative refs should be ignored.
After this patch:
% git fast-export ^uninteresting ^foo ^bar master
# nothing
% git fast-export master ^uninteresting ^foo ^bar
# nothing
And even more, it would only happen if the ref is pointing to exactly
the same commit, but not otherwise:
% git fast-export ^next next
reset refs/heads/next
from :0
% git fast-export ^next next^{commit}
# nothing
% git fast-export ^next next~0
# nothing
% git fast-export ^next next~1
# nothing
% git fast-export ^next next~2
# nothing
The reason this happens is that before traversing the commits,
fast-export checks if any of the refs point to the same object, and any
duplicated ref gets added to a list in order to issue 'reset' commands
after the traversing. Unfortunately, it's not even checking if the
commit is flagged as UNINTERESTING. The fix of course, is to check it.
However, in order to do it properly we need to get the UNINTERESTING
flag from the command line, not from the commit object, because
"^foo bar" will mark the commit 'bar' uninteresting if foo and bar
points at the same commit. rev_cmdline_info, which was introduced
exactly to handle this situation, contains all the information we
need for get_tags_and_duplicates(), plus the ref flag. This way the
rest of the positive refs will remain untouched; it's only the
negative ones that change in behavior.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-29 06:23:59 +08:00
|
|
|
if (e->flags & UNINTERESTING)
|
|
|
|
continue;
|
|
|
|
|
2023-03-28 21:58:54 +08:00
|
|
|
if (repo_dwim_ref(the_repository, e->name, strlen(e->name),
|
|
|
|
&oid, &full_name, 0) != 1)
|
2007-12-02 22:14:13 +08:00
|
|
|
continue;
|
|
|
|
|
2018-05-17 06:57:59 +08:00
|
|
|
if (refspecs.nr) {
|
2014-04-21 02:59:24 +08:00
|
|
|
char *private;
|
2018-05-17 06:58:11 +08:00
|
|
|
private = apply_refspecs(&refspecs, full_name);
|
2014-04-21 02:59:24 +08:00
|
|
|
if (private) {
|
|
|
|
free(full_name);
|
|
|
|
full_name = private;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-09-01 15:05:48 +08:00
|
|
|
commit = get_commit(e, full_name);
|
|
|
|
if (!commit) {
|
2009-03-23 20:53:07 +08:00
|
|
|
warning("%s: Unexpected object of type %s, skipping.",
|
|
|
|
e->name,
|
2018-02-15 02:59:24 +08:00
|
|
|
type_name(e->item->type));
|
2009-03-23 20:53:07 +08:00
|
|
|
continue;
|
2007-12-02 22:14:13 +08:00
|
|
|
}
|
fast-export: make sure updated refs get updated
When an object has already been exported (and thus is in the marks) it's
flagged as SHOWN, so it will not be exported again, even if in a later
time it's exported through a different ref.
We don't need the object to be exported again, but we want the ref
updated, which doesn't happen.
Since we can't know if a ref was exported or not, let's just assume that
if the commit was marked (flags & SHOWN), the user still wants the ref
updated.
IOW: If it's specified in the command line, it will get updated,
regardless of whether or not the object was marked.
So:
% git branch test master
% git fast-export $mark_flags master
% git fast-export $mark_flags test
Would export 'test' properly.
Additionally, this fixes issues with remote helpers; now they can push
refs whose objects have already been exported, and a few other issues as
well. Update the tests accordingly.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-29 06:24:00 +08:00
|
|
|
|
2013-09-01 15:05:48 +08:00
|
|
|
switch(commit->object.type) {
|
|
|
|
case OBJ_COMMIT:
|
|
|
|
break;
|
|
|
|
case OBJ_BLOB:
|
2017-02-22 07:47:23 +08:00
|
|
|
export_blob(&commit->object.oid);
|
2013-09-01 15:05:48 +08:00
|
|
|
continue;
|
|
|
|
default: /* OBJ_TAG (nested tags) is already handled */
|
|
|
|
warning("Tag points to object of unexpected type %s, skipping.",
|
2018-02-15 02:59:24 +08:00
|
|
|
type_name(commit->object.type));
|
2013-09-01 15:05:48 +08:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
fast-export: make sure updated refs get updated
When an object has already been exported (and thus is in the marks) it's
flagged as SHOWN, so it will not be exported again, even if in a later
time it's exported through a different ref.
We don't need the object to be exported again, but we want the ref
updated, which doesn't happen.
Since we can't know if a ref was exported or not, let's just assume that
if the commit was marked (flags & SHOWN), the user still wants the ref
updated.
IOW: If it's specified in the command line, it will get updated,
regardless of whether or not the object was marked.
So:
% git branch test master
% git fast-export $mark_flags master
% git fast-export $mark_flags test
Would export 'test' properly.
Additionally, this fixes issues with remote helpers; now they can push
refs whose objects have already been exported, and a few other issues as
well. Update the tests accordingly.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-29 06:24:00 +08:00
|
|
|
/*
|
2018-11-16 15:59:53 +08:00
|
|
|
* Make sure this ref gets properly updated eventually, whether
|
|
|
|
* through a commit or manually at the end.
|
fast-export: make sure updated refs get updated
When an object has already been exported (and thus is in the marks) it's
flagged as SHOWN, so it will not be exported again, even if in a later
time it's exported through a different ref.
We don't need the object to be exported again, but we want the ref
updated, which doesn't happen.
Since we can't know if a ref was exported or not, let's just assume that
if the commit was marked (flags & SHOWN), the user still wants the ref
updated.
IOW: If it's specified in the command line, it will get updated,
regardless of whether or not the object was marked.
So:
% git branch test master
% git fast-export $mark_flags master
% git fast-export $mark_flags test
Would export 'test' properly.
Additionally, this fixes issues with remote helpers; now they can push
refs whose objects have already been exported, and a few other issues as
well. Update the tests accordingly.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-29 06:24:00 +08:00
|
|
|
*/
|
2018-11-16 15:59:53 +08:00
|
|
|
if (e->item->type != OBJ_TAG)
|
2013-09-01 15:05:47 +08:00
|
|
|
string_list_append(&extra_refs, full_name)->util = commit;
|
2018-11-16 15:59:53 +08:00
|
|
|
|
2018-05-19 13:28:24 +08:00
|
|
|
if (!*revision_sources_at(&revision_sources, commit))
|
|
|
|
*revision_sources_at(&revision_sources, commit) = full_name;
|
2007-12-02 22:14:13 +08:00
|
|
|
}
|
2018-11-16 15:59:53 +08:00
|
|
|
|
|
|
|
string_list_sort(&extra_refs);
|
|
|
|
string_list_remove_duplicates(&extra_refs, 0);
|
2007-12-02 22:14:13 +08:00
|
|
|
}
|
|
|
|
|
2018-11-16 15:59:53 +08:00
|
|
|
static void handle_tags_and_duplicates(struct string_list *extras)
|
2007-12-02 22:14:13 +08:00
|
|
|
{
|
|
|
|
struct commit *commit;
|
|
|
|
int i;
|
|
|
|
|
2018-11-16 15:59:53 +08:00
|
|
|
for (i = extras->nr - 1; i >= 0; i--) {
|
|
|
|
const char *name = extras->items[i].string;
|
|
|
|
struct object *object = extras->items[i].util;
|
|
|
|
int mark;
|
|
|
|
|
2007-12-02 22:14:13 +08:00
|
|
|
switch (object->type) {
|
|
|
|
case OBJ_TAG:
|
|
|
|
handle_tag(name, (struct tag *)object);
|
|
|
|
break;
|
|
|
|
case OBJ_COMMIT:
|
2014-08-28 01:01:28 +08:00
|
|
|
if (anonymize)
|
|
|
|
name = anonymize_refname(name);
|
2007-12-02 22:14:13 +08:00
|
|
|
/* create refs pointing to already seen commits */
|
2018-11-16 15:59:52 +08:00
|
|
|
commit = rewrite_commit((struct commit *)object);
|
|
|
|
if (!commit) {
|
|
|
|
/*
|
|
|
|
* Neither this object nor any of its
|
|
|
|
* ancestors touch any relevant paths, so
|
|
|
|
* it has been filtered to nothing. Delete
|
|
|
|
* it.
|
|
|
|
*/
|
|
|
|
printf("reset %s\nfrom %s\n\n",
|
2021-04-26 09:02:56 +08:00
|
|
|
name, oid_to_hex(null_oid()));
|
2018-11-16 15:59:52 +08:00
|
|
|
continue;
|
|
|
|
}
|
2018-11-16 15:59:53 +08:00
|
|
|
|
|
|
|
mark = get_object_mark(&commit->object);
|
|
|
|
if (!mark) {
|
|
|
|
/*
|
|
|
|
* Getting here means we have a commit which
|
|
|
|
* was excluded by a negative refspec (e.g.
|
2020-09-22 06:01:22 +08:00
|
|
|
* fast-export ^HEAD HEAD). If we are
|
fast-export: add --reference-excluded-parents option
git filter-branch has a nifty feature allowing you to rewrite, e.g. just
the last 8 commits of a linear history
git filter-branch $OPTIONS HEAD~8..HEAD
If you try the same with git fast-export, you instead get a history of
only 8 commits, with HEAD~7 being rewritten into a root commit. There
are two alternatives:
1) Don't use the negative revision specification, and when you're
filtering the output to make modifications to the last 8 commits,
just be careful to not modify any earlier commits somehow.
2) First run 'git fast-export --export-marks=somefile HEAD~8', then
run 'git fast-export --import-marks=somefile HEAD~8..HEAD'.
Both are more error prone than I'd like (the first for obvious reasons;
with the second option I have sometimes accidentally included too many
revisions in the first command and then found that the corresponding
extra revisions were not exported by the second command and thus were
not modified as I expected). Also, both are poor from a performance
perspective.
Add a new --reference-excluded-parents option which will cause
fast-export to refer to commits outside the specified rev-list-args
range by their sha1sum. Such a stream will only be useful in a
repository which already contains the necessary commits (much like the
restriction imposed when using --no-data).
Note from Peff:
I think we might be able to do a little more optimization here. If
we're exporting HEAD^..HEAD and there's an object in HEAD^ which is
unchanged in HEAD, I think we'd still print it (because it would not
be marked SHOWN), but we could omit it (by walking the tree of the
boundary commits and marking them shown). I don't think it's a
blocker for what you're doing here, but just a possible future
optimization.
Signed-off-by: Elijah Newren <newren@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-16 15:59:54 +08:00
|
|
|
* referencing excluded commits, set the ref
|
|
|
|
* to the exact commit. Otherwise, the user
|
2018-11-16 15:59:53 +08:00
|
|
|
* wants the branch exported but every commit
|
fast-export: add --reference-excluded-parents option
git filter-branch has a nifty feature allowing you to rewrite, e.g. just
the last 8 commits of a linear history
git filter-branch $OPTIONS HEAD~8..HEAD
If you try the same with git fast-export, you instead get a history of
only 8 commits, with HEAD~7 being rewritten into a root commit. There
are two alternatives:
1) Don't use the negative revision specification, and when you're
filtering the output to make modifications to the last 8 commits,
just be careful to not modify any earlier commits somehow.
2) First run 'git fast-export --export-marks=somefile HEAD~8', then
run 'git fast-export --import-marks=somefile HEAD~8..HEAD'.
Both are more error prone than I'd like (the first for obvious reasons;
with the second option I have sometimes accidentally included too many
revisions in the first command and then found that the corresponding
extra revisions were not exported by the second command and thus were
not modified as I expected). Also, both are poor from a performance
perspective.
Add a new --reference-excluded-parents option which will cause
fast-export to refer to commits outside the specified rev-list-args
range by their sha1sum. Such a stream will only be useful in a
repository which already contains the necessary commits (much like the
restriction imposed when using --no-data).
Note from Peff:
I think we might be able to do a little more optimization here. If
we're exporting HEAD^..HEAD and there's an object in HEAD^ which is
unchanged in HEAD, I think we'd still print it (because it would not
be marked SHOWN), but we could omit it (by walking the tree of the
boundary commits and marking them shown). I don't think it's a
blocker for what you're doing here, but just a possible future
optimization.
Signed-off-by: Elijah Newren <newren@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-16 15:59:54 +08:00
|
|
|
* in its history to be deleted, which basically
|
|
|
|
* just means deletion of the ref.
|
2018-11-16 15:59:53 +08:00
|
|
|
*/
|
fast-export: add --reference-excluded-parents option
git filter-branch has a nifty feature allowing you to rewrite, e.g. just
the last 8 commits of a linear history
git filter-branch $OPTIONS HEAD~8..HEAD
If you try the same with git fast-export, you instead get a history of
only 8 commits, with HEAD~7 being rewritten into a root commit. There
are two alternatives:
1) Don't use the negative revision specification, and when you're
filtering the output to make modifications to the last 8 commits,
just be careful to not modify any earlier commits somehow.
2) First run 'git fast-export --export-marks=somefile HEAD~8', then
run 'git fast-export --import-marks=somefile HEAD~8..HEAD'.
Both are more error prone than I'd like (the first for obvious reasons;
with the second option I have sometimes accidentally included too many
revisions in the first command and then found that the corresponding
extra revisions were not exported by the second command and thus were
not modified as I expected). Also, both are poor from a performance
perspective.
Add a new --reference-excluded-parents option which will cause
fast-export to refer to commits outside the specified rev-list-args
range by their sha1sum. Such a stream will only be useful in a
repository which already contains the necessary commits (much like the
restriction imposed when using --no-data).
Note from Peff:
I think we might be able to do a little more optimization here. If
we're exporting HEAD^..HEAD and there's an object in HEAD^ which is
unchanged in HEAD, I think we'd still print it (because it would not
be marked SHOWN), but we could omit it (by walking the tree of the
boundary commits and marking them shown). I don't think it's a
blocker for what you're doing here, but just a possible future
optimization.
Signed-off-by: Elijah Newren <newren@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-16 15:59:54 +08:00
|
|
|
if (!reference_excluded_commits) {
|
|
|
|
/* delete the ref */
|
|
|
|
printf("reset %s\nfrom %s\n\n",
|
2021-04-26 09:02:56 +08:00
|
|
|
name, oid_to_hex(null_oid()));
|
fast-export: add --reference-excluded-parents option
git filter-branch has a nifty feature allowing you to rewrite, e.g. just
the last 8 commits of a linear history
git filter-branch $OPTIONS HEAD~8..HEAD
If you try the same with git fast-export, you instead get a history of
only 8 commits, with HEAD~7 being rewritten into a root commit. There
are two alternatives:
1) Don't use the negative revision specification, and when you're
filtering the output to make modifications to the last 8 commits,
just be careful to not modify any earlier commits somehow.
2) First run 'git fast-export --export-marks=somefile HEAD~8', then
run 'git fast-export --import-marks=somefile HEAD~8..HEAD'.
Both are more error prone than I'd like (the first for obvious reasons;
with the second option I have sometimes accidentally included too many
revisions in the first command and then found that the corresponding
extra revisions were not exported by the second command and thus were
not modified as I expected). Also, both are poor from a performance
perspective.
Add a new --reference-excluded-parents option which will cause
fast-export to refer to commits outside the specified rev-list-args
range by their sha1sum. Such a stream will only be useful in a
repository which already contains the necessary commits (much like the
restriction imposed when using --no-data).
Note from Peff:
I think we might be able to do a little more optimization here. If
we're exporting HEAD^..HEAD and there's an object in HEAD^ which is
unchanged in HEAD, I think we'd still print it (because it would not
be marked SHOWN), but we could omit it (by walking the tree of the
boundary commits and marking them shown). I don't think it's a
blocker for what you're doing here, but just a possible future
optimization.
Signed-off-by: Elijah Newren <newren@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-16 15:59:54 +08:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
/* set ref to commit using oid, not mark */
|
|
|
|
printf("reset %s\nfrom %s\n\n", name,
|
|
|
|
oid_to_hex(&commit->object.oid));
|
2018-11-16 15:59:53 +08:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
printf("reset %s\nfrom :%d\n\n", name, mark
|
|
|
|
);
|
2007-12-02 22:14:13 +08:00
|
|
|
show_progress();
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-06-11 19:17:04 +08:00
|
|
|
static void export_marks(char *file)
|
|
|
|
{
|
|
|
|
unsigned int i;
|
|
|
|
uint32_t mark;
|
2017-12-08 08:14:24 +08:00
|
|
|
struct decoration_entry *deco = idnums.entries;
|
2008-06-11 19:17:04 +08:00
|
|
|
FILE *f;
|
2009-07-24 16:17:13 +08:00
|
|
|
int e = 0;
|
2008-06-11 19:17:04 +08:00
|
|
|
|
Handle more file writes correctly in shared repos
In shared repositories, we have to be careful when writing files whose
permissions do not allow users other than the owner to write them.
In particular, we force the marks file of fast-export and the FETCH_HEAD
when fetching to be rewritten from scratch.
This commit does not touch other calls to fopen() that want to
write files:
- commands that write to working tree files (core.sharedRepository
does not affect permission bits of working tree files),
e.g. .rej file created by "apply --reject", result of applying a
previous conflict resolution by "rerere", "git merge-file".
- git am, when splitting mails (git-am correctly cleans up its directory
after finishing, so there is no need to share those files between users)
- git submodule clone, when writing the .git file, because the file
will not be overwritten
- git_terminal_prompt() in compat/terminal.c, because it is not writing to
a file at all
- git diff --output, because the output file is clearly not intended to be
shared between the users of the current repository
- git fast-import, when writing a crash report, because the reports' file
names are unique due to an embedded process ID
- mailinfo() in mailinfo.c, because the output is clearly not intended to
be shared between the users of the current repository
- check_or_regenerate_marks() in remote-testsvn.c, because this is only
used for Git's internal testing
- git fsck, when writing lost&found blobs (this should probably be
changed, but left as a low-hanging fruit for future contributors).
Note that this patch does not touch callers of write_file() and
write_file_gently(), which would benefit from the same scrutiny as
to usage in shared repositories. Most notable users are branch,
daemon, submodule & worktree, and a worrisome call in transport.c
when updating one ref (which ignores the shared flag).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-12 02:35:54 +08:00
|
|
|
f = fopen_for_writing(file);
|
2008-06-11 19:17:04 +08:00
|
|
|
if (!f)
|
2010-03-28 13:42:48 +08:00
|
|
|
die_errno("Unable to open marks file %s for writing.", file);
|
2008-06-11 19:17:04 +08:00
|
|
|
|
2008-07-03 15:25:23 +08:00
|
|
|
for (i = 0; i < idnums.size; i++) {
|
|
|
|
if (deco->base && deco->base->type == 1) {
|
2008-06-11 19:17:04 +08:00
|
|
|
mark = ptr_to_mark(deco->decoration);
|
2009-07-24 16:17:13 +08:00
|
|
|
if (fprintf(f, ":%"PRIu32" %s\n", mark,
|
2015-11-10 10:22:28 +08:00
|
|
|
oid_to_hex(&deco->base->oid)) < 0) {
|
2009-07-24 16:17:13 +08:00
|
|
|
e = 1;
|
|
|
|
break;
|
|
|
|
}
|
2008-06-11 19:17:04 +08:00
|
|
|
}
|
2008-07-03 15:25:23 +08:00
|
|
|
deco++;
|
2008-06-11 19:17:04 +08:00
|
|
|
}
|
|
|
|
|
2009-07-24 16:17:13 +08:00
|
|
|
e |= ferror(f);
|
|
|
|
e |= fclose(f);
|
|
|
|
if (e)
|
2008-06-11 19:17:04 +08:00
|
|
|
error("Unable to write marks file %s.", file);
|
|
|
|
}
|
|
|
|
|
2019-10-04 04:27:06 +08:00
|
|
|
static void import_marks(char *input_file, int check_exists)
|
2008-06-11 19:17:04 +08:00
|
|
|
{
|
|
|
|
char line[512];
|
2019-10-04 04:27:06 +08:00
|
|
|
FILE *f;
|
|
|
|
struct stat sb;
|
|
|
|
|
|
|
|
if (check_exists && stat(input_file, &sb))
|
|
|
|
return;
|
2008-06-11 19:17:04 +08:00
|
|
|
|
2019-10-04 04:27:06 +08:00
|
|
|
f = xfopen(input_file, "r");
|
2008-06-11 19:17:04 +08:00
|
|
|
while (fgets(line, sizeof(line), f)) {
|
|
|
|
uint32_t mark;
|
|
|
|
char *line_end, *mark_end;
|
2017-02-22 07:47:23 +08:00
|
|
|
struct object_id oid;
|
2008-06-11 19:17:04 +08:00
|
|
|
struct object *object;
|
2013-05-06 06:38:54 +08:00
|
|
|
struct commit *commit;
|
2013-05-06 06:38:53 +08:00
|
|
|
enum object_type type;
|
2008-06-11 19:17:04 +08:00
|
|
|
|
|
|
|
line_end = strchr(line, '\n');
|
|
|
|
if (line[0] != ':' || !line_end)
|
|
|
|
die("corrupt mark line: %s", line);
|
2008-07-03 15:25:23 +08:00
|
|
|
*line_end = '\0';
|
2008-06-11 19:17:04 +08:00
|
|
|
|
|
|
|
mark = strtoumax(line + 1, &mark_end, 10);
|
|
|
|
if (!mark || mark_end == line + 1
|
2017-02-22 07:47:23 +08:00
|
|
|
|| *mark_end != ' ' || get_oid_hex(mark_end + 1, &oid))
|
2008-06-11 19:17:04 +08:00
|
|
|
die("corrupt mark line: %s", line);
|
|
|
|
|
2013-04-07 01:04:31 +08:00
|
|
|
if (last_idnum < mark)
|
|
|
|
last_idnum = mark;
|
|
|
|
|
2018-04-26 02:20:59 +08:00
|
|
|
type = oid_object_info(the_repository, &oid, NULL);
|
2013-05-06 06:38:53 +08:00
|
|
|
if (type < 0)
|
2017-02-22 07:47:23 +08:00
|
|
|
die("object not found: %s", oid_to_hex(&oid));
|
2013-05-06 06:38:53 +08:00
|
|
|
|
|
|
|
if (type != OBJ_COMMIT)
|
|
|
|
/* only commits */
|
2013-04-07 01:04:31 +08:00
|
|
|
continue;
|
2008-06-11 19:17:04 +08:00
|
|
|
|
2018-06-29 09:21:59 +08:00
|
|
|
commit = lookup_commit(the_repository, &oid);
|
2013-05-06 06:38:54 +08:00
|
|
|
if (!commit)
|
2017-02-22 07:47:23 +08:00
|
|
|
die("not a commit? can't happen: %s", oid_to_hex(&oid));
|
2013-05-06 06:38:54 +08:00
|
|
|
|
|
|
|
object = &commit->object;
|
2013-05-06 06:38:53 +08:00
|
|
|
|
2008-06-11 19:17:04 +08:00
|
|
|
if (object->flags & SHOWN)
|
2017-02-22 07:47:23 +08:00
|
|
|
error("Object %s already has a mark", oid_to_hex(&oid));
|
2008-06-11 19:17:04 +08:00
|
|
|
|
|
|
|
mark_object(object, mark);
|
|
|
|
|
|
|
|
object->flags |= SHOWN;
|
|
|
|
}
|
|
|
|
fclose(f);
|
|
|
|
}
|
|
|
|
|
2014-04-21 02:59:28 +08:00
|
|
|
static void handle_deletes(void)
|
|
|
|
{
|
|
|
|
int i;
|
2018-05-17 06:57:59 +08:00
|
|
|
for (i = 0; i < refspecs.nr; i++) {
|
|
|
|
struct refspec_item *refspec = &refspecs.items[i];
|
2014-04-21 02:59:28 +08:00
|
|
|
if (*refspec->src)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
printf("reset %s\nfrom %s\n\n",
|
2021-04-26 09:02:56 +08:00
|
|
|
refspec->dst, oid_to_hex(null_oid()));
|
2014-04-21 02:59:28 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-06-26 03:48:32 +08:00
|
|
|
static int parse_opt_anonymize_map(const struct option *opt,
|
|
|
|
const char *arg, int unset)
|
|
|
|
{
|
|
|
|
struct hashmap *map = opt->value;
|
|
|
|
const char *delim, *value;
|
|
|
|
size_t keylen;
|
|
|
|
|
|
|
|
BUG_ON_OPT_NEG(unset);
|
|
|
|
|
|
|
|
delim = strchr(arg, ':');
|
|
|
|
if (delim) {
|
|
|
|
keylen = delim - arg;
|
|
|
|
value = delim + 1;
|
|
|
|
} else {
|
|
|
|
keylen = strlen(arg);
|
|
|
|
value = arg;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!keylen || !*value)
|
|
|
|
return error(_("--anonymize-map token cannot be empty"));
|
|
|
|
|
fast-export: de-obfuscate --anonymize-map handling
When we handle an --anonymize-map option, we parse the orig/anon pair,
and then feed the "orig" string to anonymize_str(), along with a
generator function that duplicates the "anon" string to be cached in the
map.
This works, because anonymize_str() says "ah, there is no mapping yet
for orig; I'll add one from the generator". But there are some
downsides:
1. It's a bit too clever, as it's not obvious what the code is trying
to do or why it works.
2. It requires allowing generator functions to take an extra void
pointer, which is not something any of the normal callers of
anonymize_str() want.
3. It does the wrong thing if the same token is provided twice.
When there are conflicting options, like:
git fast-export --anonymize \
--anonymize-map=foo:one \
--anonymize-map=foo:two
we usually let the second one override the first. But by using
anonymize_str(), which has first-one-wins logic, we do the
opposite.
So instead of relying on anonymize_str(), let's directly add the entry
ourselves. We can tweak the tests to show that we handle overridden
options correctly now.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-23 01:42:13 +08:00
|
|
|
add_anonymized_entry(map, memhash(arg, keylen), arg, keylen,
|
|
|
|
xstrdup(value));
|
2020-06-26 03:48:32 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2007-12-02 22:14:13 +08:00
|
|
|
int cmd_fast_export(int argc, const char **argv, const char *prefix)
|
|
|
|
{
|
|
|
|
struct rev_info revs;
|
|
|
|
struct commit *commit;
|
2019-10-04 04:27:06 +08:00
|
|
|
char *export_filename = NULL,
|
|
|
|
*import_filename = NULL,
|
|
|
|
*import_filename_if_exists = NULL;
|
2013-04-07 01:04:31 +08:00
|
|
|
uint32_t lastimportid;
|
2014-04-21 02:59:24 +08:00
|
|
|
struct string_list refspecs_list = STRING_LIST_INIT_NODUP;
|
2017-09-21 07:55:02 +08:00
|
|
|
struct string_list paths_of_changed_objects = STRING_LIST_INIT_DUP;
|
2007-12-02 22:14:13 +08:00
|
|
|
struct option options[] = {
|
|
|
|
OPT_INTEGER(0, "progress", &progress,
|
2012-08-20 20:32:08 +08:00
|
|
|
N_("show progress after <n> objects")),
|
|
|
|
OPT_CALLBACK(0, "signed-tags", &signed_tag_mode, N_("mode"),
|
|
|
|
N_("select handling of signed tags"),
|
2007-12-02 22:14:13 +08:00
|
|
|
parse_opt_signed_tag_mode),
|
2012-08-20 20:32:08 +08:00
|
|
|
OPT_CALLBACK(0, "tag-of-filtered-object", &tag_of_filtered_mode, N_("mode"),
|
|
|
|
N_("select handling of tags that tag filtered objects"),
|
2009-06-26 12:48:31 +08:00
|
|
|
parse_opt_tag_of_filtered_mode),
|
2019-05-14 12:31:02 +08:00
|
|
|
OPT_CALLBACK(0, "reencode", &reencode_mode, N_("mode"),
|
|
|
|
N_("select handling of commit messages in an alternate encoding"),
|
|
|
|
parse_opt_reencode_mode),
|
2012-08-20 20:32:08 +08:00
|
|
|
OPT_STRING(0, "export-marks", &export_filename, N_("file"),
|
2021-01-06 22:44:03 +08:00
|
|
|
N_("dump marks to this file")),
|
2012-08-20 20:32:08 +08:00
|
|
|
OPT_STRING(0, "import-marks", &import_filename, N_("file"),
|
2021-01-06 22:44:03 +08:00
|
|
|
N_("import marks from this file")),
|
2019-10-04 04:27:06 +08:00
|
|
|
OPT_STRING(0, "import-marks-if-exists",
|
|
|
|
&import_filename_if_exists,
|
|
|
|
N_("file"),
|
2021-01-06 22:44:03 +08:00
|
|
|
N_("import marks from this file if it exists")),
|
2013-08-03 19:51:19 +08:00
|
|
|
OPT_BOOL(0, "fake-missing-tagger", &fake_missing_tagger,
|
2021-01-06 22:44:03 +08:00
|
|
|
N_("fake a tagger when tags lack one")),
|
2013-08-03 19:51:19 +08:00
|
|
|
OPT_BOOL(0, "full-tree", &full_tree,
|
2021-01-06 22:44:03 +08:00
|
|
|
N_("output full tree for each commit")),
|
2013-08-03 19:51:19 +08:00
|
|
|
OPT_BOOL(0, "use-done-feature", &use_done_feature,
|
2021-01-06 22:44:03 +08:00
|
|
|
N_("use the done feature to terminate the stream")),
|
|
|
|
OPT_BOOL(0, "no-data", &no_data, N_("skip output of blob data")),
|
2014-04-21 02:59:24 +08:00
|
|
|
OPT_STRING_LIST(0, "refspec", &refspecs_list, N_("refspec"),
|
2021-01-06 22:44:03 +08:00
|
|
|
N_("apply refspec to exported refs")),
|
2014-08-28 01:01:28 +08:00
|
|
|
OPT_BOOL(0, "anonymize", &anonymize, N_("anonymize output")),
|
2020-06-26 03:48:32 +08:00
|
|
|
OPT_CALLBACK_F(0, "anonymize-map", &anonymized_seeds, N_("from:to"),
|
|
|
|
N_("convert <from> to <to> in anonymized output"),
|
|
|
|
PARSE_OPT_NONEG, parse_opt_anonymize_map),
|
fast-export: add --reference-excluded-parents option
git filter-branch has a nifty feature allowing you to rewrite, e.g. just
the last 8 commits of a linear history
git filter-branch $OPTIONS HEAD~8..HEAD
If you try the same with git fast-export, you instead get a history of
only 8 commits, with HEAD~7 being rewritten into a root commit. There
are two alternatives:
1) Don't use the negative revision specification, and when you're
filtering the output to make modifications to the last 8 commits,
just be careful to not modify any earlier commits somehow.
2) First run 'git fast-export --export-marks=somefile HEAD~8', then
run 'git fast-export --import-marks=somefile HEAD~8..HEAD'.
Both are more error prone than I'd like (the first for obvious reasons;
with the second option I have sometimes accidentally included too many
revisions in the first command and then found that the corresponding
extra revisions were not exported by the second command and thus were
not modified as I expected). Also, both are poor from a performance
perspective.
Add a new --reference-excluded-parents option which will cause
fast-export to refer to commits outside the specified rev-list-args
range by their sha1sum. Such a stream will only be useful in a
repository which already contains the necessary commits (much like the
restriction imposed when using --no-data).
Note from Peff:
I think we might be able to do a little more optimization here. If
we're exporting HEAD^..HEAD and there's an object in HEAD^ which is
unchanged in HEAD, I think we'd still print it (because it would not
be marked SHOWN), but we could omit it (by walking the tree of the
boundary commits and marking them shown). I don't think it's a
blocker for what you're doing here, but just a possible future
optimization.
Signed-off-by: Elijah Newren <newren@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-16 15:59:54 +08:00
|
|
|
OPT_BOOL(0, "reference-excluded-parents",
|
2021-01-06 22:44:03 +08:00
|
|
|
&reference_excluded_commits, N_("reference parents which are not in fast-export stream by object id")),
|
2018-11-16 15:59:56 +08:00
|
|
|
OPT_BOOL(0, "show-original-ids", &show_original_ids,
|
2021-01-06 22:44:03 +08:00
|
|
|
N_("show original object ids of blobs/commits")),
|
2019-10-04 04:27:07 +08:00
|
|
|
OPT_BOOL(0, "mark-tags", &mark_tags,
|
2021-01-06 22:44:03 +08:00
|
|
|
N_("label tags with mark ids")),
|
fast-export: add --reference-excluded-parents option
git filter-branch has a nifty feature allowing you to rewrite, e.g. just
the last 8 commits of a linear history
git filter-branch $OPTIONS HEAD~8..HEAD
If you try the same with git fast-export, you instead get a history of
only 8 commits, with HEAD~7 being rewritten into a root commit. There
are two alternatives:
1) Don't use the negative revision specification, and when you're
filtering the output to make modifications to the last 8 commits,
just be careful to not modify any earlier commits somehow.
2) First run 'git fast-export --export-marks=somefile HEAD~8', then
run 'git fast-export --import-marks=somefile HEAD~8..HEAD'.
Both are more error prone than I'd like (the first for obvious reasons;
with the second option I have sometimes accidentally included too many
revisions in the first command and then found that the corresponding
extra revisions were not exported by the second command and thus were
not modified as I expected). Also, both are poor from a performance
perspective.
Add a new --reference-excluded-parents option which will cause
fast-export to refer to commits outside the specified rev-list-args
range by their sha1sum. Such a stream will only be useful in a
repository which already contains the necessary commits (much like the
restriction imposed when using --no-data).
Note from Peff:
I think we might be able to do a little more optimization here. If
we're exporting HEAD^..HEAD and there's an object in HEAD^ which is
unchanged in HEAD, I think we'd still print it (because it would not
be marked SHOWN), but we could omit it (by walking the tree of the
boundary commits and marking them shown). I don't think it's a
blocker for what you're doing here, but just a possible future
optimization.
Signed-off-by: Elijah Newren <newren@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-16 15:59:54 +08:00
|
|
|
|
2007-12-02 22:14:13 +08:00
|
|
|
OPT_END()
|
|
|
|
};
|
|
|
|
|
2009-01-03 11:59:12 +08:00
|
|
|
if (argc == 1)
|
|
|
|
usage_with_options (fast_export_usage, options);
|
|
|
|
|
2007-12-02 22:14:13 +08:00
|
|
|
/* we handle encodings */
|
2008-05-15 01:46:53 +08:00
|
|
|
git_config(git_default_config, NULL);
|
2007-12-02 22:14:13 +08:00
|
|
|
|
2018-09-21 23:57:38 +08:00
|
|
|
repo_init_revisions(the_repository, &revs, prefix);
|
2018-05-19 13:28:24 +08:00
|
|
|
init_revision_sources(&revision_sources);
|
2009-06-26 12:48:27 +08:00
|
|
|
revs.topo_order = 1;
|
2018-05-19 13:28:24 +08:00
|
|
|
revs.sources = &revision_sources;
|
2009-06-26 12:48:30 +08:00
|
|
|
revs.rewrite_parents = 1;
|
2014-04-21 02:59:23 +08:00
|
|
|
argc = parse_options(argc, argv, prefix, options, fast_export_usage,
|
2022-08-20 00:03:57 +08:00
|
|
|
PARSE_OPT_KEEP_ARGV0 | PARSE_OPT_KEEP_UNKNOWN_OPT);
|
2007-12-02 22:14:13 +08:00
|
|
|
argc = setup_revisions(argc, argv, &revs, NULL);
|
|
|
|
if (argc > 1)
|
|
|
|
usage_with_options (fast_export_usage, options);
|
|
|
|
|
2020-06-26 03:48:32 +08:00
|
|
|
if (anonymized_seeds.cmpfn && !anonymize)
|
2022-01-06 04:02:19 +08:00
|
|
|
die(_("the option '%s' requires '%s'"), "--anonymize-map", "--anonymize");
|
2020-06-26 03:48:32 +08:00
|
|
|
|
2014-04-21 02:59:24 +08:00
|
|
|
if (refspecs_list.nr) {
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < refspecs_list.nr; i++)
|
2018-05-17 06:57:59 +08:00
|
|
|
refspec_append(&refspecs, refspecs_list.items[i].string);
|
2014-04-21 02:59:24 +08:00
|
|
|
|
|
|
|
string_list_clear(&refspecs_list, 1);
|
|
|
|
}
|
|
|
|
|
2011-07-16 21:03:33 +08:00
|
|
|
if (use_done_feature)
|
|
|
|
printf("feature done\n");
|
|
|
|
|
2019-10-04 04:27:06 +08:00
|
|
|
if (import_filename && import_filename_if_exists)
|
2022-01-06 04:02:16 +08:00
|
|
|
die(_("options '%s' and '%s' cannot be used together"), "--import-marks", "--import-marks-if-exists");
|
2008-06-11 19:17:04 +08:00
|
|
|
if (import_filename)
|
2019-10-04 04:27:06 +08:00
|
|
|
import_marks(import_filename, 0);
|
|
|
|
else if (import_filename_if_exists)
|
|
|
|
import_marks(import_filename_if_exists, 1);
|
2013-04-07 01:04:31 +08:00
|
|
|
lastimportid = last_idnum;
|
2008-06-11 19:17:04 +08:00
|
|
|
|
2010-12-17 20:43:06 +08:00
|
|
|
if (import_filename && revs.prune_data.nr)
|
2010-07-18 01:00:50 +08:00
|
|
|
full_tree = 1;
|
|
|
|
|
2013-09-01 15:05:47 +08:00
|
|
|
get_tags_and_duplicates(&revs.cmdline);
|
2007-12-02 22:14:13 +08:00
|
|
|
|
2008-02-18 15:31:56 +08:00
|
|
|
if (prepare_revision_walk(&revs))
|
|
|
|
die("revision walk setup failed");
|
fast-export: fix surprising behavior with --first-parent
The revision traversal machinery typically processes and returns all
children before any parent. fast-export needs to operate in the
reverse fashion, handling parents before any of their children in
order to build up the history starting from the root commit(s). This
would be a clear case where we could just use the revision traversal
machinery's "reverse" option to achieve this desired affect.
However, this wasn't what the code did. It added its own array for
queuing. The obvious hand-rolled solution would be to just push all
the commits into the array and then traverse afterwards, but it didn't
quite do that either. It instead attempted to process anything it
could as soon as it could, and once it could, check whether it could
process anything that had been queued. As far as I can tell, this was
an effort to save a little memory in the case of multiple root commits
since it could process some commits before queueing all of them. This
involved some helper functions named has_unshown_parent() and
handle_tail(). For typical invocations of fast-export, this
alternative essentially amounted to a hand-rolled method of reversing
the commits -- it was a bunch of work to duplicate the revision
traversal machinery's "reverse" option.
This hand-rolled reversing mechanism is actually somewhat difficult to
reason about. It takes some time to figure out how it ensures in
normal cases that it will actually process all traversed commits
(rather than just dropping some and not printing anything for them).
And it turns out there are some cases where the code does drop commits
without handling them, and not even printing an error or warning for
the user. Due to the has_unshown_parent() checks, some commits could
be left in the array at the end of the "while...get_revision()" loop
which would be unprocessed. This could be triggered for example with
git fast-export main -- --first-parent
or non-sensical traversal rules such as
git fast-export main -- --grep=Merge --invert-grep
While most traversals that don't include all parents should likely
trigger errors in fast-export (or at least require being used in
combination with --reference-excluded-parents), the --first-parent
traversal is at least reasonable and it'd be nice if it didn't just drop
commits. It'd also be nice for future readers of the code to have a
simpler "reverse traversal" mechanism. Use the "reverse" option of the
revision traversal machinery to achieve both.
Even for the non-sensical traversal flags like the --grep one above,
this would be an improvement. For example, in that case, the code
previously would have silently truncated history to only those commits
that do not have an ancestor containing "Merge" in their commit message.
After this code change, that case would include all commits without
"Merge" in their commit message -- but any commit that previously had a
"Merge"-mentioning parent would lose that parent
(likely resulting in many new root commits). While the new behavior is
still odd, it is at least understandable given that
--reference-excluded-parents is not the default.
Helped-by: Elijah Newren <newren@gmail.com>
Signed-off-by: William Sprent <williams@unity3d.com>
Reviewed-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-17 00:23:09 +08:00
|
|
|
|
|
|
|
revs.reverse = 1;
|
2007-12-02 22:14:13 +08:00
|
|
|
revs.diffopt.format_callback = show_filemodify;
|
2017-09-21 07:55:02 +08:00
|
|
|
revs.diffopt.format_callback_data = &paths_of_changed_objects;
|
2017-11-01 02:19:11 +08:00
|
|
|
revs.diffopt.flags.recursive = 1;
|
2022-04-30 22:31:43 +08:00
|
|
|
revs.diffopt.no_free = 1;
|
fast-export: fix surprising behavior with --first-parent
The revision traversal machinery typically processes and returns all
children before any parent. fast-export needs to operate in the
reverse fashion, handling parents before any of their children in
order to build up the history starting from the root commit(s). This
would be a clear case where we could just use the revision traversal
machinery's "reverse" option to achieve this desired affect.
However, this wasn't what the code did. It added its own array for
queuing. The obvious hand-rolled solution would be to just push all
the commits into the array and then traverse afterwards, but it didn't
quite do that either. It instead attempted to process anything it
could as soon as it could, and once it could, check whether it could
process anything that had been queued. As far as I can tell, this was
an effort to save a little memory in the case of multiple root commits
since it could process some commits before queueing all of them. This
involved some helper functions named has_unshown_parent() and
handle_tail(). For typical invocations of fast-export, this
alternative essentially amounted to a hand-rolled method of reversing
the commits -- it was a bunch of work to duplicate the revision
traversal machinery's "reverse" option.
This hand-rolled reversing mechanism is actually somewhat difficult to
reason about. It takes some time to figure out how it ensures in
normal cases that it will actually process all traversed commits
(rather than just dropping some and not printing anything for them).
And it turns out there are some cases where the code does drop commits
without handling them, and not even printing an error or warning for
the user. Due to the has_unshown_parent() checks, some commits could
be left in the array at the end of the "while...get_revision()" loop
which would be unprocessed. This could be triggered for example with
git fast-export main -- --first-parent
or non-sensical traversal rules such as
git fast-export main -- --grep=Merge --invert-grep
While most traversals that don't include all parents should likely
trigger errors in fast-export (or at least require being used in
combination with --reference-excluded-parents), the --first-parent
traversal is at least reasonable and it'd be nice if it didn't just drop
commits. It'd also be nice for future readers of the code to have a
simpler "reverse traversal" mechanism. Use the "reverse" option of the
revision traversal machinery to achieve both.
Even for the non-sensical traversal flags like the --grep one above,
this would be an improvement. For example, in that case, the code
previously would have silently truncated history to only those commits
that do not have an ancestor containing "Merge" in their commit message.
After this code change, that case would include all commits without
"Merge" in their commit message -- but any commit that previously had a
"Merge"-mentioning parent would lose that parent
(likely resulting in many new root commits). While the new behavior is
still odd, it is at least understandable given that
--reference-excluded-parents is not the default.
Helped-by: Elijah Newren <newren@gmail.com>
Signed-off-by: William Sprent <williams@unity3d.com>
Reviewed-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-17 00:23:09 +08:00
|
|
|
while ((commit = get_revision(&revs)))
|
|
|
|
handle_commit(commit, &revs, &paths_of_changed_objects);
|
2007-12-02 22:14:13 +08:00
|
|
|
|
2018-11-16 15:59:53 +08:00
|
|
|
handle_tags_and_duplicates(&extra_refs);
|
|
|
|
handle_tags_and_duplicates(&tag_refs);
|
2014-04-21 02:59:28 +08:00
|
|
|
handle_deletes();
|
2007-12-02 22:14:13 +08:00
|
|
|
|
2013-04-07 01:04:31 +08:00
|
|
|
if (export_filename && lastimportid != last_idnum)
|
2008-06-11 19:17:04 +08:00
|
|
|
export_marks(export_filename);
|
|
|
|
|
2011-07-16 21:03:33 +08:00
|
|
|
if (use_done_feature)
|
|
|
|
printf("done\n");
|
|
|
|
|
2018-05-17 06:57:59 +08:00
|
|
|
refspec_clear(&refspecs);
|
2022-04-14 04:01:36 +08:00
|
|
|
release_revisions(&revs);
|
2014-04-21 02:59:24 +08:00
|
|
|
|
2007-12-02 22:14:13 +08:00
|
|
|
return 0;
|
|
|
|
}
|