* [PATCH 1/2] fast-import: add 'commit from 0{40}' failing test
From: Dmitry Ivankov @ 2011-09-18 21:20 UTC (permalink / raw)
To: git
Cc: Jonathan Nieder, Shawn O. Pearce, David Barr, Sverre Rabbelier,
Dmitry Ivankov
In-Reply-To: <1316380846-15845-1-git-send-email-divanorama@gmail.com>
Following shouldn't be allowed, while it is:
commit refs/heads/some
committer ...
data ...
from `null_sha1`
It is treated as if 'from' was omitted. But it is allowed to just
omit 'from' actually. And `null_sha1` being special in fast-import
is an internal implementation detail.
Add a test as described.
Signed-off-by: Dmitry Ivankov <divanorama@gmail.com>
---
t/t9300-fast-import.sh | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/t/t9300-fast-import.sh b/t/t9300-fast-import.sh
index 1a6c066..8cc3f16 100755
--- a/t/t9300-fast-import.sh
+++ b/t/t9300-fast-import.sh
@@ -375,6 +375,18 @@ test_expect_success 'B: fail on invalid branch name "bad[branch]name"' '
rm -f .git/objects/pack_* .git/objects/index_*
cat >input <<INPUT_END
+commit refs/heads/zeromaster
+committer $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE
+data 0
+
+from 0000000000000000000000000000000000000000
+INPUT_END
+test_expect_failure 'B: fail on "from 0{40}"' '
+ test_must_fail git fast-import <input
+'
+rm -f .git/objects/pack_* .git/objects/index_*
+
+cat >input <<INPUT_END
commit TEMP_TAG
committer $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE
data <<COMMIT
--
1.7.3.4
^ permalink raw reply related
* [PATCH 2/2] fast-import: fix 'from 0{40}' test
From: Dmitry Ivankov @ 2011-09-18 21:20 UTC (permalink / raw)
To: git
Cc: Jonathan Nieder, Shawn O. Pearce, David Barr, Sverre Rabbelier,
Dmitry Ivankov
In-Reply-To: <1316380846-15845-1-git-send-email-divanorama@gmail.com>
parse_from_existing() has a special case for null_sha1 treating it
as a start of an orphaned branch. It is how null_sha1 parent is
treated in fast-import. For example parse_reset_branch() clears
sha1 of a branch but leaves it in a lookup table.
Looking at parse_from_existing() call sites, we can seen that it is
only called for sha1's that come from get_sha1() or an existing
object. So fast-import internals don't give it null_sha1 explicitly
and the only way for it to appear is direct '0{40}' in the input.
Don't treat null_sha1 as a magic sha1 in parse_from_existing thus
making 'from 0{40}' an invalid input. (Unless there is a commit
object having null_sha1, of course. And object with null_sha1 would
be a lot of trouble in fast-import regardless of this patch.)
Signed-off-by: Dmitry Ivankov <divanorama@gmail.com>
---
fast-import.c | 17 ++++++-----------
t/t9300-fast-import.sh | 2 +-
2 files changed, 7 insertions(+), 12 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index 742e7da..827434a 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -2488,18 +2488,13 @@ static void parse_from_commit(struct branch *b, char *buf, unsigned long size)
static void parse_from_existing(struct branch *b)
{
- if (is_null_sha1(b->sha1)) {
- hashclr(b->branch_tree.versions[0].sha1);
- hashclr(b->branch_tree.versions[1].sha1);
- } else {
- unsigned long size;
- char *buf;
+ unsigned long size;
+ char *buf;
- buf = read_object_with_reference(b->sha1,
- commit_type, &size, b->sha1);
- parse_from_commit(b, buf, size);
- free(buf);
- }
+ buf = read_object_with_reference(b->sha1,
+ commit_type, &size, b->sha1);
+ parse_from_commit(b, buf, size);
+ free(buf);
}
static int parse_from(struct branch *b)
diff --git a/t/t9300-fast-import.sh b/t/t9300-fast-import.sh
index 8cc3f16..0784d50 100755
--- a/t/t9300-fast-import.sh
+++ b/t/t9300-fast-import.sh
@@ -381,7 +381,7 @@ data 0
from 0000000000000000000000000000000000000000
INPUT_END
-test_expect_failure 'B: fail on "from 0{40}"' '
+test_expect_success 'B: fail on "from 0{40}"' '
test_must_fail git fast-import <input
'
rm -f .git/objects/pack_* .git/objects/index_*
--
1.7.3.4
^ permalink raw reply related
* Branch deletion (Re: [RFC] fast-import: note deletion command)
From: Jonathan Nieder @ 2011-09-18 21:18 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Dmitry Ivankov, Git List, David Barr, Shawn O. Pearce,
Thomas Rast, Johan Herland
In-Reply-To: <CAGdFq_hpA95Kj4eMr4e1duuXTpr+OkkwF4K5bTapXEi9UjWcSA@mail.gmail.com>
Sverre Rabbelier wrote:
> Is this perhaps a good moment to also think about branch deletion?
> That came up earlier as well, and thinking about that might give us
> some insights in how to deal with deletions uniformly.
Sorry, my earlier reply missed the point. To answer your question:
Dmitry's RFC was about deleting individual notes rather than entire
notes refs, so it is not too closely related to branch deletion.
A new "deleteref" command would be a very simple addition, and the UI
seems pretty obvious. The main concern in adding such a thing is that
it destroys history, while currently "git fast-import" without -f does
not provide any commands that can do that. So presumably one would
want to do one of the following:
- only allow deletion of refs that were not present at the start of
the import, or
- add a command-line option to permit deletion of refs, so it doesn't
happen by mistake when misparsing a stream.
It would also be interesting to see an example use (do you remember
the earlier thread where it came up?) to make sure the UI fits it
well. In most typical cases I can imagine, direct use of "git
update-ref -d" would work better. In the case of remote helpers, IIRC
there was already a need for the transport-helper to handle the final
ref updates so "git fetch" can write a nice notice about them to the
console.
^ permalink raw reply
* Re: [PATCH/RFC 0/2] fast-import: commit from null_sha1
From: Jonathan Nieder @ 2011-09-18 21:30 UTC (permalink / raw)
To: Dmitry Ivankov; +Cc: git, Shawn O. Pearce, David Barr, Sverre Rabbelier
In-Reply-To: <1316380846-15845-1-git-send-email-divanorama@gmail.com>
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? 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: Branch deletion (Re: [RFC] fast-import: note deletion command)
From: Sverre Rabbelier @ 2011-09-18 21:38 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Dmitry Ivankov, Git List, David Barr, Shawn O. Pearce,
Thomas Rast, Johan Herland
In-Reply-To: <20110918211836.GI2308@elie>
Heya,
On Sun, Sep 18, 2011 at 23:18, Jonathan Nieder <jrnieder@gmail.com> wrote:
> In the case of remote helpers, IIRC there was already a need for
> the transport-helper to handle the final ref updates so "git fetch"
> can write a nice notice about them to the console.
That book-keeping is trivial to do. 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.
Something like 'deleteref' sounds sane I suppose, and I agree that
there should be some sort of safety switch :). I think we need a new
feature announcing that we require support for it, and then the
importer can abort right away if the user doesn't want to have their
refs deleted.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* 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
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