* Re: [PATCH 2/2] pack-objects: fix threaded load balancing
From: Jon Smirl @ 2007-12-10 5:23 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <9e4733910712092030j5cf7dfdcrb3a003fbce391422@mail.gmail.com>
On 12/9/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> > + if (victim) {
> > + sub_size = victim->remaining / 2;
> > + list = victim->list + victim->list_size - sub_size;
> > + while (sub_size && list[0]->hash &&
> > + list[0]->hash == list[-1]->hash) {
> > + list++;
>
> I think you needed to copy sub_size to another variable for this loop
Copying sub_size was wrong. I believe you are checking for deltas on
the same file. It's probably that chain of 103,817 deltas that can't
be broken up.
ChainLength Objects Cumulative
1: 103817 103817
2: 67332 171149
3: 57520 228669
4: 52570 281239
5: 43910 325149
6: 37520 362669
7: 35248 397917
8: 29819 427736
9: 27619 455355
10: 22656 478011
11: 21073 499084
...
>
> > + sub_size--;
> > + }
> > + target->list = list;
> > + victim->list_size -= sub_size;
> > + victim->remaining -= sub_size;
> > + }
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH 2/2] pack-objects: fix threaded load balancing
From: Jon Smirl @ 2007-12-10 5:59 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <9e4733910712092123r6987c3edua74a15890ae45a3d@mail.gmail.com>
I just deleted the section looking for identical hashes.
+ while (sub_size && list[0]->hash &&
+ list[0]->hash == list[-1]->hash) {
+ list++;
+ sub_size--;
+ }
Doing that allows the long chains to be split over the cores.
My last 5% of objects is taking over 50% of the total CPU time in the
repack. I think these objects are the ones from that 103,817 entry
chain. It is also causing the explosion in RAM consumption.
At the end I can only do 20 objects per clock second on four cores. It
takes 30 clock minutes (120 CPU minutes) to do the last 3% of objects.
Can the chains be limited to not grow over some reasonable number, say
5,000? It will make the pack a little bigger but it will help a lot
with performance.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH 2/2] pack-objects: fix threaded load balancing
From: Jon Smirl @ 2007-12-10 6:06 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <9e4733910712092159s24cf5a7cx4610f797f61b1de5@mail.gmail.com>
On 12/10/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> I just deleted the section looking for identical hashes.
>
> + while (sub_size && list[0]->hash &&
> + list[0]->hash == list[-1]->hash) {
> + list++;
> + sub_size--;
> + }
>
> Doing that allows the long chains to be split over the cores.
>
> My last 5% of objects is taking over 50% of the total CPU time in the
> repack. I think these objects are the ones from that 103,817 entry
> chain. It is also causing the explosion in RAM consumption.
>
> At the end I can only do 20 objects per clock second on four cores. It
> takes 30 clock minutes (120 CPU minutes) to do the last 3% of objects.
It's all in create_delta...
samples % symbol name
10344074 98.5961 create_delta
138010 1.3155 create_delta_index
4380 0.0417 find_deltas
2526 0.0241 patch_delta
776 0.0074 unpack_entry
>
> Can the chains be limited to not grow over some reasonable number, say
> 5,000? It will make the pack a little bigger but it will help a lot
> with performance.
>
> --
> Jon Smirl
> jonsmirl@gmail.com
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH 2/2] pack-objects: fix threaded load balancing
From: Jon Smirl @ 2007-12-10 6:19 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <9e4733910712092206o40e0c748s3796b95f637bf2b3@mail.gmail.com>
It seems to be caused by looping over those runs of 100,000 identical
hash entries.
5091699 24.6407 : for (entry = index->hash[i];
entry < index->hash[i+1]; entry++) {
5301791 25.6575 : const unsigned char
*ref = entry->ptr;
228772 1.1071 : while (data < top) {
223646 1.0823 : if (msize < 4096) {
: struct index_entry *entry;
5862 0.0284 : val ^= U[data[-RABIN_WINDOW]];
753004 3.6441 : val = ((val << 8) | *data) ^
T[val >> RABIN_SHIFT];
1232556 5.9648 : i = val & index->hash_mask;
5091699 24.6407 : for (entry = index->hash[i];
entry < index->hash[i+1]; entry++) {
5301791 25.6575 : const unsigned char
*ref = entry->ptr;
: const unsigned char *src = data;
25919 0.1254 : unsigned int ref_size
= ref_top - ref;
740077 3.5815 : if (entry->val != val)
: continue;
331 0.0016 : if (ref_size > top - src)
83804 0.4056 : ref_size = top - src;
25059 0.1213 : if (ref_size <= msize)
: break;
1269621 6.1442 : while (ref_size-- &&
*src++ == *ref)
42122 0.2038 : ref++;
14362 0.0695 : if (msize < ref - entry->ptr) {
: /* this is our
best match so far */
10452 0.0506 : msize = ref -
entry->ptr;
6882 0.0333 : moff =
entry->ptr - ref_data;
6382 0.0309 : if (msize >=
4096) /* good enough */
: break;
: }
: }
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: How-to combine several separate git repos?
From: Wink Saville @ 2007-12-10 6:36 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Alex Riesen, git
In-Reply-To: <Pine.LNX.4.64.0712092130560.5349@iabervon.org>
Daniel Barkalow wrote:
> On Sun, 9 Dec 2007, Wink Saville wrote:
>
>
> Ah, okay. I was assuming that you wanted them to maintain their original
> identities (so you'd send stuff off for each of them separately, for
> example).
>
> I think you can do what you want by doing:
>
> # Set up the new line:
> $ mkdir x; cd x
> $ git init
> $ touch README
> $ git add README
> $ git commit
>
> # Add a project "foo"
> $ git fetch ../foo refs/heads/master:refs/heads/foo
> $ git merge --no-commit foo
> $ git read-tree --reset -u HEAD
> $ git read-tree -u --prefix=foo/ foo
> $ git commit
>
> And repeat for all of the other projects.
>
> What's going on here is that you're merging in each project, except that
> you're moving all of the files from that project into a subdirectory as
> you pull in the content. The resulting repository has one recent dull
> initial commit, and then merges in each of the other projects with their
> history, with only the slight oddity that they don't go back to the same
> initial commit, and the merge renames all of the project's files.
>
> I think there may be a more obvious way of doing this (it's essentially
> how gitweb and git-gui got into the git history), but I'm not sure what it
> is, if there is one.
>
> -Daniel
> *This .sig left intentionally blank*
>
Daniel,
Worked like a charm, someday maybe I'll understand why it works:)
Wink
^ permalink raw reply
* Re: [PATCH 2/2] Add support for URLs to git-apply
From: Mike Hommey @ 2007-12-10 6:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Ericsson, git
In-Reply-To: <7vhciro4vx.fsf@gitster.siamese.dyndns.org>
On Sun, Dec 09, 2007 at 02:54:58PM -0800, Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
>
> > Mike Hommey wrote:
> >> Instead of doing several "wget -O - url | git-apply -" in a raw, you now
> >> can just git-apply url1 url2 ...
> >>
> >
> > I seriously like this idea. Combined with gitweb (or cgit), it could be
> > used as a cherry-pick from someone else's repo :)
>
> FWIW, my initial impression is that I seriously dislike this. It may be
> good if the patch were to git-am, but when git-apply rejects an
> inapplicable patch, there won't be nothing left for you to recover with
> and you need to re-download the patch anyway.
There are some usecase differences between git-apply and git-am.
Probably, this change would be good to have on both.
Mike
^ permalink raw reply
* Re: How-to combine several separate git repos?
From: Daniel Barkalow @ 2007-12-10 6:51 UTC (permalink / raw)
To: Wink Saville; +Cc: Alex Riesen, git
In-Reply-To: <475CDE73.9010505@saville.com>
On Sun, 9 Dec 2007, Wink Saville wrote:
> Daniel,
>
> Worked like a charm, someday maybe I'll understand why it works:)
I should probably explain (now that I know it's actually relevant).
> > # Add a project "foo"
> > $ git fetch ../foo refs/heads/master:refs/heads/foo
Get the history and data, as an extra branch, so we can deal with it
easily.
> > $ git merge --no-commit foo
We want to generate a merge commit, but we want to mess with it, so we use
merge to set it up, but --no-commit to not actually commit it. (The commit
below will generate a merge commit if we don't cancel stuff entirely.)
> > $ git read-tree --reset -u HEAD
Replace the index (--reset), updating the working directory (-u), with
HEAD (the commit on the local side before the merge we're in the middle
of).
> > $ git read-tree -u --prefix=foo/ foo
Read into the index, updating the working directory, "foo" (the branch we
fetched above), but with the prefix "foo/" so everything is stuffed into a
subdirectory.
> > $ git commit
And commit the result, which has the tree as constructed above (everything
from the local parent, and everything from the branch in a subdirectory),
and has the parents as for the merge we started: first parent is the local
line without the additional branch, and the second parent is the added
repository.
And git doesn't care about global structure, so the fact that this commit
is obviously just what you'd ideally like, while the history as a whole is
a bit odd (like, it doesn't have a unique start, and development didn't
start in subdirectories, and...) doesn't matter.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: How-to combine several separate git repos?
From: Wink Saville @ 2007-12-10 7:01 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Alex Riesen, git
In-Reply-To: <Pine.LNX.4.64.0712100137250.5349@iabervon.org>
Daniel Barkalow wrote:
> On Sun, 9 Dec 2007, Wink Saville wrote:
>
>
The history does look odd as I look at in gitk, but
it is there and I've expanded my knowledge a little.
Thanks again,
Wink
^ permalink raw reply
* Re: [PATCH] Interactive editor tests for commit-msg hook
From: Wincent Colaiuta @ 2007-12-10 7:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, krh
In-Reply-To: <7vwsrnmczu.fsf@gitster.siamese.dyndns.org>
El 10/12/2007, a las 4:42, Junio C Hamano escribió:
>> +# set up fake editor for interactive editing
>> +cat > fake-editor <<'EOF'
>> +#!/bin/sh
>> +cp FAKE_MSG "$1"
>> +exit 0
>> +EOF
>> +chmod +x fake-editor
>> +FAKE_EDITOR="$(pwd)/fake-editor"
>> +export FAKE_EDITOR
>
> Hmm. Why "export"?
Because I'd seen it in other tests (eg. t3404-rebase-interactive.sh),
so I just copied the style. If it's not necessary though we can lose it.
> I initially was going to say "this is just a style thing", but I
> really
> want our tests to read uniformly like this:
Ok, fixed up version will follow in a couple of minutes.
Cheers,
Wincent
^ permalink raw reply
* [PATCH 7/7] Interactive editor tests for commit-msg hook
From: Wincent Colaiuta @ 2007-12-10 7:33 UTC (permalink / raw)
To: git; +Cc: gitster, krh, Wincent Colaiuta
In-Reply-To: <7vwsrnmczu.fsf@gitster.siamese.dyndns.org>
Supplement the existing tests for the commit-msg hook (which all use
"git commit -m") with tests which use an interactive editor (no -m
switch) to ensure that all code paths get tested.
At the same time the quoting of some of the existing tests is changed
to conform to Junio's recommendations for test style (single quotes
used around the test unless there is a compelling reason not to, and
the opening quote on the same line as the test_expect and the closing
quote in column 1).
Signed-off-by: Wincent Colaiuta <win@wincent.com>
---
t/t7504-commit-msg-hook.sh | 218 +++++++++++++++++++++++++++++++++++---------
1 files changed, 175 insertions(+), 43 deletions(-)
diff --git a/t/t7504-commit-msg-hook.sh b/t/t7504-commit-msg-hook.sh
index 17aad7c..751b113 100755
--- a/t/t7504-commit-msg-hook.sh
+++ b/t/t7504-commit-msg-hook.sh
@@ -4,15 +4,49 @@ test_description='commit-msg hook'
. ./test-lib.sh
-test_expect_success "with no hook" \
- "echo 'foo' > file &&
- git add file &&
- git commit -m 'first'"
+test_expect_success 'with no hook' '
-test_expect_success "--no-verify with no hook" \
- "echo 'bar' > file &&
- git add file &&
- git commit --no-verify -m 'bar'"
+ echo "foo" > file &&
+ git add file &&
+ git commit -m "first"
+
+'
+
+# set up fake editor for interactive editing
+cat > fake-editor <<'EOF'
+#!/bin/sh
+cp FAKE_MSG "$1"
+exit 0
+EOF
+chmod +x fake-editor
+FAKE_EDITOR="$(pwd)/fake-editor"
+export FAKE_EDITOR
+
+test_expect_success 'with no hook (editor)' '
+
+ echo "more foo" >> file &&
+ git add file &&
+ echo "more foo" > FAKE_MSG &&
+ GIT_EDITOR="$FAKE_EDITOR" git commit
+
+'
+
+test_expect_success '--no-verify with no hook' '
+
+ echo "bar" > file &&
+ git add file &&
+ git commit --no-verify -m "bar"
+
+'
+
+test_expect_success '--no-verify with no hook (editor)' '
+
+ echo "more bar" > file &&
+ git add file &&
+ echo "more bar" > FAKE_MSG &&
+ GIT_EDITOR="$FAKE_EDITOR" git commit --no-verify
+
+'
# now install hook that always succeeds
HOOKDIR="$(git rev-parse --git-dir)/hooks"
@@ -24,15 +58,39 @@ exit 0
EOF
chmod +x "$HOOK"
-test_expect_success "with succeeding hook" \
- "echo 'more' >> file &&
- git add file &&
- git commit -m 'more'"
+test_expect_success 'with succeeding hook' '
-test_expect_success "--no-verify with succeeding hook" \
- "echo 'even more' >> file &&
- git add file &&
- git commit --no-verify -m 'even more'"
+ echo "more" >> file &&
+ git add file &&
+ git commit -m "more"
+
+'
+
+test_expect_success 'with succeeding hook (editor)' '
+
+ echo "more more" >> file &&
+ git add file &&
+ echo "more more" > FAKE_MSG &&
+ GIT_EDITOR="$FAKE_EDITOR" git commit
+
+'
+
+test_expect_success '--no-verify with succeeding hook' '
+
+ echo "even more" >> file &&
+ git add file &&
+ git commit --no-verify -m "even more"
+
+'
+
+test_expect_success '--no-verify with succeeding hook (editor)' '
+
+ echo "even more more" >> file &&
+ git add file &&
+ echo "even more more" > FAKE_MSG &&
+ GIT_EDITOR="$FAKE_EDITOR" git commit --no-verify
+
+'
# now a hook that fails
cat > "$HOOK" <<EOF
@@ -40,26 +98,74 @@ cat > "$HOOK" <<EOF
exit 1
EOF
-test_expect_failure "with failing hook" \
- "echo 'another' >> file &&
- git add file &&
- git commit -m 'another'"
+test_expect_failure 'with failing hook' '
+
+ echo "another" >> file &&
+ git add file &&
+ git commit -m "another"
+
+'
+
+test_expect_failure 'with failing hook (editor)' '
+
+ echo "more another" >> file &&
+ git add file &&
+ echo "more another" > FAKE_MSG &&
+ GIT_EDITOR="$FAKE_EDITOR" git commit
-test_expect_success "--no-verify with failing hook" \
- "echo 'stuff' >> file &&
- git add file &&
- git commit --no-verify -m 'stuff'"
+'
+
+test_expect_success '--no-verify with failing hook' '
+
+ echo "stuff" >> file &&
+ git add file &&
+ git commit --no-verify -m "stuff"
+
+'
+
+test_expect_success '--no-verify with failing hook (editor)' '
+
+ echo "more stuff" >> file &&
+ git add file &&
+ echo "more stuff" > FAKE_MSG &&
+ GIT_EDITOR="$FAKE_EDITOR" git commit --no-verify
+
+'
chmod -x "$HOOK"
-test_expect_success "with non-executable hook" \
- "echo 'content' >> file &&
- git add file &&
- git commit -m 'content'"
+test_expect_success 'with non-executable hook' '
+
+ echo "content" >> file &&
+ git add file &&
+ git commit -m "content"
+
+'
+
+test_expect_success 'with non-executable hook (editor)' '
+
+ echo "content again" >> file &&
+ git add file &&
+ echo "content again" > FAKE_MSG &&
+ GIT_EDITOR="$FAKE_EDITOR" git commit -m "content again"
+
+'
+
+test_expect_success '--no-verify with non-executable hook' '
+
+ echo "more content" >> file &&
+ git add file &&
+ git commit --no-verify -m "more content"
+
+'
-test_expect_success "--no-verify with non-executable hook" \
- "echo 'more content' >> file &&
- git add file &&
- git commit --no-verify -m 'more content'"
+test_expect_success '--no-verify with non-executable hook (editor)' '
+
+ echo "even more content" >> file &&
+ git add file &&
+ echo "even more content" > FAKE_MSG &&
+ GIT_EDITOR="$FAKE_EDITOR" git commit --no-verify
+
+'
# now a hook that edits the commit message
cat > "$HOOK" <<'EOF'
@@ -73,16 +179,42 @@ commit_msg_is () {
test "`git log --pretty=format:%s%b -1`" = "$1"
}
-test_expect_success "hook edits commit message" \
- "echo 'additional' >> file &&
- git add file &&
- git commit -m 'additional' &&
- commit_msg_is 'new message'"
-
-test_expect_success "hook doesn't edit commit message" \
- "echo 'plus' >> file &&
- git add file &&
- git commit --no-verify -m 'plus' &&
- commit_msg_is 'plus'"
+test_expect_success 'hook edits commit message' '
+
+ echo "additional" >> file &&
+ git add file &&
+ git commit -m "additional" &&
+ commit_msg_is "new message"
+
+'
+
+test_expect_success 'hook edits commit message (editor)' '
+
+ echo "additional content" >> file &&
+ git add file &&
+ echo "additional content" > FAKE_MSG &&
+ GIT_EDITOR="$FAKE_EDITOR" git commit &&
+ commit_msg_is "new message"
+
+'
+
+test_expect_success "hook doesn't edit commit message" '
+
+ echo "plus" >> file &&
+ git add file &&
+ git commit --no-verify -m "plus" &&
+ commit_msg_is "plus"
+
+'
+
+test_expect_success "hook doesn't edit commit message (editor)" '
+
+ echo "more plus" >> file &&
+ git add file &&
+ echo "more plus" > FAKE_MSG &&
+ GIT_EDITOR="$FAKE_EDITOR" git commit --no-verify &&
+ commit_msg_is "more plus"
+
+'
test_done
--
1.5.3.7.1116.gf11de
^ permalink raw reply related
* [PATCH] Style fixes for pre-commit hook tests
From: Wincent Colaiuta @ 2007-12-10 7:42 UTC (permalink / raw)
To: git; +Cc: gitster, Wincent Colaiuta
As pointed out by Junio on the mailing list, surrounding tests in
double quotes can lead to bugs wherein variables get substituted away,
so this isn't just style churn but important to prevent others from
looking at these tests in the future and thinking that this is "the
way" that Git tests should be written.
Signed-off-by: Wincent Colaiuta <win@wincent.com>
---
t/t7503-pre-commit-hook.sh | 90 ++++++++++++++++++++++++++++----------------
1 files changed, 57 insertions(+), 33 deletions(-)
diff --git a/t/t7503-pre-commit-hook.sh b/t/t7503-pre-commit-hook.sh
index c8097a7..d787cac 100755
--- a/t/t7503-pre-commit-hook.sh
+++ b/t/t7503-pre-commit-hook.sh
@@ -4,15 +4,21 @@ test_description='pre-commit hook'
. ./test-lib.sh
-test_expect_success "with no hook" \
- "echo 'foo' > file &&
- git add file &&
- git commit -m 'first'"
+test_expect_success 'with no hook' '
-test_expect_success "--no-verify with no hook" \
- "echo 'bar' > file &&
- git add file &&
- git commit --no-verify -m 'bar'"
+ echo "foo" > file &&
+ git add file &&
+ git commit -m "first"
+
+'
+
+test_expect_success '--no-verify with no hook' '
+
+ echo "bar" > file &&
+ git add file &&
+ git commit --no-verify -m "bar"
+
+'
# now install hook that always succeeds
HOOKDIR="$(git rev-parse --git-dir)/hooks"
@@ -24,15 +30,21 @@ exit 0
EOF
chmod +x "$HOOK"
-test_expect_success "with succeeding hook" \
- "echo 'more' >> file &&
- git add file &&
- git commit -m 'more'"
+test_expect_success 'with succeeding hook' '
+
+ echo "more" >> file &&
+ git add file &&
+ git commit -m "more"
-test_expect_success "--no-verify with succeeding hook" \
- "echo 'even more' >> file &&
- git add file &&
- git commit --no-verify -m 'even more'"
+'
+
+test_expect_success '--no-verify with succeeding hook' '
+
+ echo "even more" >> file &&
+ git add file &&
+ git commit --no-verify -m "even more"
+
+'
# now a hook that fails
cat > "$HOOK" <<EOF
@@ -40,25 +52,37 @@ cat > "$HOOK" <<EOF
exit 1
EOF
-test_expect_failure "with failing hook" \
- "echo 'another' >> file &&
- git add file &&
- git commit -m 'another'"
+test_expect_failure 'with failing hook' '
+
+ echo "another" >> file &&
+ git add file &&
+ git commit -m "another"
-test_expect_success "--no-verify with failing hook" \
- "echo 'stuff' >> file &&
- git add file &&
- git commit --no-verify -m 'stuff'"
+'
+
+test_expect_success '--no-verify with failing hook' '
+
+ echo "stuff" >> file &&
+ git add file &&
+ git commit --no-verify -m "stuff"
+
+'
chmod -x "$HOOK"
-test_expect_success "with non-executable hook" \
- "echo 'content' >> file &&
- git add file &&
- git commit -m 'content'"
-
-test_expect_success "--no-verify with non-executable hook" \
- "echo 'more content' >> file &&
- git add file &&
- git commit --no-verify -m 'more content'"
+test_expect_success 'with non-executable hook' '
+
+ echo "content" >> file &&
+ git add file &&
+ git commit -m "content"
+
+'
+
+test_expect_success '--no-verify with non-executable hook' '
+
+ echo "more content" >> file &&
+ git add file &&
+ git commit --no-verify -m "more content"
+
+'
test_done
--
1.5.3.7.1116.gf11de
^ permalink raw reply related
* Re: How-to combine several separate git repos?
From: Alex Riesen @ 2007-12-10 7:52 UTC (permalink / raw)
To: Wink Saville; +Cc: git
In-Reply-To: <475C3E25.30704@saville.com>
Wink Saville, Sun, Dec 09, 2007 20:12:37 +0100:
>> You can merge them, for example:
>>
>> $ cd project1
>> $ git merge project2/master
>>
> Starting over (restoring the original from a tar backup)
> this didn't work I get:
>
> wink@ic2d1:$ cd StateMachine
> wink@ic2d1:$ git merge ../test2/master
> ../test2/master - not something we can merge
This is *not* what I suggested. It should be:
$ git config ... (as suggested before)
$ git fetch test2
$ git merge test2/master
Here test2/master - is *NOT* a path. It is the name of the branch
where the local repository stores reference to the commit
corresponding to the master of remote repo (that is: the "master"
branch of "test2", as seen from the repository where you do the
merge).
> So the first suggestion works, but I don't want them as
> separate branches as I want to work on the simultaneously
> and they'll share common code.
Sound like the secode (merge) approach
> Another option I was thinking would work for me would be to use
> submodules. But I'm not sure submodules are ready for
> neophytes and maybe it doesn't do what I want?
They are ready for some (dunno if they'd like to be called neophytes).
I just don't think you need them (keywords on your explanations being
"share common code", understanding them as "the modules use the common
code simultaneously").
^ permalink raw reply
* [Replacement PATCH 4/4] Add support for URLs to git-apply
From: Mike Hommey @ 2007-12-10 9:06 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <1197219900-19334-4-git-send-email-mh@glandium.org>
Instead of doing several "wget -O - url | git-apply -" in a raw, you now
can just git-apply url1 url2 ...
Signed-off-by: Mike Hommey <mh@glandium.org>
---
A #ifndef NO_CURL was missing in the previous patch.
Documentation/git-apply.txt | 3 +-
builtin-apply.c | 60 ++++++++++++++++++++++++++++++++++++------
2 files changed, 53 insertions(+), 10 deletions(-)
diff --git a/Documentation/git-apply.txt b/Documentation/git-apply.txt
index bae3e7b..2d5d725 100644
--- a/Documentation/git-apply.txt
+++ b/Documentation/git-apply.txt
@@ -25,7 +25,8 @@ OPTIONS
-------
<patch>...::
The files to read patch from. '-' can be used to read
- from the standard input.
+ from the standard input. They can also be http, https or
+ ftp URLs.
--stat::
Instead of applying the patch, output diffstat for the
diff --git a/builtin-apply.c b/builtin-apply.c
index 8c8162a..28645c7 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -12,6 +12,9 @@
#include "blob.h"
#include "delta.h"
#include "builtin.h"
+#ifndef NO_CURL
+#include "http.h"
+#endif
/*
* --check turns on checking that the working tree matches the
@@ -182,12 +185,47 @@ static void say_patch_name(FILE *output, const char *pre,
#define CHUNKSIZE (8192)
#define SLOP (16)
-static void read_patch_file(struct strbuf *sb, const char *filename)
+#ifndef NO_CURL
+static int used_http;
+
+static void read_patch_url(struct strbuf *sb, const char *url)
+{
+ struct active_request_slot *slot;
+ struct slot_results results;
+
+ if (! used_http) {
+ http_init();
+ used_http = 1;
+ }
+
+ slot = get_active_slot();
+ slot->results = &results;
+ curl_easy_setopt(slot->curl, CURLOPT_FILE, sb);
+ curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, fwrite_buffer);
+ curl_easy_setopt(slot->curl, CURLOPT_URL, url);
+ curl_easy_setopt(slot->curl, CURLOPT_HTTPHEADER, NULL);
+
+ if (start_active_slot(slot)) {
+ run_active_slot(slot);
+ if (results.curl_result != CURLE_OK)
+ die("git-apply: could not open %s", url);
+ }
+}
+#endif
+
+static void read_patch(struct strbuf *sb, const char *filename)
{
int fd;
if (!strcmp(filename, "-")) {
fd = 0;
+#ifndef NO_CURL
+ } else if (!strncmp(filename, "http://", 7) ||
+ !strncmp(filename, "https://", 8) ||
+ !strncmp(filename, "ftp://", 6)) {
+ read_patch_url(sb, filename);
+ return;
+#endif
} else {
fd = open(filename, O_RDONLY);
if (fd < 0)
@@ -199,13 +237,6 @@ static void read_patch_file(struct strbuf *sb, const char *filename)
die("git-apply: read returned %s", strerror(errno));
close(fd);
- /*
- * Make sure that we have some slop in the buffer
- * so that we can do speculative "memcmp" etc, and
- * see to it that it is NUL-filled.
- */
- strbuf_grow(sb, SLOP);
- memset(sb->buf + sb->len, 0, SLOP);
}
static unsigned long linelen(const char *buffer, unsigned long size)
@@ -2726,7 +2757,14 @@ static int apply_patch(const char *filename, int inaccurate_eof)
strbuf_init(&buf, 0);
patch_input_file = filename;
- read_patch_file(&buf, filename);
+ read_patch(&buf, filename);
+ /*
+ * Make sure that we have some slop in the buffer
+ * so that we can do speculative "memcmp" etc, and
+ * see to it that it is NUL-filled.
+ */
+ strbuf_grow(&buf, SLOP);
+ memset(buf.buf + buf.len, 0, SLOP);
offset = 0;
while (offset < buf.len) {
struct patch *patch;
@@ -2926,6 +2964,10 @@ int cmd_apply(int argc, const char **argv, const char *unused_prefix)
set_default_whitespace_mode(whitespace_option);
errs |= apply_patch(arg, inaccurate_eof);
}
+#ifndef NO_CURL
+ if (used_http)
+ http_cleanup();
+#endif
set_default_whitespace_mode(whitespace_option);
if (read_stdin)
errs |= apply_patch("-", inaccurate_eof);
--
1.5.3.7.1148.gcfe7
^ permalink raw reply related
* Re: [PATCH] Restore ls-remote reference pattern matching
From: Eyvind Bernhardsen @ 2007-12-10 9:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sergey Vlasov, git
In-Reply-To: <7vtzmrobrl.fsf@gitster.siamese.dyndns.org>
On 9. des. 2007, at 21.26, Junio C Hamano wrote:
> Sergey Vlasov <vsu@altlinux.ru> writes:
>
>> This still does not match the behavior of the old shell
>> implementation
>> completely - because $pat was not quoted, shell pattern characters in
>> $pat worked, and things like "git ls-remote . 'refs/heads/
>> something--*'"
>> were possible (and used in some of my scripts), so a full fnmatch()
>> call is still needed.
>
> Sigh...
This patch makes ls-remote work as expected for me.
--
Eyvind
^ permalink raw reply
* [PATCH] Don't cache DESTDIR in perl/perl.mak.
From: Gerrit Pape @ 2007-12-10 9:31 UTC (permalink / raw)
To: git, Junio C Hamano
DESTDIR is supposed to be overridden on 'make install' after doing
'make'. Have the automatically generated perl/perl.mak not cache the
value of DESTDIR to support that for the perl/ subdirectory also.
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
Makefile | 2 +-
perl/Makefile.PL | 6 +-----
2 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/Makefile b/Makefile
index 4cdb84b..3615be0 100644
--- a/Makefile
+++ b/Makefile
@@ -1025,7 +1025,7 @@ install: all
$(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexecdir_SQ)'
$(INSTALL) git$X '$(DESTDIR_SQ)$(bindir_SQ)'
$(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' install
- $(MAKE) -C perl prefix='$(prefix_SQ)' install
+ $(MAKE) -C perl prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' install
ifndef NO_TCLTK
$(MAKE) -C gitk-git install
$(MAKE) -C git-gui install
diff --git a/perl/Makefile.PL b/perl/Makefile.PL
index 6aecd89..320253e 100644
--- a/perl/Makefile.PL
+++ b/perl/Makefile.PL
@@ -17,9 +17,6 @@ if ($@ || $Error::VERSION < 0.15009) {
$pm{'private-Error.pm'} = '$(INST_LIBDIR)/Error.pm';
}
-my %extra;
-$extra{DESTDIR} = $ENV{DESTDIR} if $ENV{DESTDIR};
-
# redirect stdout, otherwise the message "Writing perl.mak for Git"
# disrupts the output for the target 'instlibdir'
open STDOUT, ">&STDERR";
@@ -29,6 +26,5 @@ WriteMakefile(
VERSION_FROM => 'Git.pm',
PM => \%pm,
MAKEFILE => 'perl.mak',
- INSTALLSITEMAN3DIR => '$(SITEPREFIX)/share/man/man3',
- %extra
+ INSTALLSITEMAN3DIR => '$(SITEPREFIX)/share/man/man3'
);
--
1.5.3.4
^ permalink raw reply related
* Re: Git and GCC
From: Gabriel Paubert @ 2007-12-10 9:54 UTC (permalink / raw)
To: Harvey Harrison
Cc: Linus Torvalds, Jeff King, Nicolas Pitre, Jon Smirl,
Daniel Berlin, David Miller, ismail, gcc, git
In-Reply-To: <1197074839.22471.34.camel@brick>
On Fri, Dec 07, 2007 at 04:47:19PM -0800, Harvey Harrison wrote:
> Some interesting stats from the highly packed gcc repo. The long chain
> lengths very quickly tail off. Over 60% of the objects have a chain
> length of 20 or less. If anyone wants the full list let me know. I
> also have included a few other interesting points, the git default
> depth of 50, my initial guess of 100 and every 10% in the cumulative
> distribution from 60-100%.
>
> This shows the git default of 50 really isn't that bad, and after
> about 100 it really starts to get sparse.
Do you have a way to know which files have the longest chains?
I have a suspiscion that the ChangeLog* files are among them,
not only because they are, almost without exception, only modified
by prepending text to the previous version (and a fairly small amount
compared to the size of the file), and therefore the diff is simple
(a single hunk) so that the limit on chain depth is probably what
causes a new copy to be created.
Besides that these files grow quite large and become some of the
largest files in the tree, and at least one of them is changed
for every commit. This leads again to many versions of fairly
large files.
If this guess is right, this implies that most of the size gains
from longer chains comes from having less copies of the ChangeLog*
files. From a performance point of view, it is rather favourable
since the differences are simple. This would also explain why
the window parameter has little effect.
Regards,
Gabriel
^ permalink raw reply
* Re: [PATCH] Restore ls-remote reference pattern matching
From: Junio C Hamano @ 2007-12-10 9:56 UTC (permalink / raw)
To: Eyvind Bernhardsen; +Cc: Sergey Vlasov, git
In-Reply-To: <5C669468-71F1-4E28-9E15-1EAA4893135F@orakel.ntnu.no>
Eyvind Bernhardsen <eyvind-git@orakel.ntnu.no> writes:
> This patch makes ls-remote work as expected for me.
Thanks, the patch is queued for master.
^ permalink raw reply
* Re: Git and GCC
From: David Miller @ 2007-12-10 9:57 UTC (permalink / raw)
To: jonsmirl; +Cc: peff, nico, dberlin, harvey.harrison, ismail, gcc, git
In-Reply-To: <20071207.045329.204650714.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Fri, 07 Dec 2007 04:53:29 -0800 (PST)
> I should run oprofile...
While doing the initial object counting, most of the time is spent in
lookup_object(), memcmp() (via hashcmp()), and inflate(). I tried to
see if I could do some tricks on sparc with the hashcmp() but the sha1
pointers are very often not even 4 byte aligned.
I suspect lookup_object() could be improved if it didn't use a hash
table without chaining, but I can see why 'struct object' size is a
concern and thus why things are done the way they are.
samples % app name symbol name
504 13.7517 libc-2.6.1.so memcmp
386 10.5321 libz.so.1.2.3.3 inflate
288 7.8581 git lookup_object
248 6.7667 libz.so.1.2.3.3 inflate_fast
201 5.4843 libz.so.1.2.3.3 inflate_table
175 4.7749 git decode_tree_entry
...
Deltifying is %94 consumed by create_delta(), the rest is completely
in the noise.
samples % app name symbol name
10581 94.8373 git create_delta
181 1.6223 git create_delta_index
72 0.6453 git prepare_pack
55 0.4930 libc-2.6.1.so loop
34 0.3047 libz.so.1.2.3.3 inflate_fast
33 0.2958 libc-2.6.1.so _int_malloc
22 0.1972 libshadow.so shadowUpdatePacked
21 0.1882 libc-2.6.1.so _int_free
19 0.1703 libc-2.6.1.so malloc
...
^ permalink raw reply
* Re: [PATCH 0/3] git-help -i (info): finishing touches
From: Junio C Hamano @ 2007-12-10 10:06 UTC (permalink / raw)
To: git; +Cc: David Kastrup, Christian Couder
In-Reply-To: <1197279969-10613-1-git-send-email-gitster@pobox.com>
Junio C Hamano <gitster@pobox.com> writes:
> This series attempts to add finishing touches to "git help -i" (info)
> support.
Side note. The patches I sent out are queued for 'next', and I'll push
it out shortly. I am hoping, after this series graduates to 'master',
to be able to tag v1.5.4-rc0 and declare 'master' as feature complete
for now, and see everybody move to bugfix-only mode.
Currently, the man pages are sorted in $(wildcard) order in the main
menu, but I think:
* make git(7) the first node after Top;
* order the commands in the main @menu to follow the command-list.txt
categorization, and show Porcelains and then Plumbings, just like
git(7) does;
would make the organization better, but I did not do that tonight. I'd
leave that as an exercise to interested readers.
I also briefly considered rolling the manual pages into git.info which
is built from the user manual, but I decided against it for now. I
think the current organization of the user manual is good as a
standalone document, and making the manual set as its appendix is
possible but not necessary. I can be persuaded differently, though.
^ permalink raw reply
* Re: Better value for chunk_size when threaded
From: Andreas Ericsson @ 2007-12-10 10:26 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jon Smirl, Git Mailing List, Junio C Hamano
In-Reply-To: <alpine.LFD.0.99999.0712062014060.555@xanadu.home>
Nicolas Pitre wrote:
> On Thu, 6 Dec 2007, Jon Smirl wrote:
>
>> I tried some various ideas out for chunk_size and the best strategy I
>> found was to simply set it to a constant. How does 20,000 work on
>> other CPUs?
>
> That depends on the object size. If you have a repo with big objects
> but only 1000 of them for example, then the constant doesn't work.
>
> Ideally I'd opt for a value that tend towards around 5 seconds worth of
> work per segment, or something like that. Maybe using the actual
> objects size could be another way.
>
>> I'd turn on default threaded support with this change. With threads=1
>> versus non-threaded there is no appreciable difference in the time.
>
> Would need a way to determine pthreads availability from Makefile.
>
>> Is there an API to ask how many CPUs are in the system? It would be
>> nice to default the number of threads equal to the number of CPUs and
>> only use pack.threads=X to override.
>
> If there is one besides futzing with /proc/cpuinfo I'd like to know
> about it. Bonus points if it is portable.
>
Here is such a one. I've sent it before, using git-send-email, but that
one doesn't seem to work too well for all list-members, probably because
my own laptop appears to be the original SMTP-server and its name can't
be looked up. Sorry for inlining it here instead of sending it as a mail
on its own, but I have absolutely no idea how to get git-send-email to
do ldap authentication and connect to our tls-enabled smtp-server
without using /usr/bin/sendmail and adding my laptop as originating
smtp-server.
This patch replaces the one I sent earlier and *should* work on
everything from Irix and AIX to Linux, Windows and every other
posixish system. It passes all tests, both with and without
THREADED_DELTA_SEARCH, and causes our weekly repack of our
mother-ship repos to run roughly 4 times as fast (4 cores, no
previous thread config).
Extract with
sed -n -e /^##SEDMEHERE##/,/##TOHERE##/p -e /^##/d
##SEDMEHERE##
From ddf08303bd7962be385abbd5e964455a90ed6055 Mon Sep 17 00:00:00 2001
From: Andreas Ericsson <ae@op5.se>
Date: Thu, 6 Dec 2007 22:09:27 +0100
Subject: [PATCH] pack-objects: Add runtime detection of number of CPU's
Packing objects can be done in parallell nowadays, but
it's only done if the config option pack.threads is set
to a value above 1. Because of that, the code-path used
is sometimes not the most optimal one.
This patch adds a routine to detect the number of active
CPU's at runtime, which should provide a better default
and activate the (hopefully) better codepath more often.
The code is a rework of "numcpus.c", written by one
Philip Willoughby <pgw99@doc.ic.ac.uk>. numcpus.c is in
the public domain and can presently be downloaded from
http://csgsoft.doc.ic.ac.uk/numcpus/
Signed-off-by: Andreas Ericsson <ae@op5.se>
---
builtin-pack-objects.c | 49 +++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 48 insertions(+), 1 deletions(-)
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 250dc56..ccf5198 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -17,6 +17,13 @@
#ifdef THREADED_DELTA_SEARCH
#include <pthread.h>
+# ifdef _WIN32
+# define WIN32_LEAN_AND_MEAN
+# include <windows.h>
+# endif
+# if defined(hpux) || defined(__hpux) || defined(_hpux)
+# include <sys/pstat.h>
+# endif
#endif
static const char pack_usage[] = "\
@@ -70,7 +77,7 @@ static int progress = 1;
static int window = 10;
static uint32_t pack_size_limit;
static int depth = 50;
-static int delta_search_threads = 1;
+static long delta_search_threads;
static int pack_to_stdout;
static int num_preferred_base;
static struct progress *progress_state;
@@ -2004,6 +2011,44 @@ static int adjust_perm(const char *path, mode_t mode)
return adjust_shared_perm(path);
}
+/*
+ * this is a disgusting nest of #ifdef's. I just love
+ * non-portable interfaces. By doing it in two steps
+ * we can get the function to be fairly coherent anyways
+ */
+#ifndef _SC_NPROCESSORS_ONLN
+# ifdef _SC_NPROC_ONLN
+# define _SC_NPROCESSORS_ONLN _SC_NPROC_ONLN
+# elif defined _SC_CRAY_NCPU
+# define _SC_NPROCESSORS_ONLN _SC_CRAY_NCPU
+# endif
+#endif
+static long active_cpu_count(void)
+{
+#ifdef THREADED_DELTA_SEARCH
+# ifdef _SC_NPROCESSORS_ONLN
+ long ncpus;
+
+ if ((ncpus = (long)sysconf(_SC_NPROCESSORS_ONLN)) > 0)
+ return ncpus;
+# else
+# ifdef _WIN32
+ SYSTEM_INFO info;
+ GetSystemInfo(&info);
+
+ return (long)info.dwNumberOfProcessors;
+# endif /* _WIN32 */
+# if defined(hpux) || defined(__hpux) || defined(_hpux)
+ struct pst_dynamic psd;
+
+ if (!pstat_getdynamic(&psd, sizeof(psd), (size_t)1, 0))
+ return (long)psd.psd_proc_cnt;
+# endif /* hpux */
+# endif /* _SC_NPROCESSORS_ONLN */
+#endif /* THREADED_DELTA_SEARCH */
+ return 1;
+}
+
int cmd_pack_objects(int argc, const char **argv, const char *prefix)
{
int use_internal_rev_list = 0;
@@ -2019,6 +2064,8 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
rp_av[1] = "--objects"; /* --thin will make it --objects-edge */
rp_ac = 2;
+ delta_search_threads = active_cpu_count();
+
git_config(git_pack_config);
if (!pack_compression_seen && core_compression_seen)
pack_compression_level = core_compression_level;
--
1.5.3.6.2031.gf9bdc
##TOHERE##
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply related
* [PATCH] Add git-browse-help to gitignore
From: Jeff King @ 2007-12-10 10:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Christian Couder, git
Signed-off-by: Jeff King <peff@peff.net>
---
.gitignore | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/.gitignore b/.gitignore
index bac60ce..5eaba41 100644
--- a/.gitignore
+++ b/.gitignore
@@ -12,6 +12,7 @@ git-archive
git-bisect
git-blame
git-branch
+git-browse-help
git-bundle
git-cat-file
git-check-attr
--
1.5.3.7.2227.gf64a8
^ permalink raw reply related
* Re: git-svn init from Avogadro SVN repo - deleted files showing
From: Peter Baumann @ 2007-12-10 10:42 UTC (permalink / raw)
To: Marcus D. Hanwell; +Cc: Eric Wong, git
In-Reply-To: <475C8748.6000005@cryos.net>
On Sun, Dec 09, 2007 at 07:24:40PM -0500, Marcus D. Hanwell wrote:
> Hi,
>
> I am quite new to git and git-svn but have been using both for my
> development work recently. I imported the Avogadro subversion repository
> (hosted on Sourceforge) using the following commands,
>
> git svn init -t tags -b branches -T trunk
> https://avogadro.svn.sourceforge.net/svnroot/avogadro
>
> git svn fetch
>
>
> The files avogadro.pro and README in the trunk/ directory appear in my
> imported git repository but not in Avogadro subversion trunk. We also had
> trunk/src/ and all its files/subdirectories appearing in the git checkout
> but not in subversion trunk. We deleted this using git and git svn which
> removed it from the git checkouts too after r858.
>
> I have been talking to Peter who confirmed this and pointed out that the
> repo was reorganised several times in the past. Please CC me on replies as
> I am not on the list. There is a copy of my git repo at
> http://platinum.cryos.net/avogadro.git/ if you would rather skip the
> import. Other than that everything has been working great. It would be good
> to get rid of this bug if possible. Let me know if there is anything else I
> can do to help.
>
[ Eric Cc'ed, as the author of git-svn ]
I can confirm that this looks like an import problem.
(e.g see svn log -v -r33:78 https://avogadro.svn.sourceforge.net/svnroot/avogadro)
I did my analysis on the file /trunk/avogadro.pro, because the error
happens really early in the history so could just import up to revision 76
to see what goes wrong. (The file gets never deleted in the import, as it
should be!)
trunk/avogadro.pro is added here:
------------------------------------------------------------------------
r33 | dcurtis3 | 2006-08-21 07:34:10 +0200 (Mon, 21 Aug 2006) | 3 lines
Changed paths:
A /trunk/avogadro.pro
Does a recursive build.
Here the refactoring starts (a new directory not tracked by git is added):
------------------------------------------------------------------------
r66 | dcurtis3 | 2007-01-03 06:42:45 +0100 (Wed, 03 Jan 2007) | 3 lines
Changed paths:
A /avogadro
Making room for libavogadro.
/branches is moved to /avogadro/branches
------------------------------------------------------------------------
r67 | dcurtis3 | 2007-01-03 06:47:11 +0100 (Wed, 03 Jan 2007) | 3 lines
Changed paths:
A /avogadro/branches (from /branches:66)
D /branches
Making room for libavogadro
ERROR HAPPENS HERE:
====================
/trunk and /tags are moved, too.
(/trunk/avogadro.pro becomes /avogadro/trunk/avogadro.pro):
------------------------------------------------------------------------
r68 | dcurtis3 | 2007-01-03 06:47:34 +0100 (Wed, 03 Jan 2007) | 3 lines
Changed paths:
A /avogadro/tags (from /tags:66)
A /avogadro/trunk (from /trunk:66)
D /tags
D /trunk
Making room for libavogadro.
The above delete/move of trunk isn't recorded anywhere in the git svn import.
'git-svn find-rev r66' doesn't produce any output!
And later git-svn thinks that /trunk and all its files are still there, so
e.g. /trunk/avogadro.pro stays in the repo forever.
-Peter
This is just for consistency here and for anyone interested in further
analyses.
Here is the rest of the import analyses I've done. Look how "interesting" the
repo is and how many times the files are moved.
/libavogadro is added
------------------------------------------------------------------------
r69 | dcurtis3 | 2007-01-03 06:50:58 +0100 (Wed, 03 Jan 2007) | 3 lines
Changed paths:
A /libavogadro
A /libavogadro/CMakeLists.txt
A /libavogadro/FindOpenBabel.cmake
A /libavogadro/src
A /libavogadro/src/CMakeLists.txt
A /libavogadro/src/color.cpp
A /libavogadro/src/color.h
A /libavogadro/src/engine.h
A /libavogadro/src/engines
A /libavogadro/src/engines/CMakeLists.txt
A /libavogadro/src/engines/ResidueSphereEngine.cpp
A /libavogadro/src/engines/ResidueSphereEngine.h
A /libavogadro/src/engines/SphereEngine.cpp
A /libavogadro/src/engines/SphereEngine.h
A /libavogadro/src/engines/StickEngine.cpp
A /libavogadro/src/engines/StickEngine.h
A /libavogadro/src/engines/WireframeEngine.cpp
A /libavogadro/src/engines/WireframeEngine.h
A /libavogadro/src/engines/bsengine.cpp
A /libavogadro/src/engines/bsengine.h
A /libavogadro/src/engines/vertexarray.cpp
A /libavogadro/src/engines/vertexarray.h
A /libavogadro/src/glwidget.cpp
A /libavogadro/src/glwidget.h
A /libavogadro/src/primitives.cpp
A /libavogadro/src/primitives.h
Added libavogadro.
Create /libavogadro/{trunk,branches,tags} and move anything below the
former /libavogadro into /libavogadro/trunk
------------------------------------------------------------------------
r70 | dcurtis3 | 2007-01-03 06:53:13 +0100 (Wed, 03 Jan 2007) | 3 lines
Changed paths:
D /libavogadro/CMakeLists.txt
D /libavogadro/FindOpenBabel.cmake
A /libavogadro/branches
D /libavogadro/src
A /libavogadro/tags
A /libavogadro/trunk
A /libavogadro/trunk/CMakeLists.txt (from /libavogadro/CMakeLists.txt:69)
A /libavogadro/trunk/FindOpenBabel.cmake (from /libavogadro/FindOpenBabel.cmake:69)
A /libavogadro/trunk/src (from /libavogadro/src:69)
Putting in trunk / branches / tags.
------------------------------------------------------------------------
r72 | dcurtis3 | 2007-01-03 08:55:32 +0100 (Wed, 03 Jan 2007) | 3 lines
Changed paths:
A /avogadro/trunk/CMakeLists.txt
A /avogadro/trunk/FindAvogadro.cmake
A /avogadro/trunk/FindOpenBabel.cmake
D /avogadro/trunk/src/Engine.h
D /avogadro/trunk/src/GLWidget.cpp
D /avogadro/trunk/src/GLWidget.h
D /avogadro/trunk/src/MainWindow.cpp
D /avogadro/trunk/src/MainWindow.h
D /avogadro/trunk/src/Primitives.cpp
D /avogadro/trunk/src/Primitives.h
D /avogadro/trunk/src/Renderer.h
D /avogadro/trunk/src/Tool.cpp
D /avogadro/trunk/src/Tool.h
D /avogadro/trunk/src/Views.cpp
D /avogadro/trunk/src/Views.h
D /avogadro/trunk/src/color.cpp
D /avogadro/trunk/src/color.h
D /avogadro/trunk/src/engines
M /avogadro/trunk/src/main.cpp
A /avogadro/trunk/src/mainwindow.cpp (from /avogadro/trunk/src/MainWindow.cpp:70)
A /avogadro/trunk/src/mainwindow.h (from /avogadro/trunk/src/MainWindow.h:70)
A /avogadro/trunk/src/tool.cpp (from /avogadro/trunk/src/Tool.cpp:70)
A /avogadro/trunk/src/tool.h (from /avogadro/trunk/src/Tool.h:70)
A /avogadro/trunk/untitled01.gpr
Now uses libavogadro. Starting to think we should package this a
little different.
Renamed /libavogadro to /avogadro-lib
------------------------------------------------------------------------
r73 | dcurtis3 | 2007-01-03 16:48:02 +0100 (Wed, 03 Jan 2007) | 3 lines
Changed paths:
A /avogadro-lib (from /libavogadro:72)
D /libavogadro
Refactor
mv /avogadro/trunk/avogadro.pro /trunk/avogadro/avogadro.pro
------------------------------------------------------------------------
r75 | dcurtis3 | 2007-01-03 20:49:35 +0100 (Wed, 03 Jan 2007) | 2 lines
Changed paths:
D /avogadro
D /avogadro-lib
A /branches
A /tags
A /trunk
A /trunk/avogadro (from /avogadro/trunk:74)
A /trunk/libavogadro (from /avogadro-lib/trunk:74)
Moving things around. Conforming to a more KDE-like layout in SVN.
I'm going nuts. SOrry
^ permalink raw reply
* Re: [PATCH 2/2] Add support for URLs to git-apply
From: Johannes Schindelin @ 2007-12-10 11:16 UTC (permalink / raw)
To: Mike Hommey; +Cc: Junio C Hamano, Andreas Ericsson, git
In-Reply-To: <20071210064659.GA4148@glandium.org>
Hi,
On Mon, 10 Dec 2007, Mike Hommey wrote:
> On Sun, Dec 09, 2007 at 02:54:58PM -0800, Junio C Hamano wrote:
> > Andreas Ericsson <ae@op5.se> writes:
> >
> > > Mike Hommey wrote:
> > >> Instead of doing several "wget -O - url | git-apply -" in a raw,
> > >> you now can just git-apply url1 url2 ...
> > >>
> > >
> > > I seriously like this idea. Combined with gitweb (or cgit), it could
> > > be used as a cherry-pick from someone else's repo :)
> >
> > FWIW, my initial impression is that I seriously dislike this. It may
> > be good if the patch were to git-am, but when git-apply rejects an
> > inapplicable patch, there won't be nothing left for you to recover
> > with and you need to re-download the patch anyway.
>
> There are some usecase differences between git-apply and git-am.
> Probably, this change would be good to have on both.
But what about Junio's comments about a failed patch? You really want to
hammer that poor webserver?
My first thought when seeing your patch was: this would give us a chance
to "clone" via gitweb. And while doing so, all but kill those webservers.
So I thought it was wrong.
When Junio mentioned git-am it was obvious to me that this is the "right"
solution.
I mean, we go out of our way to be nice to the servers, putting more load
onto the clients, because there are many clients, but only one server
(which is unfair).
Please address these issues before further arguing that both apply and am
should learn about URLs.
Ciao,
Dscho
^ permalink raw reply
* [ANNOUNCE] Stacked GIT 0.14
From: Catalin Marinas @ 2007-12-10 11:40 UTC (permalink / raw)
To: Git Mailing List, Linux Kernel Mailing List
Stacked GIT 0.14 release is available from http://www.procode.org/stgit/.
StGIT is a Python application providing similar functionality to Quilt
(i.e. pushing/popping patches to/from a stack) on top of GIT. These
operations are performed using GIT commands and the patches are stored
as GIT commit objects, allowing easy merging of the StGIT patches into
other repositories using standard GIT functionality.
This release requires at least Python 2.4 and GIT 1.5.2.
The main features in this release:
* Support for correctly running StGIT in subdirectories
* 'repair' command for fixing an StGIT repository modified by GIT
commands such as 'commit', 'pull', 'merge' or 'rebase'
* 'edit' command for editing both the patch description and diff
* Support for SMTP over TLS
* Support for MIME multipart e-mail templates
* '--attach' option to the 'mail' command to send a patch attached
rather than inline
* Diff statistics and shortlog added to the cover e-mail template
* '--sign/ack' options to the 'import' and 'new' commands
* '--number' to the 'log' command for limiting the output
* Support for binary files in patches
* Support for detached HEAD
* Refactoring of some modules with better support for debugging
* Many bug-fixes
Acknowledgements (many thanks to all the people who contributed code,
reported bugs or made suggestions):
Karl Hasselström (73):
Teach StGIT about core.excludesfile
New test: make sure that popping doesn't change patch order
Verify patch status during the test
Add an --smtp-server commandline option to "stg mail"
Test that all branch config information is renamed
Rename all config sections of a branch
New test: make sure that StGIT can handle packed refs
Make use of the get_patch() utility function
Don't touch ref files manually
Don't use test_expect_failure when more than one thing could fail
Don't write None to the conf file
Replace "git repo-config" with "git config" in help texts
Compile regexp just once
Refactor output handling to break circular dependency
Refactor subprocess creation
Assert that the argument to Run is a sequence of strings
Add optional logging of subprocess execution
Write warnings and errors to stderr if not on a terminal
Don't fail just because a subprocess wrote stuff to stderr
Let "stg status" ignore empty directories
Allow "stg add" when we have no stack
Test "stg status" more thoroughly
Use subprocess.Popen to call git executables
Use the builtin set() instead of sets.Set()
Discard stderr when determining if a patch is already applied
Add the any() and all() utility functions from Python 2.5
Add --sign and --ack options to "stg import"
Add diffstat of whole patch series to cover mail
Add shortlog of patch series to cover mail
Include summary of added/deleted files in diffstat
It doesn't make sense to sink below an unapplied patch
Don't special-case the "master" branch during branch delete
Don't try to delete the branch twice
Properly remove all config for a deleted branch
Add simple test for "stg branch --delete"
New test: make sure tha we can run "stg help"
Make sure that the output of "stg status" is sorted
New policy: Only use test_expect_failure for broken tests
Make Run available in stack.py
Teach "stg assimilate" to repair patch reachability
Test the new powers of "stg assimilate"
Let "stg assimilate" handle missing patches
Add --ack/--sign options to "stg new"
New test: "stg pop --keep"
Fix up the help text for "stg edit"
Don't split long and short description in "stg edit"
Make a common superclass for all StGit exceptions
Simplify debug level error checking
Discard stderr output from git-rev-parse
Remove the --force flag to "stg rebase" and "stg pull"
Infrastructure for current directory handling
New test: Try "stg push" in a subdirectory
Make "stg push" subdirectory safe
New test: try "stg refresh" in a subdirectory
Make "stg refresh" subdirectory safe
Allow caller to customize title of error/warning message
Use our nice message printout wrapping system
Properly detect that HEAD is detached
Refactor crt_series creation
Don't have a global crt_series in stgit.commans.common
Fix error message generation
New test: "stg diff"
Simple test for "stg clean"
Cogito is deprecated, so don't point to it
Let some commands work with detached HEAD
Rename "stg assimilate" to "stg repair"
stg repair: Patchify non-patch commits between patches
Push and pop don't have --to flags anymore
Add missing switch to "stg uncommit" usage line
Make "stg repair" help text more helpful
Fix bashism
Discard exitcode of subprocess in a better way
Don't use test_expect_failure for tests that are supposed to work
Catalin Marinas (36):
Allow 'import' to apply empty patches
Make the maximum patch name length configurable
Add the '--exclusive' option to 'uncommit'
Add patch editing command
Add 'edit' to the patchcommands list
Print 'updating patch' earlier in 'edit'
Allow the rebase command to be defined
Fix the rebasing with an external command
Fix assertion in patch creation
"stg pop --keep" fails because of git-apply --index (bug #8972)
Do not raise an exception if no FETCH_HEAD
Allow StGIT commands to run correctly in subdirectories
Allow "branch --create" to be given a tag id
Fix more commands to run correctly in subdirectories
Allow the diff showing in the log command if patch modified by edit
'stg pop --keep' doesn't update the index
Execute the 'git ...' rather than 'git-...'
Keep the patch log when import --replace deletes patches
Improve the t1205 test for push
Make Series.refresh_patch automatically save the undo information
Check for disappeared newborn files in git.tree_status (bug #8516)
Correctly identify the parent branch (bug #10014)
Clean-up if the branch creation fails (bug #10015)
Allow multipart templates for patch e-mails (bug #10237)
Add a test for the 'mail --attach' command
Check the minimum required versions of GIT and Python (bug #10218)
git.pretty_commit() re-implemented with "git show" (bug #10018)
Allow 'show' and 'id' to work on non-StGIT branches (bug #10011)
Change the file timestamp in 'resolved --reset' (bug #10017)
Add the 'log --number' option to limit the output
Ignore the gitk exit code in 'stg log -g' (bug #10010)
Some clean-up of the branch manipulation commands
Make sure the refid given to 'mail' has the angle brackets
Allow only certain gitk exit codes as valid
Better handling of binary files (bug #8495)
Release 0.14
David Kågedal (15):
Don't print unnecessary backtraces when testing
Fixed indeterminism in t2102-pull-policy-rebase
Add basic test for stg status
Cleanup tree_status and use -z
Add some more tests of "stg status" output
Clear up semantics of tree_status
Moved that status function to the status command file
Split Series.push_patch in two
Remove dead code from push_empty_patch
Refactor Series.push_patch
Clean up Series.refresh_patch
Add a 'bottom' parameter to Series.refresh_patch and use it
Clear up the semantics of Series.new_patch
Refactor Series.new_patch
Added test case for stg refresh
Yann Dirson (9):
Improve stg-fold-files-from doc.
New contrib scripts: stg-dispatch and stg-show.
Add -O flag to stg-fold-files-from.
Add a no-act flag to stg-dispatch and stg-fold-file-from.
Provide file completion for add/resolved/refresh based on status.
Fixed completion function hardcoding .git/.
Include contrib scripts in the release tarball.
Better diagnostic for wrong branch configuration.
stg-gitk: allow passing args to gitk; add --help.
Pavel Roskin (7):
Add support for SMTP over Transport Layer Security (TLS)
Ask for SMTP password if it's not provided
Use --force to overwrite python files
Fix refresh -es
git.__remotes_from_dir() should only return lists
Set GIT_TEMPLATE_DIR in the testsuite, like it's done in git
Support tags in uncommit - use git_id instead of rev_parse
--
Catalin
^ permalink raw reply
* Re: git-svn init from Avogadro SVN repo - deleted files showing
From: Peter Baumann @ 2007-12-10 11:40 UTC (permalink / raw)
To: Marcus D. Hanwell; +Cc: Eric Wong, git
In-Reply-To: <20071210104235.GA7521@xp.machine.xx>
On Mon, Dec 10, 2007 at 11:42:35AM +0100, Peter Baumann wrote:
> On Sun, Dec 09, 2007 at 07:24:40PM -0500, Marcus D. Hanwell wrote:
> > Hi,
> >
> > I am quite new to git and git-svn but have been using both for my
> > development work recently. I imported the Avogadro subversion repository
> > (hosted on Sourceforge) using the following commands,
> >
> > git svn init -t tags -b branches -T trunk
> > https://avogadro.svn.sourceforge.net/svnroot/avogadro
> >
> > git svn fetch
> >
> >
> > The files avogadro.pro and README in the trunk/ directory appear in my
> > imported git repository but not in Avogadro subversion trunk. We also had
> > trunk/src/ and all its files/subdirectories appearing in the git checkout
> > but not in subversion trunk. We deleted this using git and git svn which
> > removed it from the git checkouts too after r858.
> >
> > I have been talking to Peter who confirmed this and pointed out that the
> > repo was reorganised several times in the past. Please CC me on replies as
> > I am not on the list. There is a copy of my git repo at
> > http://platinum.cryos.net/avogadro.git/ if you would rather skip the
> > import. Other than that everything has been working great. It would be good
> > to get rid of this bug if possible. Let me know if there is anything else I
> > can do to help.
> >
>
> [ Eric Cc'ed, as the author of git-svn ]
>
> I can confirm that this looks like an import problem.
> (e.g see svn log -v -r33:78 https://avogadro.svn.sourceforge.net/svnroot/avogadro)
>
> I did my analysis on the file /trunk/avogadro.pro, because the error
> happens really early in the history so could just import up to revision 76
> to see what goes wrong. (The file gets never deleted in the import, as it
> should be!)
>
>
>
> trunk/avogadro.pro is added here:
>
> ------------------------------------------------------------------------
> r33 | dcurtis3 | 2006-08-21 07:34:10 +0200 (Mon, 21 Aug 2006) | 3 lines
> Changed paths:
> A /trunk/avogadro.pro
>
> Does a recursive build.
>
>
> Here the refactoring starts (a new directory not tracked by git is added):
> ------------------------------------------------------------------------
> r66 | dcurtis3 | 2007-01-03 06:42:45 +0100 (Wed, 03 Jan 2007) | 3 lines
> Changed paths:
> A /avogadro
>
> Making room for libavogadro.
>
>
> /branches is moved to /avogadro/branches
> ------------------------------------------------------------------------
> r67 | dcurtis3 | 2007-01-03 06:47:11 +0100 (Wed, 03 Jan 2007) | 3 lines
> Changed paths:
> A /avogadro/branches (from /branches:66)
> D /branches
>
> Making room for libavogadro
>
>
>
>
> ERROR HAPPENS HERE:
> ====================
>
> /trunk and /tags are moved, too.
> (/trunk/avogadro.pro becomes /avogadro/trunk/avogadro.pro):
> ------------------------------------------------------------------------
> r68 | dcurtis3 | 2007-01-03 06:47:34 +0100 (Wed, 03 Jan 2007) | 3 lines
> Changed paths:
> A /avogadro/tags (from /tags:66)
> A /avogadro/trunk (from /trunk:66)
> D /tags
> D /trunk
>
> Making room for libavogadro.
>
> The above delete/move of trunk isn't recorded anywhere in the git svn import.
> 'git-svn find-rev r66' doesn't produce any output!
Sorry. I meant r67 and r68 instead of r66.
> And later git-svn thinks that /trunk and all its files are still there, so
> e.g. /trunk/avogadro.pro stays in the repo forever.
>
>
> -Peter
>
> This is just for consistency here and for anyone interested in further
> analyses.
>
> Here is the rest of the import analyses I've done. Look how "interesting" the
> repo is and how many times the files are moved.
>
>
>
>
> /libavogadro is added
> ------------------------------------------------------------------------
> r69 | dcurtis3 | 2007-01-03 06:50:58 +0100 (Wed, 03 Jan 2007) | 3 lines
> Changed paths:
> A /libavogadro
> A /libavogadro/CMakeLists.txt
> A /libavogadro/FindOpenBabel.cmake
> A /libavogadro/src
> A /libavogadro/src/CMakeLists.txt
> A /libavogadro/src/color.cpp
> A /libavogadro/src/color.h
> A /libavogadro/src/engine.h
> A /libavogadro/src/engines
> A /libavogadro/src/engines/CMakeLists.txt
> A /libavogadro/src/engines/ResidueSphereEngine.cpp
> A /libavogadro/src/engines/ResidueSphereEngine.h
> A /libavogadro/src/engines/SphereEngine.cpp
> A /libavogadro/src/engines/SphereEngine.h
> A /libavogadro/src/engines/StickEngine.cpp
> A /libavogadro/src/engines/StickEngine.h
> A /libavogadro/src/engines/WireframeEngine.cpp
> A /libavogadro/src/engines/WireframeEngine.h
> A /libavogadro/src/engines/bsengine.cpp
> A /libavogadro/src/engines/bsengine.h
> A /libavogadro/src/engines/vertexarray.cpp
> A /libavogadro/src/engines/vertexarray.h
> A /libavogadro/src/glwidget.cpp
> A /libavogadro/src/glwidget.h
> A /libavogadro/src/primitives.cpp
> A /libavogadro/src/primitives.h
>
> Added libavogadro.
>
>
> Create /libavogadro/{trunk,branches,tags} and move anything below the
> former /libavogadro into /libavogadro/trunk
> ------------------------------------------------------------------------
> r70 | dcurtis3 | 2007-01-03 06:53:13 +0100 (Wed, 03 Jan 2007) | 3 lines
> Changed paths:
> D /libavogadro/CMakeLists.txt
> D /libavogadro/FindOpenBabel.cmake
> A /libavogadro/branches
> D /libavogadro/src
> A /libavogadro/tags
> A /libavogadro/trunk
> A /libavogadro/trunk/CMakeLists.txt (from /libavogadro/CMakeLists.txt:69)
> A /libavogadro/trunk/FindOpenBabel.cmake (from /libavogadro/FindOpenBabel.cmake:69)
> A /libavogadro/trunk/src (from /libavogadro/src:69)
>
> Putting in trunk / branches / tags.
>
>
> ------------------------------------------------------------------------
> r72 | dcurtis3 | 2007-01-03 08:55:32 +0100 (Wed, 03 Jan 2007) | 3 lines
> Changed paths:
> A /avogadro/trunk/CMakeLists.txt
> A /avogadro/trunk/FindAvogadro.cmake
> A /avogadro/trunk/FindOpenBabel.cmake
> D /avogadro/trunk/src/Engine.h
> D /avogadro/trunk/src/GLWidget.cpp
> D /avogadro/trunk/src/GLWidget.h
> D /avogadro/trunk/src/MainWindow.cpp
> D /avogadro/trunk/src/MainWindow.h
> D /avogadro/trunk/src/Primitives.cpp
> D /avogadro/trunk/src/Primitives.h
> D /avogadro/trunk/src/Renderer.h
> D /avogadro/trunk/src/Tool.cpp
> D /avogadro/trunk/src/Tool.h
> D /avogadro/trunk/src/Views.cpp
> D /avogadro/trunk/src/Views.h
> D /avogadro/trunk/src/color.cpp
> D /avogadro/trunk/src/color.h
> D /avogadro/trunk/src/engines
> M /avogadro/trunk/src/main.cpp
> A /avogadro/trunk/src/mainwindow.cpp (from /avogadro/trunk/src/MainWindow.cpp:70)
> A /avogadro/trunk/src/mainwindow.h (from /avogadro/trunk/src/MainWindow.h:70)
> A /avogadro/trunk/src/tool.cpp (from /avogadro/trunk/src/Tool.cpp:70)
> A /avogadro/trunk/src/tool.h (from /avogadro/trunk/src/Tool.h:70)
> A /avogadro/trunk/untitled01.gpr
>
> Now uses libavogadro. Starting to think we should package this a
> little different.
>
>
>
> Renamed /libavogadro to /avogadro-lib
> ------------------------------------------------------------------------
> r73 | dcurtis3 | 2007-01-03 16:48:02 +0100 (Wed, 03 Jan 2007) | 3 lines
> Changed paths:
> A /avogadro-lib (from /libavogadro:72)
> D /libavogadro
>
> Refactor
>
>
> mv /avogadro/trunk/avogadro.pro /trunk/avogadro/avogadro.pro
> ------------------------------------------------------------------------
> r75 | dcurtis3 | 2007-01-03 20:49:35 +0100 (Wed, 03 Jan 2007) | 2 lines
> Changed paths:
> D /avogadro
> D /avogadro-lib
> A /branches
> A /tags
> A /trunk
> A /trunk/avogadro (from /avogadro/trunk:74)
> A /trunk/libavogadro (from /avogadro-lib/trunk:74)
>
> Moving things around. Conforming to a more KDE-like layout in SVN.
> I'm going nuts. SOrry
^ 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