* Re: [PATCH 3/3] fast-import: rename object_count to pack_object_count
From: Jonathan Nieder @ 2011-09-18 21:40 UTC (permalink / raw)
To: Dmitry Ivankov; +Cc: git, Shawn O. Pearce, David Barr
In-Reply-To: <CA+gfSn8aOWPm=xmTE9WzuXsQY0EfYypFxRAyVb-x3_kmhNUb-Q@mail.gmail.com>
Dmitry Ivankov wrote:
> --- a/fast-import.c
> +++ b/fast-import.c
[...]
> @@ -310,8 +309,16 @@ static unsigned int atom_cnt;
> static struct atom_str **atom_table;
>
> /* The .pack file being generated */
> +/*
> + * objects that are being written to the current pack
> + * all *must* have current pack_id in struct object_entry.
> + * And object_count *must* be a count of object_entry's
> + * having current pack_id. This data is used to create
> + * index file once current pack_file is finished.
> + */
> static struct pack_idx_option pack_idx_opts;
> static unsigned int pack_id;
> +static unsigned long object_count;
> static struct sha1file *pack_file;
Closer. Now I am tempted to nitpick and say that this should be
a single comment, formatted in complete sentences, and written to
be descriptive rather than normative when possible (since norms
will inevitably change over time, and future readers should not
have an excuse to be afraid to adjust the comment to match code
changes).
/*
* The .pack file being generated
*
* Objects that are being written to the current pack store the
* current value of "pack_id" in struct object_entry.
* "object_count" counts the object_entrys with the current
* pack_id. These values are used to create the pack index
* file when the current pack is finished.
*/
static struct pack_idx_option pack_idx_opts;
static unsigned int pack_id;
...
^ permalink raw reply
* Re: [PATCH/RFC 0/2] fast-import: commit from null_sha1
From: Dmitry Ivankov @ 2011-09-18 21:40 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Shawn O. Pearce, David Barr, Sverre Rabbelier
In-Reply-To: <20110918213050.GJ2308@elie>
On Mon, Sep 19, 2011 at 3:30 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Dmitry Ivankov wrote:
>
>> These patches make fast-import treat
>> commit refs/heads/master
>> ...
>> from `null_sha1`
>> like any other missing parent sha1 - reject such input.
>
> Are you sure the existing support for "from 0{40}" is not deliberate
> and that no one is relying on it?
It is hard to guess. There is no test for it in t/t9300-fast-import.sh, no
mention in the Documentation, but sometimes a user can see null_sha1
from git. I hope that it pops up only when something is read to simplify
the format and never accepted in 'write' commands or as an argument.
> If and only if you are, then this
> seems like a good idea (a single patch that both makes the behavior
> change and adds a test for it should be easier to review).
>
^ permalink raw reply
* Re: [PATCH 1/5] git-p4 tests: refactor, split out common functions
From: Junio C Hamano @ 2011-09-18 21:48 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: git, Vitor Antunes, Luke Diamand, Chris Li
In-Reply-To: <20110918012713.GA4619@arf.padd.com>
Pete Wyckoff <pw@padd.com> writes:
> Introduce a library for functions that are common to
> multiple git-p4 test files.
>
> Separate the tests related to detecting p4 branches
> into their own file, and add a few more.
>
> Signed-off-by: Pete Wyckoff <pw@padd.com>
> ---
> t/lib-git-p4.sh | 55 ++++++++++++
> t/t9800-git-p4.sh | 108 ++---------------------
> t/t9801-git-p4-branch.sh | 221 ++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 283 insertions(+), 101 deletions(-)
> create mode 100644 t/lib-git-p4.sh
> create mode 100755 t/t9801-git-p4-branch.sh
I take that you meant "coding style" by "generic test beauty" in the cover
letter, so here are some minor nitpicks.
> diff --git a/t/lib-git-p4.sh b/t/lib-git-p4.sh
> new file mode 100644
> index 0000000..dbc1499
> --- /dev/null
> +++ b/t/lib-git-p4.sh
> @@ -0,0 +1,55 @@
> +#
> +# Library code for git-p4 tests
> +#
> +
> +. ./test-lib.sh
> +
> +( p4 -h && p4d -h ) >/dev/null 2>&1 || {
> + skip_all='skipping git-p4 tests; no p4 or p4d'
> + test_done
> +}
> +
> +GITP4=$GIT_BUILD_DIR/contrib/fast-import/git-p4
> +P4DPORT=10669
What happens when tests are run in parallel (make -j or prove --jobs) and
9800 and 9801 are run at the same time?
> +export P4PORT=localhost:$P4DPORT
> +export P4CLIENT=client
> +
> +db="$TRASH_DIRECTORY/db"
> +cli="$TRASH_DIRECTORY/cli"
> +git="$TRASH_DIRECTORY/git"
> +
> +start_p4d()
> +{
Prevalent style in t/ and scripted part of Git in general is to begin a
shell function like this, with SP on both sides of () and opening brace
on the same line.
start_p4d () {
> + mkdir -p "$db" &&
> + p4d -q -d -r "$db" -p $P4DPORT &&
> + mkdir -p "$cli" &&
> + mkdir -p "$git" &&
> + cd "$cli" &&
> + p4 client -i <<-EOF
> + Client: client
> + Description: client
> + Root: $cli
> + View: //depot/... //client/...
> + EOF
> +}
> +
> +kill_p4d()
> +{
> + pid=`pgrep -f p4d` &&
> + test -n "$pid" &&
It is unfortunate that you have to use pgrep. I am unfamiliar with p4, but
do you have any control how p4d is started during this test? If the first
use of client automagically starts p4d without your control, that would be
harder to arrange, but the point I am getting at is that if you know when
you start p4d yourself and that is the only p4d process you use, you
should be keep its pid in $TRASH_DIRECTORY somewhere and replace these
with
pid=$(cat "$TRASH_DIRECTORY/p4d_pid") &&
kill -0 "$pid"
to see if that daemon is still alive.
You call kill_p4d at the very beginning of t9800; what instance of p4d are
you trying to kill? Who could have started it? For you to be able to kill
(and nobody sane would be running the test suite as "root", I hope), it
would be your process, but would it be possible that you are doing some
other important thing using p4 that is not related to git-p4 development
or testing at all, perhaps listening to a port different from 10669? Would
it be necessary to kill that other p4d to run these tests in a predicatable
and reproducible environment?
I would very much more prefer if at the very beginning you started p4d at
the port assigned for the test and fail the test if it cannot start for
whatever reason. Perhaps the reason you cannot start a p4d is because a
stale p4d instance is hanging around from previous round of test, and if
that is the case, then that is the bug we need to fix in the _previous_
test, not something we want to sweep under the rug by killing it during
this round of test.
> + for i in {1..5} ; do
That {1..5} does not pass POSIX shells, such as /bin/dash.
for i in 1 2 3 4 5
do
...
> + test_debug "ps wl `echo $pid`" &&
> + kill $pid 2>/dev/null &&
> + pgrep -f p4d >/dev/null || break &&
You are saying "all of these things would hold true if we attempt to kill
it and it still is alive" with the chain of "&&" up to that last pgrep,
and then with "||", you say "otherwise we do not have to keep sending the
signal to it anymore". But the extra "&&" after "break" is unneeded and
misleading.
> + sleep 0.2
That 0.2 does not look like a non-negative decimal interger like POSIX
wants to have.
> + done &&
> + rm -rf "$db" &&
> + rm -rf "$cli"
> +}
> +
> +cleanup_git() {
> + cd "$TRASH_DIRECTORY" &&
> + rm -rf "$git" &&
> + mkdir "$git"
> +}
> diff --git a/t/t9800-git-p4.sh b/t/t9800-git-p4.sh
> index 01ba041..bb89b63 100755
> --- a/t/t9800-git-p4.sh
> +++ b/t/t9800-git-p4.sh
> @@ -2,40 +2,16 @@
>
> test_description='git-p4 tests'
>
> -. ./test-lib.sh
> +. ./lib-git-p4.sh
>
> +test_expect_success 'start p4d' '
> + kill_p4d || : &&
> + start_p4d &&
> + cd "$TRASH_DIRECTORY"
> '
Don't "chdir" around in the test, and worse yet hide some "cd" in helper
functions. The seemingly unnecessary "cd $TRASH_DIRECTORY" at the end,
which may not even happen if start_p4d fails, is because start_p4d has a
hidden "cd" somewhere (which in turn may or may not run depending on where
in the && chain you have a failure).
One way to keep the test cleaner is to do the helper functions like the
following, so that the callers do not have to worry about where they end
up with:
start_p4d () {
mkdir -p "$db" "$cli" "$git" &&
p4d -q -d -r "$db" -p "$P4DPORT" &&
(
cd "$cli" &&
p4 client -i <<-EOF
...
EOF
)
}
> test_expect_success 'add p4 files' '
> cd "$cli" &&
> echo file1 >file1 &&
> p4 add file1 &&
> p4 submit -d "file1" &&
> ...
> cd "$TRASH_DIRECTORY"
> '
The same issue here.
test_expect_success 'add p4 files' '
(
cd "$cli" &&
echo file1 >file1 &&
...
)
'
^ permalink raw reply
* Re: Branch deletion (Re: [RFC] fast-import: note deletion command)
From: Jonathan Nieder @ 2011-09-18 21:49 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Dmitry Ivankov, Git List, David Barr, Shawn O. Pearce,
Thomas Rast, Johan Herland
In-Reply-To: <CAGdFq_gH=u1BU6k3Z23Lo9mOSE4Rq-6nWU0EE91CQNpxksGw5w@mail.gmail.com>
Sverre Rabbelier wrote:
> The problem currently is that when
> you try to "git push origin :experimental-branch", there is no way for
> the transport-helper code to tell the helper to delete the ref.
Ah! Thanks for explaining.
It also occurs to me that
reset refs/heads/experimental-branch
... rest of the fast-import stream comes here ...
could be used as an especially non-self-explanatory way to express
this kind of thing. :) No idea whether that works already. A
deleteref command and deleteref feature documented to be meant for
this purpose sound handy to me.
By the way, what does the "export" command do in the following
situation?
git push origin something-big:master
Does it assume the remote-tracking branch for master reflects what's
available on the other end and send a stream for
origin/master..something-big, or does it send the entire history of
something-big?
^ permalink raw reply
* Re: [PATCH 2/5] credential-cache: fix expiration calculation corner cases
From: Junio C Hamano @ 2011-09-18 21:51 UTC (permalink / raw)
To: Jeff King; +Cc: git, Thomas Rast, Brian Gernhardt
In-Reply-To: <20110914191757.GB28267@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> The main credential-cache daemon loop calls poll to wait for
> a client or to trigger the expiration of credentials. When
> the last credential we hold expires, we exit.
> ...
Thanks.
^ permalink raw reply
* Re: [PATCH v5 4/4] Accept tags in HEAD or MERGE_HEAD
From: Junio C Hamano @ 2011-09-18 21:51 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1316260665-1728-4-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> HEAD and MERGE_HEAD (among other branch tips) should never hold a
> tag. That can only be caused by broken tools and is cumbersome to fix
> by an end user with:
>
> $ git update-ref HEAD $(git rev-parse HEAD^{commit})
>
> which may look like a magic to a new person.
> ...
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Nicely done.
Just a few micronits.
> diff --git a/commit.h b/commit.h
> ...
> +/*
> + * Look sha1 up for a commit, defer if needed. If dereference occurs,
That's s/defer/deref/;
> + * update "sha1" for consistency with retval->object.sha1. Also warn
> + * users this case because it is expected that sha1 points directly to
> + * a commit.
> + */
> +struct commit *lookup_commit_or_die(const unsigned char *sha1, const char *ref_name);
This no longer updates sha1 now it is a pointer to a const arena.
I'll update this part as follows, and queue the result.
/*
* Look up object named by "sha1", dereference tag as necessary,
* get a commit and return it. If "sha1" does not dereference to
* a commit, use ref_name to report an error and die.
*/
Thanks.
^ permalink raw reply
* Re: Branch deletion (Re: [RFC] fast-import: note deletion command)
From: Dmitry Ivankov @ 2011-09-18 21:54 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Sverre Rabbelier, Git List, David Barr, Shawn O. Pearce,
Thomas Rast, Johan Herland
In-Reply-To: <20110918214954.GL2308@elie>
On Mon, Sep 19, 2011 at 3:49 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Sverre Rabbelier wrote:
>
>> The problem currently is that when
>> you try to "git push origin :experimental-branch", there is no way for
>> the transport-helper code to tell the helper to delete the ref.
>
> Ah! Thanks for explaining.
>
> It also occurs to me that
>
> reset refs/heads/experimental-branch
>
> ... rest of the fast-import stream comes here ...
>
> could be used as an especially non-self-explanatory way to express
> this kind of thing. :) No idea whether that works already.
feature force
reset refs/heads/experimental-branch
Will be close. It'll overwrite the branch if any commits are done to
it. But will
keep it as is in case it's not touched in the rest of the fast-import stream.
> A deleteref command and deleteref feature documented to be meant for
> this purpose sound handy to me.
>
> By the way, what does the "export" command do in the following
> situation?
>
> git push origin something-big:master
>
> Does it assume the remote-tracking branch for master reflects what's
> available on the other end and send a stream for
> origin/master..something-big, or does it send the entire history of
> something-big?
>
^ permalink raw reply
* Re: Branch deletion (Re: [RFC] fast-import: note deletion command)
From: Sverre Rabbelier @ 2011-09-18 21:55 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Dmitry Ivankov, Git List, David Barr, Shawn O. Pearce,
Thomas Rast, Johan Herland
In-Reply-To: <20110918214954.GL2308@elie>
Heya,
On Sun, Sep 18, 2011 at 23:49, Jonathan Nieder <jrnieder@gmail.com> wrote:
> By the way, what does the "export" command do in the following
> situation?
>
> git push origin something-big:master
>
> Does it assume the remote-tracking branch for master reflects what's
> available on the other end and send a stream for
> origin/master..something-big, or does it send the entire history of
> something-big?
We have a test case for this actually. It goes like this:
checking known breakage:
(cd clone &&
git push origin new-name:new-refspec
) &&
compare_refs clone HEAD server refs/heads/new-refspec
Everything up-to-date
fatal: Needed a single revision
not ok 16 - push new branch with old:new refspec # TODO known breakage
In other words, we don't handle it at all. What we do handle a case
similar to what you say, where we have already pushed part of the
history of some-branch, and in that case we do indeed only push the
needed objects.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* [PATCH] SubmittingPatches: Remove diff tool examples
From: Sverre Rabbelier @ 2011-09-18 22:11 UTC (permalink / raw)
To: Ramkumar Ramachandra, Junio C Hamano, Git List; +Cc: Sverre Rabbelier
Since Cogito is long deprecated, it is somewhat awkward to leave it
as example. Removing Cogito leaves just git and StGit, which is a
rather incomplete list of git diff tools available. Sidestep the
problem of deciding what tools to mention by not mentioning any.
Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
---
This uses the subject Ramkumar suggested. Since the subject no
longer references Cogito, I've added a reference to the reason
for this removal as the first line of the description.
Documentation/SubmittingPatches | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 938eccf..0dbf2c9 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -134,8 +134,7 @@ Another thing: NULL pointers shall be written as NULL, not as 0.
(2) Generate your patch using git tools out of your commits.
-git based diff tools (git, Cogito, and StGIT included) generate
-unidiff which is the preferred format.
+git based diff tools generate unidiff which is the preferred format.
You do not have to be afraid to use -M option to "git diff" or
"git format-patch", if your patch involves file renames. The
--
1.7.6.1.724.g9519c
^ permalink raw reply related
* [PATCH] Teach progress eye-candy to fetch_refs_from_bundle()
From: Junio C Hamano @ 2011-09-18 23:52 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce
With the usual "git" transport, a large-ish transfer with "git fetch" and
"git pull" give progress eye-candy to avoid boring users. However, not
when they are reading from a bundle. I.e.
$ git pull ../git-bundle.bndl master
This teaches bundle.c:unbundle() to give "-v" option to index-pack and
tell it to give progress bar when transport decides it is necessary.
The operation in the other direction, "git bundle create", could also
learn to honor --quiet but that is a separate issue.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin/bundle.c | 2 +-
bundle.c | 7 +++++--
bundle.h | 3 ++-
transport.c | 3 ++-
4 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/builtin/bundle.c b/builtin/bundle.c
index 81046a9..92a8a60 100644
--- a/builtin/bundle.c
+++ b/builtin/bundle.c
@@ -58,7 +58,7 @@ int cmd_bundle(int argc, const char **argv, const char *prefix)
} else if (!strcmp(cmd, "unbundle")) {
if (!startup_info->have_repository)
die(_("Need a repository to unbundle."));
- return !!unbundle(&header, bundle_fd) ||
+ return !!unbundle(&header, bundle_fd, 0) ||
list_bundle_refs(&header, argc, argv);
} else
usage(builtin_bundle_usage);
diff --git a/bundle.c b/bundle.c
index f48fd7d..6bf8497 100644
--- a/bundle.c
+++ b/bundle.c
@@ -380,12 +380,15 @@ int create_bundle(struct bundle_header *header, const char *path,
return 0;
}
-int unbundle(struct bundle_header *header, int bundle_fd)
+int unbundle(struct bundle_header *header, int bundle_fd, int flags)
{
const char *argv_index_pack[] = {"index-pack",
- "--fix-thin", "--stdin", NULL};
+ "--fix-thin", "--stdin", NULL, NULL};
struct child_process ip;
+ if (flags & BUNDLE_VERBOSE)
+ argv_index_pack[3] = "-v";
+
if (verify_bundle(header, 0))
return -1;
memset(&ip, 0, sizeof(ip));
diff --git a/bundle.h b/bundle.h
index e2aedd6..c5a22c8 100644
--- a/bundle.h
+++ b/bundle.h
@@ -18,7 +18,8 @@ int read_bundle_header(const char *path, struct bundle_header *header);
int create_bundle(struct bundle_header *header, const char *path,
int argc, const char **argv);
int verify_bundle(struct bundle_header *header, int verbose);
-int unbundle(struct bundle_header *header, int bundle_fd);
+#define BUNDLE_VERBOSE 1
+int unbundle(struct bundle_header *header, int bundle_fd, int flags);
int list_bundle_refs(struct bundle_header *header,
int argc, const char **argv);
diff --git a/transport.c b/transport.c
index fa279d5..e194061 100644
--- a/transport.c
+++ b/transport.c
@@ -432,7 +432,8 @@ static int fetch_refs_from_bundle(struct transport *transport,
int nr_heads, struct ref **to_fetch)
{
struct bundle_transport_data *data = transport->data;
- return unbundle(&data->header, data->fd);
+ return unbundle(&data->header, data->fd,
+ transport->progress ? BUNDLE_VERBOSE : 0);
}
static int close_bundle(struct transport *transport)
^ permalink raw reply related
* [PATCH 0/8] fast-import: cache oe more often
From: Dmitry Ivankov @ 2011-09-19 1:27 UTC (permalink / raw)
To: git
Cc: Jonathan Nieder, Shawn O. Pearce, David Barr, Sverre Rabbelier,
Dmitry Ivankov
fast-import keeps a struct object_entry for each object written to
it's pack. This is to keep type, pack-coordinates and delta_depth.
struct object_entry is also used to cache this metadata for objects
that exist outside fast-import's pack ('old' objects).
struct object_entry has a small fixed size and thus it should be
reasonable to cache any 'old' object metadata retrieval to save the
disk i/o.
Also it is a step toward making fast-import identify objects via
struct object_entry rather than sha1. One pointer takes less than
20 bytes, it'll be later possible to have references to objects
that don't yet have sha1 computed (fast-import with threads future).
Dmitry Ivankov (8):
fast-import: cache oe in file_change_m
fast-import: cache oe in parse_new_tag
fast-import: cache oe in note_change_n
fast-import: extract common sha1_file access functions
fast-import: tiny optimization in read_marks
fast-import: cache oe in load_tree
fast-import: cache oe in cat_blob
fast-import: cache objects while dereferencing
fast-import.c | 177 +++++++++++++++++++++++++++++++--------------------------
1 files changed, 96 insertions(+), 81 deletions(-)
--
1.7.3.4
^ permalink raw reply
* [PATCH 1/8] fast-import: cache oe in file_change_m
From: Dmitry Ivankov @ 2011-09-19 1:27 UTC (permalink / raw)
To: git
Cc: Jonathan Nieder, Shawn O. Pearce, David Barr, Sverre Rabbelier,
Dmitry Ivankov
In-Reply-To: <1316395657-6991-1-git-send-email-divanorama@gmail.com>
file_change_m checks object type for objects specified by sha1. It does
so via sha1_object_info but doesn't cache this information in struct
object_entry.
Make this call to sha1_object_info cached in struct object_entry.
Signed-off-by: Dmitry Ivankov <divanorama@gmail.com>
---
fast-import.c | 22 ++++++++++++++--------
1 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index 742e7da..42f9b17 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -2297,15 +2297,21 @@ static void file_change_m(struct branch *b)
} else {
enum object_type expected = S_ISDIR(mode) ?
OBJ_TREE: OBJ_BLOB;
- enum object_type type = oe ? oe->type :
- sha1_object_info(sha1, NULL);
- if (type < 0)
- die("%s not found: %s",
- S_ISDIR(mode) ? "Tree" : "Blob",
- command_buf.buf);
- if (type != expected)
+ if (!oe)
+ oe = insert_object(sha1);
+ if (!oe->idx.offset) {
+ enum object_type type = sha1_object_info(oe->idx.sha1, NULL);
+ if (type < 0)
+ die("%s not found: %s",
+ S_ISDIR(mode) ? "Tree" : "Blob",
+ command_buf.buf);
+ oe->type = type;
+ oe->pack_id = MAX_PACK_ID;
+ oe->idx.offset = 1; /* nonzero */
+ }
+ if (oe->type != expected)
die("Not a %s (actually a %s): %s",
- typename(expected), typename(type),
+ typename(expected), typename(oe->type),
command_buf.buf);
}
--
1.7.3.4
^ permalink raw reply related
* [PATCH 2/8] fast-import: cache oe in parse_new_tag
From: Dmitry Ivankov @ 2011-09-19 1:27 UTC (permalink / raw)
To: git
Cc: Jonathan Nieder, Shawn O. Pearce, David Barr, Sverre Rabbelier,
Dmitry Ivankov
In-Reply-To: <1316395657-6991-1-git-send-email-divanorama@gmail.com>
parse_new_tag uses sha1_object_info to find out the type of an object
given by a sha1 expression. But doesn't cache it in struct object_entry.
Make this call to sha1_object_info cached in struct object_entry.
Signed-off-by: Dmitry Ivankov <divanorama@gmail.com>
---
fast-import.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index 42f9b17..2b049f7 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -2732,11 +2732,14 @@ static void parse_new_tag(void)
type = oe->type;
hashcpy(sha1, oe->idx.sha1);
} else if (!get_sha1(from, sha1)) {
- struct object_entry *oe = find_object(sha1);
- if (!oe) {
+ struct object_entry *oe = insert_object(sha1);
+ if (!oe->idx.offset) {
type = sha1_object_info(sha1, NULL);
if (type < 0)
die("Not a valid object: %s", from);
+ oe->type = type;
+ oe->pack_id = MAX_PACK_ID;
+ oe->idx.offset = 1; /* nonzero */
} else
type = oe->type;
} else
--
1.7.3.4
^ permalink raw reply related
* [PATCH 3/8] fast-import: cache oe in note_change_n
From: Dmitry Ivankov @ 2011-09-19 1:27 UTC (permalink / raw)
To: git
Cc: Jonathan Nieder, Shawn O. Pearce, David Barr, Sverre Rabbelier,
Dmitry Ivankov
In-Reply-To: <1316395657-6991-1-git-send-email-divanorama@gmail.com>
note_change_n checks the type of annotating data object to be Blob.
For objects given by sha1 it does so via sha1_object_info and does not
cache the result in struct object_entry.
Make this call to sha1_object_info cached in struct object_entry. Also
make note_change_n operate on oe rather than on sha1 - no functional
change, just a purification.
Signed-off-by: Dmitry Ivankov <divanorama@gmail.com>
---
fast-import.c | 30 +++++++++++++++++-------------
1 files changed, 17 insertions(+), 13 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index 2b049f7..47c1e69 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -2394,9 +2394,9 @@ static void note_change_n(struct branch *b, unsigned char old_fanout)
{
const char *p = command_buf.buf + 2;
static struct strbuf uq = STRBUF_INIT;
- struct object_entry *oe = oe;
+ struct object_entry *oe = NULL;
struct branch *s;
- unsigned char sha1[20], commit_sha1[20];
+ unsigned char commit_sha1[20];
char path[60];
uint16_t inline_data = 0;
unsigned char new_fanout;
@@ -2405,15 +2405,16 @@ static void note_change_n(struct branch *b, unsigned char old_fanout)
if (*p == ':') {
char *x;
oe = find_mark(strtoumax(p + 1, &x, 10));
- hashcpy(sha1, oe->idx.sha1);
p = x;
} else if (!prefixcmp(p, "inline")) {
inline_data = 1;
p += 6;
} else {
+ unsigned char sha1[20];
if (get_sha1_hex(p, sha1))
die("Invalid SHA1: %s", command_buf.buf);
- oe = find_object(sha1);
+ if (!is_null_sha1(sha1))
+ oe = insert_object(sha1);
p += 40;
}
if (*p++ != ' ')
@@ -2440,36 +2441,39 @@ static void note_change_n(struct branch *b, unsigned char old_fanout)
die("Invalid ref name or SHA1 expression: %s", p);
if (inline_data) {
+ unsigned char sha1[20];
if (p != uq.buf) {
strbuf_addstr(&uq, p);
p = uq.buf;
}
read_next_command();
parse_and_store_blob(&last_blob, sha1, 0);
+ oe = find_object(sha1);
} else if (oe) {
+ if (!oe->idx.offset) {
+ enum object_type type = sha1_object_info(oe->idx.sha1, NULL);
+ if (type < 0)
+ die("Blob not found: %s", command_buf.buf);
+ oe->type = type;
+ oe->pack_id = MAX_PACK_ID;
+ oe->idx.offset = 1; /* nonzero */
+ }
if (oe->type != OBJ_BLOB)
die("Not a blob (actually a %s): %s",
typename(oe->type), command_buf.buf);
- } else if (!is_null_sha1(sha1)) {
- enum object_type type = sha1_object_info(sha1, NULL);
- if (type < 0)
- die("Blob not found: %s", command_buf.buf);
- if (type != OBJ_BLOB)
- die("Not a blob (actually a %s): %s",
- typename(type), command_buf.buf);
}
construct_path_with_fanout(sha1_to_hex(commit_sha1), old_fanout, path);
if (tree_content_remove(&b->branch_tree, path, NULL))
b->num_notes--;
- if (is_null_sha1(sha1))
+ if (!oe)
return; /* nothing to insert */
b->num_notes++;
new_fanout = convert_num_notes_to_fanout(b->num_notes);
construct_path_with_fanout(sha1_to_hex(commit_sha1), new_fanout, path);
- tree_content_set(&b->branch_tree, path, sha1, S_IFREG | 0644, NULL);
+ tree_content_set(&b->branch_tree, path, oe->idx.sha1, S_IFREG | 0644, NULL);
}
static void file_change_deleteall(struct branch *b)
--
1.7.3.4
^ permalink raw reply related
* [PATCH 6/8] fast-import: cache oe in load_tree
From: Dmitry Ivankov @ 2011-09-19 1:27 UTC (permalink / raw)
To: git
Cc: Jonathan Nieder, Shawn O. Pearce, David Barr, Sverre Rabbelier,
Dmitry Ivankov
In-Reply-To: <1316395657-6991-1-git-send-email-divanorama@gmail.com>
load_tree reads a tree object given it's sha1. If there was no
struct object_entry allocated for this sha1, load_tree doesn't
allocate it and thus doesn't cache it's struct object_entry.
Make this read_sha1_file cached in struct object_entry.
Signed-off-by: Dmitry Ivankov <divanorama@gmail.com>
---
fast-import.c | 20 +++++++++++++++++---
1 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index dd3dcd5..1c0716b 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -599,6 +599,17 @@ static void resolve_sha1_object(struct object_entry *oe)
oe->idx.offset = 1; /* nonzero */
}
+static void *resolve_sha1_object_read(struct object_entry *oe, enum object_type *type, unsigned long *size)
+{
+ void *ret = read_sha1_file(oe->idx.sha1, type, size);
+ if (!ret)
+ return ret;
+ oe->type = *type;
+ oe->pack_id = MAX_PACK_ID;
+ oe->idx.offset = 1; /* nonzero */
+ return ret;
+}
+
static int try_resolve_sha1_pack_object(struct object_entry *e,
enum object_type type)
{
@@ -1363,8 +1374,8 @@ static void load_tree(struct tree_entry *root)
if (is_null_sha1(sha1))
return;
- myoe = find_object(sha1);
- if (myoe && myoe->pack_id != MAX_PACK_ID) {
+ myoe = insert_object(sha1);
+ if (myoe->idx.offset && myoe->pack_id != MAX_PACK_ID) {
if (myoe->type != OBJ_TREE)
die("Not a tree: %s", sha1_to_hex(sha1));
t->delta_depth = myoe->depth;
@@ -1373,7 +1384,10 @@ static void load_tree(struct tree_entry *root)
die("Can't load tree %s", sha1_to_hex(sha1));
} else {
enum object_type type;
- buf = read_sha1_file(sha1, &type, &size);
+ if (!myoe->idx.offset)
+ buf = resolve_sha1_object_read(myoe, &type, &size);
+ else
+ buf = read_sha1_file(sha1, &type, &size);
if (!buf || type != OBJ_TREE)
die("Can't load tree %s", sha1_to_hex(sha1));
}
--
1.7.3.4
^ permalink raw reply related
* [PATCH 4/8] fast-import: extract common sha1_file access functions
From: Dmitry Ivankov @ 2011-09-19 1:27 UTC (permalink / raw)
To: git
Cc: Jonathan Nieder, Shawn O. Pearce, David Barr, Sverre Rabbelier,
Dmitry Ivankov
In-Reply-To: <1316395657-6991-1-git-send-email-divanorama@gmail.com>
fast-import asks sha1_object_info and find_sha1_pack to initialize
struct object_entry in several codepoints.
Extract common functions doing this initialization.
Signed-off-by: Dmitry Ivankov <divanorama@gmail.com>
---
fast-import.c | 82 +++++++++++++++++++++++---------------------------------
1 files changed, 34 insertions(+), 48 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index 47c1e69..3c2a067 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -589,6 +589,28 @@ static struct object_entry *insert_object(unsigned char *sha1)
return e;
}
+static void resolve_sha1_object(struct object_entry *oe)
+{
+ enum object_type type = sha1_object_info(oe->idx.sha1, NULL);
+ if (type < 0)
+ die("object not found: %s", sha1_to_hex(oe->idx.sha1));
+ oe->type = type;
+ oe->pack_id = MAX_PACK_ID;
+ oe->idx.offset = 1; /* nonzero */
+}
+
+static int try_resolve_sha1_pack_object(struct object_entry *e,
+ enum object_type type)
+{
+ if (!find_sha1_pack(e->idx.sha1, packed_git))
+ return 0;
+
+ e->type = type;
+ e->pack_id = MAX_PACK_ID;
+ e->idx.offset = 1; /* just not zero! */
+ return 1;
+}
+
static unsigned int hc_str(const char *s, size_t len)
{
unsigned int r = 0;
@@ -1042,10 +1064,7 @@ static int store_object(
if (e->idx.offset) {
duplicate_count_by_type[type]++;
return 1;
- } else if (find_sha1_pack(sha1, packed_git)) {
- e->type = type;
- e->pack_id = MAX_PACK_ID;
- e->idx.offset = 1; /* just not zero! */
+ } else if (try_resolve_sha1_pack_object(e, type)) {
duplicate_count_by_type[type]++;
return 1;
}
@@ -1252,10 +1271,7 @@ static void stream_blob(uintmax_t len, unsigned char *sha1out, uintmax_t mark)
duplicate_count_by_type[OBJ_BLOB]++;
truncate_pack(offset, &pack_file_ctx);
- } else if (find_sha1_pack(sha1, packed_git)) {
- e->type = OBJ_BLOB;
- e->pack_id = MAX_PACK_ID;
- e->idx.offset = 1; /* just not zero! */
+ } else if (try_resolve_sha1_pack_object(e, OBJ_BLOB)) {
duplicate_count_by_type[OBJ_BLOB]++;
truncate_pack(offset, &pack_file_ctx);
@@ -1838,13 +1854,8 @@ static void read_marks(void)
die("corrupt mark line: %s", line);
e = find_object(sha1);
if (!e) {
- enum object_type type = sha1_object_info(sha1, NULL);
- if (type < 0)
- die("object not found: %s", sha1_to_hex(sha1));
e = insert_object(sha1);
- e->type = type;
- e->pack_id = MAX_PACK_ID;
- e->idx.offset = 1; /* just not zero! */
+ resolve_sha1_object(e);
}
insert_mark(mark, e);
}
@@ -2299,16 +2310,8 @@ static void file_change_m(struct branch *b)
OBJ_TREE: OBJ_BLOB;
if (!oe)
oe = insert_object(sha1);
- if (!oe->idx.offset) {
- enum object_type type = sha1_object_info(oe->idx.sha1, NULL);
- if (type < 0)
- die("%s not found: %s",
- S_ISDIR(mode) ? "Tree" : "Blob",
- command_buf.buf);
- oe->type = type;
- oe->pack_id = MAX_PACK_ID;
- oe->idx.offset = 1; /* nonzero */
- }
+ if (!oe->idx.offset)
+ resolve_sha1_object(oe);
if (oe->type != expected)
die("Not a %s (actually a %s): %s",
typename(expected), typename(oe->type),
@@ -2450,14 +2453,8 @@ static void note_change_n(struct branch *b, unsigned char old_fanout)
parse_and_store_blob(&last_blob, sha1, 0);
oe = find_object(sha1);
} else if (oe) {
- if (!oe->idx.offset) {
- enum object_type type = sha1_object_info(oe->idx.sha1, NULL);
- if (type < 0)
- die("Blob not found: %s", command_buf.buf);
- oe->type = type;
- oe->pack_id = MAX_PACK_ID;
- oe->idx.offset = 1; /* nonzero */
- }
+ if (!oe->idx.offset)
+ resolve_sha1_object(oe);
if (oe->type != OBJ_BLOB)
die("Not a blob (actually a %s): %s",
typename(oe->type), command_buf.buf);
@@ -2737,15 +2734,10 @@ static void parse_new_tag(void)
hashcpy(sha1, oe->idx.sha1);
} else if (!get_sha1(from, sha1)) {
struct object_entry *oe = insert_object(sha1);
- if (!oe->idx.offset) {
- type = sha1_object_info(sha1, NULL);
- if (type < 0)
- die("Not a valid object: %s", from);
- oe->type = type;
- oe->pack_id = MAX_PACK_ID;
- oe->idx.offset = 1; /* nonzero */
- } else
- type = oe->type;
+ if (!oe->idx.offset)
+ resolve_sha1_object(oe);
+
+ type = oe->type;
} else
die("Invalid ref name or SHA1 expression: %s", from);
read_next_command();
@@ -2892,14 +2884,8 @@ static struct object_entry *dereference(struct object_entry *oe,
unsigned long size;
char *buf = NULL;
if (!oe) {
- enum object_type type = sha1_object_info(sha1, NULL);
- if (type < 0)
- die("object not found: %s", sha1_to_hex(sha1));
- /* cache it! */
oe = insert_object(sha1);
- oe->type = type;
- oe->pack_id = MAX_PACK_ID;
- oe->idx.offset = 1;
+ resolve_sha1_object(oe);
}
switch (oe->type) {
case OBJ_TREE: /* easy case. */
--
1.7.3.4
^ permalink raw reply related
* [PATCH 7/8] fast-import: cache oe in cat_blob
From: Dmitry Ivankov @ 2011-09-19 1:27 UTC (permalink / raw)
To: git
Cc: Jonathan Nieder, Shawn O. Pearce, David Barr, Sverre Rabbelier,
Dmitry Ivankov
In-Reply-To: <1316395657-6991-1-git-send-email-divanorama@gmail.com>
cat_blob read_sha1_file's the blob object and doesn't cache
it in struct object_entry.
Make this call to read_sha1_file cached in struct object_entry.
Signed-off-by: Dmitry Ivankov <divanorama@gmail.com>
---
fast-import.c | 25 +++++++++++++------------
1 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index 1c0716b..3c4c998 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -2816,16 +2816,18 @@ static void cat_blob_write(const char *buf, unsigned long size)
die_errno("Write to frontend failed");
}
-static void cat_blob(struct object_entry *oe, unsigned char sha1[20])
+static void cat_blob(struct object_entry *oe)
{
struct strbuf line = STRBUF_INIT;
unsigned long size;
enum object_type type = 0;
char *buf;
- if (!oe || oe->pack_id == MAX_PACK_ID) {
- buf = read_sha1_file(sha1, &type, &size);
- } else {
+ if (!oe->idx.offset)
+ buf = resolve_sha1_object_read(oe, &type, &size);
+ else if (oe->pack_id == MAX_PACK_ID)
+ buf = read_sha1_file(oe->idx.sha1, &type, &size);
+ else {
type = oe->type;
buf = gfi_unpack_entry(oe, &size);
}
@@ -2835,25 +2837,25 @@ static void cat_blob(struct object_entry *oe, unsigned char sha1[20])
*/
if (type <= 0) {
strbuf_reset(&line);
- strbuf_addf(&line, "%s missing\n", sha1_to_hex(sha1));
+ strbuf_addf(&line, "%s missing\n", sha1_to_hex(oe->idx.sha1));
cat_blob_write(line.buf, line.len);
strbuf_release(&line);
free(buf);
return;
}
if (!buf)
- die("Can't read object %s", sha1_to_hex(sha1));
+ die("Can't read object %s", sha1_to_hex(oe->idx.sha1));
if (type != OBJ_BLOB)
die("Object %s is a %s but a blob was expected.",
- sha1_to_hex(sha1), typename(type));
+ sha1_to_hex(oe->idx.sha1), typename(type));
strbuf_reset(&line);
- strbuf_addf(&line, "%s %s %lu\n", sha1_to_hex(sha1),
+ strbuf_addf(&line, "%s %s %lu\n", sha1_to_hex(oe->idx.sha1),
typename(type), size);
cat_blob_write(line.buf, line.len);
strbuf_release(&line);
cat_blob_write(buf, size);
cat_blob_write("\n", 1);
- if (oe && oe->pack_id == pack_id) {
+ if (oe->pack_id == pack_id) {
last_blob.offset = oe->idx.offset;
strbuf_attach(&last_blob.data, buf, size, size);
last_blob.depth = oe->depth;
@@ -2878,16 +2880,15 @@ static void parse_cat_blob(void)
die("Unknown mark: %s", command_buf.buf);
if (*x)
die("Garbage after mark: %s", command_buf.buf);
- hashcpy(sha1, oe->idx.sha1);
} else {
if (get_sha1_hex(p, sha1))
die("Invalid SHA1: %s", command_buf.buf);
if (p[40])
die("Garbage after SHA1: %s", command_buf.buf);
- oe = find_object(sha1);
+ oe = insert_object(sha1);
}
- cat_blob(oe, sha1);
+ cat_blob(oe);
}
static struct object_entry *dereference(struct object_entry *oe,
--
1.7.3.4
^ permalink raw reply related
* [PATCH 8/8] fast-import: cache objects while dereferencing
From: Dmitry Ivankov @ 2011-09-19 1:27 UTC (permalink / raw)
To: git
Cc: Jonathan Nieder, Shawn O. Pearce, David Barr, Sverre Rabbelier,
Dmitry Ivankov
In-Reply-To: <1316395657-6991-1-git-send-email-divanorama@gmail.com>
dereference() reads objects with read_sha1_file, and reads types
of objects with sha1_object_info. But doesn't cache the result in
struct object_entry.
Make these calls to read_sha1_file and sha1_object_info cached in
struct object_entry.
Signed-off-by: Dmitry Ivankov <divanorama@gmail.com>
---
fast-import.c | 31 +++++++++++++++++--------------
1 files changed, 17 insertions(+), 14 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index 3c4c998..43158c8 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -2891,15 +2891,11 @@ static void parse_cat_blob(void)
cat_blob(oe);
}
-static struct object_entry *dereference(struct object_entry *oe,
- unsigned char sha1[20])
+static struct object_entry *dereference(struct object_entry *oe)
{
+ unsigned char next_sha1[20];
unsigned long size;
char *buf = NULL;
- if (!oe) {
- oe = insert_object(sha1);
- resolve_sha1_object(oe);
- }
switch (oe->type) {
case OBJ_TREE: /* easy case. */
return oe;
@@ -2914,26 +2910,31 @@ static struct object_entry *dereference(struct object_entry *oe,
buf = gfi_unpack_entry(oe, &size);
} else {
enum object_type unused;
- buf = read_sha1_file(sha1, &unused, &size);
+ buf = read_sha1_file(oe->idx.sha1, &unused, &size);
}
if (!buf)
- die("Can't load object %s", sha1_to_hex(sha1));
+ die("Can't load object %s", sha1_to_hex(oe->idx.sha1));
/* Peel one layer. */
switch (oe->type) {
case OBJ_TAG:
if (size < 40 + strlen("object ") ||
- get_sha1_hex(buf + strlen("object "), sha1))
+ get_sha1_hex(buf + strlen("object "), next_sha1))
die("Invalid SHA1 in tag: %s", command_buf.buf);
break;
case OBJ_COMMIT:
if (size < 40 + strlen("tree ") ||
- get_sha1_hex(buf + strlen("tree "), sha1))
+ get_sha1_hex(buf + strlen("tree "), next_sha1))
die("Invalid SHA1 in commit: %s", command_buf.buf);
}
free(buf);
- return find_object(sha1);
+
+ oe = insert_object(next_sha1);
+ if (!oe->idx.offset)
+ resolve_sha1_object(oe);
+
+ return oe;
}
static struct object_entry *parse_treeish_dataref(const char **p)
@@ -2953,12 +2954,14 @@ static struct object_entry *parse_treeish_dataref(const char **p)
} else { /* <sha1> */
if (get_sha1_hex(*p, sha1))
die("Invalid SHA1: %s", command_buf.buf);
- e = find_object(sha1);
+ e = insert_object(sha1);
+ if (!e->idx.offset)
+ resolve_sha1_object(e);
*p += 40;
}
- while (!e || e->type != OBJ_TREE)
- e = dereference(e, sha1);
+ while (e->type != OBJ_TREE)
+ e = dereference(e);
return e;
}
--
1.7.3.4
^ permalink raw reply related
* [PATCH 5/8] fast-import: tiny optimization in read_marks
From: Dmitry Ivankov @ 2011-09-19 1:27 UTC (permalink / raw)
To: git
Cc: Jonathan Nieder, Shawn O. Pearce, David Barr, Sverre Rabbelier,
Dmitry Ivankov
In-Reply-To: <1316395657-6991-1-git-send-email-divanorama@gmail.com>
read_marks calls find_object and then insert_object if nothing is found.
Reduce it to just insert_object and a check if it was found or inserted.
Signed-off-by: Dmitry Ivankov <divanorama@gmail.com>
---
fast-import.c | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index 3c2a067..dd3dcd5 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -1852,11 +1852,9 @@ static void read_marks(void)
if (!mark || end == line + 1
|| *end != ' ' || get_sha1(end + 1, sha1))
die("corrupt mark line: %s", line);
- e = find_object(sha1);
- if (!e) {
- e = insert_object(sha1);
+ e = insert_object(sha1);
+ if (!e->idx.offset)
resolve_sha1_object(e);
- }
insert_mark(mark, e);
}
fclose(f);
--
1.7.3.4
^ permalink raw reply related
* [ANNOUNCE] Git 1.7.7.rc2
From: Junio C Hamano @ 2011-09-19 6:15 UTC (permalink / raw)
To: git; +Cc: Linux Kernel
A release candidate Git 1.7.7.rc2 is available but unfortunately not at
the usual places. Even so (rather, exactly because it is in unusual
places, so we are likely to have smaller number of casual observers who
grab and build them), please test it to help us make the upcoming release
as solid as we could.
A release candidate tarball is found at:
http://code.google.com/p/git-core/downloads/list
and its SHA-1 checksum is:
1e0e035148df279af689131273570a7dde45950b git-1.7.7.rc2.tar.gz
Also the following public repositories all have a copy of the v1.7.7-rc2
tag and the master branch that the tag points at:
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
url = https://github.com/gitster/git
----------------------------------------------------------------
Changes since v1.7.7-rc1 are as follows:
Bryan Jacobs (1):
git-svn: teach git-svn to populate svn:mergeinfo
Frédéric Heitzmann (1):
Disambiguate duplicate t9160* tests
Junio C Hamano (2):
branch --set-upstream: regression fix
Git 1.7.7-rc2
Pang Yan Han (1):
format-patch: ignore ui.color
^ permalink raw reply
* [PATCH] t4014: remove Message-Id/timestamp before comparing patches
From: Thomas Rast @ 2011-09-19 6:45 UTC (permalink / raw)
To: Pang Yan Han; +Cc: Jeff King, Junio C Hamano, git
The test introduced in 787570c (format-patch: ignore ui.color,
2011-09-13) has a race condition: if the two format-patch invocations
do not ask for the current time in the same second, their Message-Id
headers will disagree.
Normally this would be a pretty unlikely occurrence. However, under
valgrind format-patch runs so slowly that the race triggers every
time, with a time difference of 2-3s on my hardware.
To avoid this problem, replace the contents of the Message-Id header
with a dummy before comparing.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
t/t4014-format-patch.sh | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
index 7e405d7..8700089 100755
--- a/t/t4014-format-patch.sh
+++ b/t/t4014-format-patch.sh
@@ -886,11 +886,18 @@ test_expect_success 'empty subject prefix does not have extra space' '
test_cmp expect actual
'
+strip_msgid () {
+ sed 's#\(Message-Id: *\)<[^>]*>#\1<MESSAGE@ID>#' "$1" >"$1+" &&
+ mv "$1+" "$1"
+}
+
test_expect_success 'format patch ignores color.ui' '
test_unconfig color.ui &&
git format-patch --stdout -1 >expect &&
+ strip_msgid expect &&
test_config color.ui always &&
git format-patch --stdout -1 >actual &&
+ strip_msgid actual &&
test_cmp expect actual
'
--
1.7.7.rc1.366.ge210a6
^ permalink raw reply related
* Re: Problem with submodule merge
From: Nicolas Morey-Chaisemartin @ 2011-09-19 7:55 UTC (permalink / raw)
To: Heiko Voigt; +Cc: git
In-Reply-To: <20110916145724.GA2782@book.hvoigt.net>
Hi,
You're right, this fixes the issue:
$ git merge origin/prerelease/0.3-0
warning: Failed to merge submodule db (merge following commits not found)
Auto-merging db
CONFLICT (submodule): Merge conflict in db
Automatic merge failed; fix conflicts and then commit the result.
Thanks for the help
Nicolas
On 09/16/2011 04:57 PM, Heiko Voigt wrote:
> Hi,
>
> this looks like you have hit a codepath where the submodules object
> database is not added to the object database. I am not sure why.
>
> Could you try my patch that moves the merge search into a forked process:
>
> 3dcb369b allow multiple calls to submodule merge search for the same path
>
> That should solve the issue as a side effect. Its currently in Junio's
> pu branch.
>
> Cheers Heiko
>
> On Fri, Sep 16, 2011 at 02:48:02PM +0200, Nicolas Morey-Chaisemartin wrote:
>> Hi,
>>
>> We have meet an issue few times at work with submodule merge.
>> I'm running git 1.7.7-rc1 build from master on FC15 x86_64 but I've seen the issue on other ditro with older (stable) versions
>>
>> I still haven't figured out exactly when it happends but here are the symptoms:
>>
>> 1) I commited some updates for a submodule in our integration repo.
>> 2) I pulled a remote branch of the integration repo which had an update on the same submodule (but different SHAs)
>> 3) When the merge driver try to find a following commit for the submodule, I get some (sometimes many) error messages about refs that point to invalid objects:
>>
>> [nmorey@sat:SigmaCToolchain (user/nmorey/dev/0.3.0 *%>)]$ git merge origin/prerelease/0.3-0
>> error: refs/heads/user/nmorey/master does not point to a valid object!
>> error: refs/remotes/origin/dev/cpp does not point to a valid object!
>> error: refs/remotes/origin/dev/scuk does not point to a valid object!
>> error: refs/remotes/origin/dev/sys_agents does not point to a valid object!
>> error: refs/remotes/origin/user/bbodin/cea does not point to a valid object!
>> error: refs/remotes/origin/user/borgogoz/master does not point to a valid object!
>> warning: Failed to merge submodule db (merge following commits not found)
>> Auto-merging db
>> CONFLICT (submodule): Merge conflict in db
>> Automatic merge failed; fix conflicts and then commit the result.
>>
>>
>> I checked and the object really exists in the submodule but is in a pack.
>>
>> >From checking the strace, git looks for a the object in db/.git/objects/... whch does not exists
>> And from what I could figure it, the issue seems to be coming from find_pack_entry which does not return 1 so git goes looking for loose object
>> and cannot find any (as expected).
>> This is not a big issue as it just outputs errors about refs and does not block the user but it gets quite scary when there are a few hundreds of them !
>>
>>
>> I kept a tarball of the repo so I can provide more info/logs/trace if needed.
>>
>> Nicolas
>> --
>> To unsubscribe from this list: send the line "unsubscribe git" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Where is information of "git read-tree" stored?
From: Manuel Reimer @ 2011-09-19 8:46 UTC (permalink / raw)
To: git
Hello,
following situation:
- Project hosted on GIT. Have a local copy and push to remote server.
- Small addon is hosted on a remote SVN server
- I now cloned the SVN to a local GIT (svn git clone)
- Then I used the instructions from here:
<http://git-mirror.googlecode.com/git-history/7444c60/howto/using-merge-subtree.html>
to get the local SVN copy merged into a subdirectory on my project GIT. Anything
worked well.
To test the worst case, I cloned my project GIT to a new local repository. The
remote connection to the local SVN copy was lost, so I recreated it.
Now, for some reason, I can immediately call
git pull -s subtree Bproject master
to pull changes from the SVN copy to the subdir... I didn't have to call "git
read-tree" again. Where is this information stored? Why does GIT know where the
remote repository data has to be placed to? Can I view this information? Can I
edit it?
Is there some information available somewhere on which data is pushed to server
and which is only in my local repo?
What will happen if my SVN checkout to local GIT repo gets lost? Can I just
clone this from SVN again, connect this to my project GIT and it will work just
well without problems? Or should I keep a copy of this GIT repo on server just
to be sure nothing bad happens?
Thanks in advance
Yours
Manuel
^ permalink raw reply
* 群发软件+买家搜索机+109届广交会买家、海关数据,B2B询盘买家500万。
From: 仅10元每天 @ 2011-09-19 9:01 UTC (permalink / raw)
To: ginni, giovanni.delfranco, girishpal, girl.in.the.d,
giroussens.ceramique, gis45, gisc
群发软件+109届广交会买家、海关数据、搜索引擎买家,B2B询盘买家共500万,仅10元每天。
保证每天都有买家回复。
保证每天都有买家回复。
1、群发软件： 操作简单，功能强大，模仿人工操作模式，到达率高，日发送5万封以上。
2、500万广交会买家资源： 赠送的500万买家资源库，每月更新 。
3、超级海外买家Email搜索机： 每天能搜索1-2万以上买家真实EMAIL，成单率高。
要的抓紧联系QQ: 1339625218 或者立即回复邮箱: 1339625218@qq.com
要的抓紧联系QQ: 1339625218 或者立即回复邮箱: 1339625218@qq.com
要的抓紧联系QQ: 1339625218 或者立即回复邮箱: 1339625218@qq.com
免费赠送:
一共8个包(数据是全行业的，按照行业分好类，并且可以按照关键词查询的)：
1，2011春季109届广交会买家现场询盘数据库新鲜出炉，超级新鲜买家，新鲜数据，容易成单！
2，购买后可以免费更新2011秋季广交会+2012春季广交会买家数据。太超值了。
3，最新全球买家库,共451660条数据。 (最新更新日期 2011-05-16日)
4，2008年,2009年,2010年 春季+秋季广交会买家名录，103 104 105 106 107 108 共六届 共120.6万数据。
5，2010年国际促销协会（PPAI）成员名单 PPAI Members Directory，非常重要的大买家。
6，2010年到香港采购的国外客人名录(香港贸发局提供)，共7.2万数据，超级重要的买家。
7，48.68万条最新买家询盘，购买后每月更新 1-2万条，包括2部分，1，最新的询盘 2，最新的展会买家。免费更新36个月。
8，2009年海关提单数据piers版数据 1千万。
诚信为本，支持支付宝担保交易 (先发货并安装设置群发软件，然后付款) 彻底打消您的 顾虑。
精准数据-成单率极高
精准数据-成单率极高
精准数据-成单率极高
精准数据-成单率极高
精准数据-成单率极高
^ permalink raw reply
* Re: [PATCH] SubmittingPatches: Remove diff tool examples
From: Ramkumar Ramachandra @ 2011-09-19 9:23 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Junio C Hamano, Git List
In-Reply-To: <1316383901-17580-1-git-send-email-srabbelier@gmail.com>
Hi,
Sverre Rabbelier writes:
> This uses the subject Ramkumar suggested. Since the subject no
> longer references Cogito, I've added a reference to the reason
> for this removal as the first line of the description.
Too late: see v1.7.6.3~12.
-- Ram
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox