* 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] Add more checkout tests
From: Junio C Hamano @ 2007-12-10 5:14 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0712092244570.5349@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> Of course, a patch to clean up the user experience could have a hunk that
> makes the test expect that the UI is cleaned up. It's not like we can't
> change our tests to accompany improvements in behavior, and I'd argue that
> those hunks give a useful example of the improvement.
Ok.
> The point of adding these tests (and parts of tests) is that I'd forgotten
> to maintain some of the important information while writing
> builtin-checkout, and there wasn't a test that it was provided. While some
> of the output is arbitrary informative text, there's a certain amount of
> generated information there that shouldn't get lost or be incorrect.
Fair enough.
^ permalink raw reply
* Re: [PATCH 2/2] pack-objects: fix threaded load balancing
From: Jon Smirl @ 2007-12-10 4:30 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LFD.0.99999.0712080000120.555@xanadu.home>
On 12/8/07, Nicolas Pitre <nico@cam.org> wrote:
>
> The current method consists of a master thread serving chunks of objects
> to work threads when they're done with their previous chunk. The issue
> is to determine the best chunk size: making it too large creates poor
> load balancing, while making it too small has a negative effect on pack
> size because of the increased number of chunk boundaries and poor delta
> window utilization.
>
> This patch implements a completely different approach by initially
> splitting the work in large chunks uniformly amongst all threads, and
> whenever a thread is done then it steals half of the remaining work from
> another thread with the largest amount of unprocessed objects.
>
> This has the advantage of greatly reducing the number of chunk boundaries
> with an almost perfect load balancing.
>
> Signed-off-by: Nicolas Pitre <nico@cam.org>
> ---
> builtin-pack-objects.c | 117 +++++++++++++++++++++++++++++++++++-------------
> 1 files changed, 85 insertions(+), 32 deletions(-)
>
> diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
> index 5002cc6..fcc1901 100644
> --- a/builtin-pack-objects.c
> +++ b/builtin-pack-objects.c
> @@ -1479,10 +1479,10 @@ static unsigned long free_unpacked(struct unpacked *n)
> return freed_mem;
> }
>
> -static void find_deltas(struct object_entry **list, unsigned list_size,
> +static void find_deltas(struct object_entry **list, unsigned *list_size,
> int window, int depth, unsigned *processed)
> {
> - uint32_t i = 0, idx = 0, count = 0;
> + uint32_t i, idx = 0, count = 0;
> unsigned int array_size = window * sizeof(struct unpacked);
> struct unpacked *array;
> unsigned long mem_usage = 0;
> @@ -1490,11 +1490,23 @@ static void find_deltas(struct object_entry **list, unsigned list_size,
> array = xmalloc(array_size);
> memset(array, 0, array_size);
>
> - do {
> - struct object_entry *entry = list[i++];
> + for (;;) {
> + struct object_entry *entry = *list++;
> struct unpacked *n = array + idx;
> int j, max_depth, best_base = -1;
>
> + progress_lock();
> + if (!*list_size) {
> + progress_unlock();
> + break;
> + }
> + (*list_size)--;
> + if (!entry->preferred_base) {
> + (*processed)++;
> + display_progress(progress_state, *processed);
> + }
> + progress_unlock();
> +
> mem_usage -= free_unpacked(n);
> n->entry = entry;
>
> @@ -1512,11 +1524,6 @@ static void find_deltas(struct object_entry **list, unsigned list_size,
> if (entry->preferred_base)
> goto next;
>
> - progress_lock();
> - (*processed)++;
> - display_progress(progress_state, *processed);
> - progress_unlock();
> -
> /*
> * If the current object is at pack edge, take the depth the
> * objects that depend on the current object into account
> @@ -1576,7 +1583,7 @@ static void find_deltas(struct object_entry **list, unsigned list_size,
> count++;
> if (idx >= window)
> idx = 0;
> - } while (i < list_size);
> + }
>
> for (i = 0; i < window; ++i) {
> free_delta_index(array[i].index);
> @@ -1591,6 +1598,7 @@ struct thread_params {
> pthread_t thread;
> struct object_entry **list;
> unsigned list_size;
> + unsigned remaining;
> int window;
> int depth;
> unsigned *processed;
> @@ -1612,10 +1620,10 @@ static void *threaded_find_deltas(void *arg)
> pthread_mutex_lock(&data_ready);
> pthread_mutex_unlock(&data_request);
>
> - if (!me->list_size)
> + if (!me->remaining)
> return NULL;
>
> - find_deltas(me->list, me->list_size,
> + find_deltas(me->list, &me->remaining,
> me->window, me->depth, me->processed);
> }
> }
> @@ -1624,57 +1632,102 @@ static void ll_find_deltas(struct object_entry **list, unsigned list_size,
> int window, int depth, unsigned *processed)
> {
> struct thread_params *target, p[delta_search_threads];
> - int i, ret;
> - unsigned chunk_size;
> + int i, ret, active_threads = 0;
>
> if (delta_search_threads <= 1) {
> - find_deltas(list, list_size, window, depth, processed);
> + find_deltas(list, &list_size, window, depth, processed);
> return;
> }
>
> pthread_mutex_lock(&data_provider);
> pthread_mutex_lock(&data_ready);
>
> + /* Start work threads. */
> for (i = 0; i < delta_search_threads; i++) {
> p[i].window = window;
> p[i].depth = depth;
> p[i].processed = processed;
> + p[i].remaining = 0;
> ret = pthread_create(&p[i].thread, NULL,
> threaded_find_deltas, &p[i]);
> if (ret)
> die("unable to create thread: %s", strerror(ret));
> + active_threads++;
> }
>
> - /* this should be auto-tuned somehow */
> - chunk_size = window * 1000;
> + /* Then partition the work amongst them. */
> + for (i = 0; i < delta_search_threads; i++) {
> + unsigned sub_size = list_size / (delta_search_threads - i);
>
> - do {
> - unsigned sublist_size = chunk_size;
> - if (sublist_size > list_size)
> - sublist_size = list_size;
> + pthread_mutex_lock(&data_provider);
> + target = data_requester;
> + if (!sub_size) {
> + pthread_mutex_unlock(&data_ready);
> + pthread_join(target->thread, NULL);
> + active_threads--;
> + continue;
> + }
>
> /* try to split chunks on "path" boundaries */
> - while (sublist_size < list_size && list[sublist_size]->hash &&
> - list[sublist_size]->hash == list[sublist_size-1]->hash)
> - sublist_size++;
> + while (sub_size < list_size && list[sub_size]->hash &&
> + list[sub_size]->hash == list[sub_size-1]->hash)
> + sub_size++;
> +
> + target->list = list;
> + target->list_size = sub_size;
> + target->remaining = sub_size;
> + pthread_mutex_unlock(&data_ready);
>
> + list += sub_size;
> + list_size -= sub_size;
> + }
> +
> + /*
> + * Now let's wait for work completion. Each time a thread is done
> + * with its work, we steal half of the remaining work from the
> + * thread with the largest number of unprocessed objects and give
> + * it to that newly idle thread. This ensure good load balancing
> + * until the remaining object list segments are simply too short
> + * to be worth splitting anymore.
> + */
> + do {
> + struct thread_params *victim = NULL;
> + unsigned sub_size = 0;
> pthread_mutex_lock(&data_provider);
> target = data_requester;
> - target->list = list;
> - target->list_size = sublist_size;
> +
> + progress_lock();
> + for (i = 0; i < delta_search_threads; i++)
> + if (p[i].remaining > 2*window &&
> + (!victim || victim->remaining < p[i].remaining))
> + victim = &p[i];
> + 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
> + sub_size--;
> + }
> + target->list = list;
> + victim->list_size -= sub_size;
> + victim->remaining -= sub_size;
> + }
> + progress_unlock();
> +
> + target->list_size = sub_size;
> + target->remaining = sub_size;
> pthread_mutex_unlock(&data_ready);
>
> - list += sublist_size;
> - list_size -= sublist_size;
> - if (!sublist_size) {
> + if (!sub_size) {
> pthread_join(target->thread, NULL);
> - i--;
> + active_threads--;
> }
> - } while (i);
> + } while (active_threads);
> }
>
> #else
> -#define ll_find_deltas find_deltas
> +#define ll_find_deltas(l, s, w, d, p) find_deltas(l, &s, w, d, p)
> #endif
>
> static void prepare_pack(int window, int depth)
> --
> 1.5.3.7.2184.ge321d-dirty
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH 2/2] pack-objects: fix threaded load balancing
From: Jon Smirl @ 2007-12-10 4:10 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LFD.0.99999.0712080000120.555@xanadu.home>
I added a couple of printfs to debug this.
Why did the thread exit when there were still 72,000 objects left?
Another one exited with 50,000 objects left.
The repack is still running, it has been proceeding on two cores for
10 minutes after the two threads exited.
jonsmirl@terra:/video/gcc$ git-repack -a -d -f --depth=250 --window=250
Counting objects: 828348, done.
starting thread 0
Compressing objects: 0% (1/809010)
starting thread 1
starting thread 2
starting thread 3
Compressing objects: 59% (478011/809010)
victim 0x7fffc7976480 sub_size 76058
thread 0x7fffc79764f8 sub_size 76058
Compressing objects: 62% (504273/809010)
victim 0x7fffc79764a8 sub_size 69967
thread 0x7fffc79764d0 sub_size 69967
Compressing objects: 82% (664231/809010)
victim 0x7fffc7976480 sub_size 35308
thread 0x7fffc79764d0 sub_size 35308
Compressing objects: 91% (736690/809010)
victim 0x7fffc79764d0 sub_size 0
thread 0x7fffc79764f8 sub_size 0
Compressing objects: 93% (758922/809010)
victim 0x7fffc79764d0 sub_size 0
thread 0x7fffc79764a8 sub_size 0
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] Add more checkout tests
From: Daniel Barkalow @ 2007-12-10 4:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vprxfmczi.fsf@gitster.siamese.dyndns.org>
On Sun, 9 Dec 2007, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > +test_expect_success "checkout with unrelated dirty tree without -m" '
> > +
> > + git checkout -f master &&
> > + fill 0 1 2 3 4 5 6 7 8 >same &&
> > + cp same kept
> > + git checkout side >messages &&
> > + git diff same kept
> > + (cat > messages.expect <<EOF
> > +M same
> > +EOF
> > +) &&
> > + touch messages.expect &&
> > + git diff messages.expect messages
> > +'
>
> What is this "touch" about?
Left over from before I'd added the here document, so there'd be a file to
diff against, and it would be wrong, and I could find the actual contents.
I just forgot to take it out when I was creating the real thing.
> I do not recall the details, but we had problem reports that some shells
> do not handle here-documents (i.e. cmd <<EOF) inside test_expect_success
> well, and generally tried to keep them outside. I however see some of
> the newer tests do have here-doc inside expect-success, and do not
> recall hearing breakage reports on them. Maybe it was a false alarm and
> we were being overly cautious, or maybe not enough people (especially on
> more exotic systems) are running tests these days. Let's keep the
> here-doc as-is in your tests and see what happens.
Sure. Possibly we should instead just be testing for the presence of the
correct line, and absence of incorrect lines, in any case?
> > test_expect_success "checkout -m with dirty tree" '
> >
> > git checkout -f master &&
> > git clean -f &&
> >
> > fill 0 1 2 3 4 5 6 7 8 >one &&
> > - git checkout -m side &&
> > + git checkout -m side > messages &&
> >
> > test "$(git symbolic-ref HEAD)" = "refs/heads/side" &&
> >
> > + (cat >expect.messages <<EOF
> > +Merging side with local
> > +Merging:
> > +ab76817 Side M one, D two, A three
> > +virtual local
> > +found 1 common ancestor(s):
> > +7329388 Initial A one, A two
> > +Auto-merged one
> > +M one
> > +EOF
> > +) &&
> > + git diff expect.messages messages &&
>
> I do not like the idea of testing the exact wording of messages this
> way.
>
> I do not think we care about the exact wording of these messages, and I
> think our tests should check what we do care about without casting the
> UI in stone. Otherwise, it will make it harder to clean-up the user
> experience later. Perhaps it would be sufficient to make sure that (1)
> this checkout succeeds with exit 0 status, and that (2) the contents of
> the merged 'one' is a reasonable merge result, i.e. "git diff HEAD one"
> gets the same patch-id as "git diff HEAD one" taken before switching the
> branches.
What I'm actually testing for is the "M<tab>one" line, and that the
previous line isn't name-status stuff; that is, that the name-status stuff
is right.
Of course, a patch to clean up the user experience could have a hunk that
makes the test expect that the UI is cleaned up. It's not like we can't
change our tests to accompany improvements in behavior, and I'd argue that
those hunks give a useful example of the improvement.
> > @@ -145,7 +176,16 @@ test_expect_success 'checkout -m with merge conflict' '
> > test_expect_success 'checkout to detach HEAD' '
> >
> > git checkout -f renamer && git clean -f &&
> > - git checkout renamer^ &&
> > + git checkout renamer^ 2>messages &&
> > + (cat >messages.expect <<EOF
> > +Note: moving to "renamer^" which isn'"'"'t a local branch
> > +If you want to create a new branch from this checkout, you may do so
> > +(now or later) by using -b with the checkout command again. Example:
> > + git checkout -b <new_branch_name>
> > +HEAD is now at 7329388... Initial A one, A two
> > +EOF
> > +) &&
> > + git diff messages.expect messages &&
>
> Same here. If we want to make sure the head is detached at the intended
> commit, make sure "rev-parse HEAD" gives the expected result, and make
> sure "symbolic-ref HEAD" says it is not symbolic.
I think we're already testing for that. I really want the "HEAD is now..."
line, which ought to give the right info.
The point of adding these tests (and parts of tests) is that I'd forgotten
to maintain some of the important information while writing
builtin-checkout, and there wasn't a test that it was provided. While some
of the output is arbitrary informative text, there's a certain amount of
generated information there that shouldn't get lost or be incorrect.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] Remove .git/branches from the .git template.
From: Kristian Høgsberg @ 2007-12-10 4:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3aubpvog.fsf@gitster.siamese.dyndns.org>
On Sun, Dec 09, 2007 at 10:30:55AM -0800, Junio C Hamano wrote:
> Kristian Høgsberg <krh@bitplanet.net> writes:
>
> > The code in git to read the info in .git/branches is still there,
> > but nothing ever writes to this, so lets stop creating it.
> >
> > Signed-off-by: Kristian Høgsberg <krh@redhat.com>
> > ---
> >
> > As far as I can see this should be safe, but I admit to never really
> > knowing what .git/branches was originally used for - tracking remote
> > branches or something? In any case, we only ever read from this dir
> > so the only left in git to deal with this seems to be for compatibilty
> > with older repos.
>
> This was done purely so that Cogito would not barf on a repository
> initialized with "git init" even if it did not bother creating necessary
> leading directories when it writes its rough equivalent to .git/remotes/
> information. I do not recall if Cogito had such a problem anymore, but
> I think it can safely go when Cogito is effectively dead.
OK, I don't know where cogito is in that respect, I thought maybe we had
just forgotten we still created that directory. Should we just try to
apply the patch to find out how it might interact with cogito?
Kristian
^ permalink raw reply
* Re: [PATCH] Add more checkout tests
From: Junio C Hamano @ 2007-12-10 3:42 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0712092204200.5349@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> +test_expect_success "checkout with unrelated dirty tree without -m" '
> +
> + git checkout -f master &&
> + fill 0 1 2 3 4 5 6 7 8 >same &&
> + cp same kept
> + git checkout side >messages &&
> + git diff same kept
> + (cat > messages.expect <<EOF
> +M same
> +EOF
> +) &&
> + touch messages.expect &&
> + git diff messages.expect messages
> +'
What is this "touch" about?
I do not recall the details, but we had problem reports that some shells
do not handle here-documents (i.e. cmd <<EOF) inside test_expect_success
well, and generally tried to keep them outside. I however see some of
the newer tests do have here-doc inside expect-success, and do not
recall hearing breakage reports on them. Maybe it was a false alarm and
we were being overly cautious, or maybe not enough people (especially on
more exotic systems) are running tests these days. Let's keep the
here-doc as-is in your tests and see what happens.
> test_expect_success "checkout -m with dirty tree" '
>
> git checkout -f master &&
> git clean -f &&
>
> fill 0 1 2 3 4 5 6 7 8 >one &&
> - git checkout -m side &&
> + git checkout -m side > messages &&
>
> test "$(git symbolic-ref HEAD)" = "refs/heads/side" &&
>
> + (cat >expect.messages <<EOF
> +Merging side with local
> +Merging:
> +ab76817 Side M one, D two, A three
> +virtual local
> +found 1 common ancestor(s):
> +7329388 Initial A one, A two
> +Auto-merged one
> +M one
> +EOF
> +) &&
> + git diff expect.messages messages &&
I do not like the idea of testing the exact wording of messages this
way.
I do not think we care about the exact wording of these messages, and I
think our tests should check what we do care about without casting the
UI in stone. Otherwise, it will make it harder to clean-up the user
experience later. Perhaps it would be sufficient to make sure that (1)
this checkout succeeds with exit 0 status, and that (2) the contents of
the merged 'one' is a reasonable merge result, i.e. "git diff HEAD one"
gets the same patch-id as "git diff HEAD one" taken before switching the
branches.
> @@ -145,7 +176,16 @@ test_expect_success 'checkout -m with merge conflict' '
> test_expect_success 'checkout to detach HEAD' '
>
> git checkout -f renamer && git clean -f &&
> - git checkout renamer^ &&
> + git checkout renamer^ 2>messages &&
> + (cat >messages.expect <<EOF
> +Note: moving to "renamer^" which isn'"'"'t a local branch
> +If you want to create a new branch from this checkout, you may do so
> +(now or later) by using -b with the checkout command again. Example:
> + git checkout -b <new_branch_name>
> +HEAD is now at 7329388... Initial A one, A two
> +EOF
> +) &&
> + git diff messages.expect messages &&
Same here. If we want to make sure the head is detached at the intended
commit, make sure "rev-parse HEAD" gives the expected result, and make
sure "symbolic-ref HEAD" says it is not symbolic.
> H=$(git rev-parse --verify HEAD) &&
> M=$(git show-ref -s --verify refs/heads/master) &&
> test "z$H" = "z$M" &&
> --
> 1.5.3.6.886.gb204
^ permalink raw reply
* Re: [PATCH] Interactive editor tests for commit-msg hook
From: Junio C Hamano @ 2007-12-10 3:42 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: git, krh
In-Reply-To: <1197204731-19553-1-git-send-email-win@wincent.com>
Wincent Colaiuta <win@wincent.com> writes:
> I didn't add similar tests for the pre-commit hook because I don't
> think that's an interesting code path; we don't care about the commit
> message in that case, only whether the commit is allowed to proceed or
> not.
Sensible.
> +# 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"?
> +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"
> +
I initially was going to say "this is just a style thing", but I really
want our tests to read uniformly like this:
test_expect_success 'without hook (editor)' '
echo more foo >>file &&
git add file &&
echo more foo >FAKE_MSG &&
GIT_EDITOR="$FAKE_EDITOR" git commit
'
* Use single quotes around test unless there is a compelling reason not
to;
* The opening single quote of the test body on the same line as
expect-success; the end quote at column 1 on a line on its own.
Notice a bug in your version? Dq around $FAKE_EDITOR is stripped away
and it is harder to spot it because the script does not follow that
style.
^ permalink raw reply
* [PATCH] Add more checkout tests
From: Daniel Barkalow @ 2007-12-10 3:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
If you have local changes that don't conflict with the
branch-switching changes, these should be kept, not cause errors even
without -m, and be reported afterwards in name-status format.
With -m, the changes carried across should be listed as well. And, for
now, include the merge-recursive output from this process.
Also test the detatched head message in at least one case.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
t/t7201-co.sh | 46 +++++++++++++++++++++++++++++++++++++++++++---
1 files changed, 43 insertions(+), 3 deletions(-)
diff --git a/t/t7201-co.sh b/t/t7201-co.sh
index 55558ab..3cf0cf1 100755
--- a/t/t7201-co.sh
+++ b/t/t7201-co.sh
@@ -20,6 +20,8 @@ Test switching across them.
. ./test-lib.sh
+test_tick
+
fill () {
for i
do
@@ -30,9 +32,10 @@ fill () {
test_expect_success setup '
+ fill x y z > same &&
fill 1 2 3 4 5 6 7 8 >one &&
fill a b c d e >two &&
- git add one two &&
+ git add same one two &&
git commit -m "Initial A one, A two" &&
git checkout -b renamer &&
@@ -74,16 +77,44 @@ test_expect_success "checkout with dirty tree without -m" '
'
+test_expect_success "checkout with unrelated dirty tree without -m" '
+
+ git checkout -f master &&
+ fill 0 1 2 3 4 5 6 7 8 >same &&
+ cp same kept
+ git checkout side >messages &&
+ git diff same kept
+ (cat > messages.expect <<EOF
+M same
+EOF
+) &&
+ touch messages.expect &&
+ git diff messages.expect messages
+'
+
test_expect_success "checkout -m with dirty tree" '
git checkout -f master &&
git clean -f &&
fill 0 1 2 3 4 5 6 7 8 >one &&
- git checkout -m side &&
+ git checkout -m side > messages &&
test "$(git symbolic-ref HEAD)" = "refs/heads/side" &&
+ (cat >expect.messages <<EOF
+Merging side with local
+Merging:
+ab76817 Side M one, D two, A three
+virtual local
+found 1 common ancestor(s):
+7329388 Initial A one, A two
+Auto-merged one
+M one
+EOF
+) &&
+ git diff expect.messages messages &&
+
fill "M one" "A three" "D two" >expect.master &&
git diff --name-status master >current.master &&
diff expect.master current.master &&
@@ -145,7 +176,16 @@ test_expect_success 'checkout -m with merge conflict' '
test_expect_success 'checkout to detach HEAD' '
git checkout -f renamer && git clean -f &&
- git checkout renamer^ &&
+ git checkout renamer^ 2>messages &&
+ (cat >messages.expect <<EOF
+Note: moving to "renamer^" which isn'"'"'t a local branch
+If you want to create a new branch from this checkout, you may do so
+(now or later) by using -b with the checkout command again. Example:
+ git checkout -b <new_branch_name>
+HEAD is now at 7329388... Initial A one, A two
+EOF
+) &&
+ git diff messages.expect messages &&
H=$(git rev-parse --verify HEAD) &&
M=$(git show-ref -s --verify refs/heads/master) &&
test "z$H" = "z$M" &&
--
1.5.3.6.886.gb204
^ permalink raw reply related
* Re: How-to combine several separate git repos?
From: Daniel Barkalow @ 2007-12-10 3:01 UTC (permalink / raw)
To: Wink Saville; +Cc: Alex Riesen, git
In-Reply-To: <475CA476.6070507@saville.com>
On Sun, 9 Dec 2007, Wink Saville wrote:
> Daniel Barkalow wrote:
> > On Sun, 9 Dec 2007, Wink Saville wrote:
> > <snip>
> >
>
> I got submodule working, buy following the tutorial here:
> http://git.or.cz/gitwiki/GitSubmoduleTutorial#preview.
>
> As well as looking at:
> http://jonathan.tron.name/articles/2007/09/15/git-1-5-3-submodule
> http://en.wikibooks.org/wiki/Source_Control_Management_With_Git/Submodules_and_Superprojects#endnote_lie_parent
> http://kerneltrap.org/mailarchive/git/2007/10/19/348810
> http://kerneltrap.org/mailarchive/git/2007/10/19/348829
>
> I'd say the current documentation in git needs to improve at least
> for neophytes. The first step would be to include the GitSubmoduleTutorial.
> Also, I think the second paragraph of the tutorial is very important and
> something like it should probably be the first paragraph of the git-submodule
> man page:
>
> "Submodules maintain their own identity; the submodule support just stores the
> submodule repository location and commit ID, so other developers who clone the
> superproject can easily clone all the submodules at the same revision."
>
> My interpretation of the paragraph and how submodules might be used
> is that the "supermodule" provides tags for a set of repositories.
> I see that as important, especially for large projects which could use
> multiple repositories for sub-projects and then use a "supermodule"
> for test and release management.
>
> That isn't what I really wanted to do. As a one man band I was looking
> to actually "combine" several repositories into one logical repository
> to simplify commits, pushes, pulls to my own backup repositories.
> I now see that that wasn't the purpose of submodule.
>
> Anyway, that is the perspective of this neophyte and I learned something
> new which is a primary goal of mine.
>
> Finally, I'm back to my original question how to combine repositories? As
> I said in my response to Alex, the multiple branches I got working but that
> isn't what I want.
>
> What I think I now want is to create a new repository which contains my
> other repositories as sub-directories (with their histories) after combining
> them I would delete the old repositories. I expect the resulting history
> to be sequential, with the sequence defined by the order I combine them,
> but maybe there is another choice?
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*
^ permalink raw reply
* Re: Something is broken in repack
From: Nicolas Pitre @ 2007-12-10 2:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jon Smirl, Git Mailing List
In-Reply-To: <7vodd0vnhv.fsf@gitster.siamese.dyndns.org>
On Sat, 8 Dec 2007, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > On Fri, 7 Dec 2007, Jon Smirl wrote:
> >
> >> Starting with a 2GB pack of the same data my process size only grew to
> >> 3GB with 2GB of mmaps.
> >
> > Which is quite reasonable, even if the same issue might still be there.
> >
> > So the problem seems to be related to the pack access code and not the
> > repack code. And it must have something to do with the number of deltas
> > being replayed. And because the repack is attempting delta compression
> > roughly from newest to oldest, and because old objects are typically in
> > a deeper delta chain, then this might explain the logarithmic slowdown.
> >
> > So something must be wrong with the delta cache in sha1_file.c somehow.
>
> I was reaching the same conclusion but haven't managed to spot anything
> blatantly wrong in that area. Will need to dig more.
I didn't find anything wrong there either. I'll have to run some more
gcc repacking tests myself, despite not having a blazingly fast machine
making for rather long turnarounds.
Nicolas
^ permalink raw reply
* Re: How-to combine several separate git repos?
From: Wink Saville @ 2007-12-10 2:29 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Alex Riesen, git
In-Reply-To: <Pine.LNX.4.64.0712091942520.5349@iabervon.org>
Daniel Barkalow wrote:
> On Sun, 9 Dec 2007, Wink Saville wrote:
>
> <snip>
>
I got submodule working, buy following the tutorial here:
http://git.or.cz/gitwiki/GitSubmoduleTutorial#preview.
As well as looking at:
http://jonathan.tron.name/articles/2007/09/15/git-1-5-3-submodule
http://en.wikibooks.org/wiki/Source_Control_Management_With_Git/Submodules_and_Superprojects#endnote_lie_parent
http://kerneltrap.org/mailarchive/git/2007/10/19/348810
http://kerneltrap.org/mailarchive/git/2007/10/19/348829
I'd say the current documentation in git needs to improve at least
for neophytes. The first step would be to include the GitSubmoduleTutorial.
Also, I think the second paragraph of the tutorial is very important and
something like it should probably be the first paragraph of the
git-submodule
man page:
"Submodules maintain their own identity; the submodule support just
stores the submodule repository location and commit ID, so other
developers who clone the superproject can easily clone all the
submodules at the same revision."
My interpretation of the paragraph and how submodules might be used
is that the "supermodule" provides tags for a set of repositories.
I see that as important, especially for large projects which could use
multiple repositories for sub-projects and then use a "supermodule"
for test and release management.
That isn't what I really wanted to do. As a one man band I was looking
to actually "combine" several repositories into one logical repository
to simplify commits, pushes, pulls to my own backup repositories.
I now see that that wasn't the purpose of submodule.
Anyway, that is the perspective of this neophyte and I learned something
new which is a primary goal of mine.
Finally, I'm back to my original question how to combine repositories? As
I said in my response to Alex, the multiple branches I got working but that
isn't what I want.
What I think I now want is to create a new repository which contains my
other repositories as sub-directories (with their histories) after combining
them I would delete the old repositories. I expect the resulting history
to be sequential, with the sequence defined by the order I combine them,
but maybe there is another choice?
Cheers,
Wink Saville
^ permalink raw reply
* Re: How-to combine several separate git repos?
From: Daniel Barkalow @ 2007-12-10 1:11 UTC (permalink / raw)
To: Wink Saville; +Cc: Alex Riesen, git
In-Reply-To: <475C7DD5.9040209@saville.com>
On Sun, 9 Dec 2007, Wink Saville wrote:
> Daniel Barkalow wrote:
> > On Sun, 9 Dec 2007, Wink Saville wrote:
> >
> > I think that submodules do what you want. And they may not be ready for
> > neophytes to just use, but they're ready for neophytes to try using and tell
> > us where things get confused.
> >
> <snip>
> > -Daniel
> I would like to try submodules and started to read the man
>
>
> I'll try submodules and I'll start by reading the man page,
> I got to "add" and did the following:
>
> wink@ic2d1:$ mkdir x
> wink@ic2d1:$ cd x
> wink@ic2d1:$ git init
> Initialized empty Git repository in .git/
> wink@ic2d1:$ git-submodule add ../android/StateMachine
> remote (origin) does not have a url in .git/config
> you must specify a repository to clone.
> Clone of '' into submodule path 'StateMachine' failed
It looks like git-submodule does something really wrong for URLs that
start with ./ or ../. (By "wrong", I mean that it's different from the
handling of the same URL anywhere else.) I think there's a general problem
(beyond submodule support) that git doesn't do a good job with
intermediate repositories: if you clone a repository, and then clone the
clone, the second clone sees the local-to-the-first aspects and largely
ignores the actual origin's properties.
On the other hand, you probably don't really want the canonical URL for
the submodule to be a local relative path. If what you have are local
clones of public repositories, you want to use the public remote
repositories' URLs there. If you really want it to be a clone of the local
repository, you can use an absolute path and weird things won't happen.
I think it should be possible to store the submodule data in the 'x'
repository as well; have some branches which are the three different
projects, and then pull them out of '.', but this doesn't seem to be
working for me, either.
> The documentation for "submodule add" says:
>
> /git-submodule/ [--quiet] [-b branch] add <repository> [<path>]
> Add the given repository as a submodule at the given path to the changeset to
> be committed next.
>
> From the above, <path> is ambiguous to me, is it referring to the source or
> destination. I continue reading and in the options section we find:
>
> <path>
>
> Path to submodule(s). When specified this will restrict the command
> to only operate on the submodules found at the specified paths.
>
> So it seems <path> is the for the source, but some how it can specify multiple
> paths.
This is actually the destination. The projects that are under discussion
are only submodules in the context of the destination. For "git submodule
add" it's the path in the superproject where the submodule will appear.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Something is broken in repack
From: Nicolas Pitre @ 2007-12-10 1:07 UTC (permalink / raw)
To: Jon Smirl; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <9e4733910712091025s27c3d698yba78eed4306cd3ec@mail.gmail.com>
On Sun, 9 Dec 2007, Jon Smirl wrote:
> On 12/9/07, Junio C Hamano <gitster@pobox.com> wrote:
> > Junio C Hamano <gitster@pobox.com> writes:
> >
> > > Nicolas Pitre <nico@cam.org> writes:
> > >
> > >> On Fri, 7 Dec 2007, Jon Smirl wrote:
> > >>
> > >>> Starting with a 2GB pack of the same data my process size only grew to
> > >>> 3GB with 2GB of mmaps.
> > >>
> > >> Which is quite reasonable, even if the same issue might still be there.
> > >>
> > >> So the problem seems to be related to the pack access code and not the
> > >> repack code. And it must have something to do with the number of deltas
> > >> being replayed. And because the repack is attempting delta compression
> > >> roughly from newest to oldest, and because old objects are typically in
> > >> a deeper delta chain, then this might explain the logarithmic slowdown.
> > >>
> > >> So something must be wrong with the delta cache in sha1_file.c somehow.
> > >
> > > I was reaching the same conclusion but haven't managed to spot anything
> > > blatantly wrong in that area. Will need to dig more.
> >
> > Does this problem have correlation with the use of threads? Do you see
> > the same bloat with or without THREADED_DELTA_SEARCH defined?
> >
>
> Something else seems to be wrong.
>
> With threading turned off, 5000 CPU seconds and 13% done.
> With threading turned on, threads = 1, 5000 CPU seconds, 13%
> With threading turned on, threads = 2, 180 CPU seconds, 13%
> With threading turned on, threads = 4, 150 CPU seconds, 13%
>
> This can't be right, four cores are not 40x one core.
It may be right. The object list to apply delta compression on doesn't
necessarily require a uniform amount of cycles throughout. When using
multiple threads, the list is broken in parts for each thread, and later
parts might end up being simply much easier to process, therefore
changing the percentage figure.
> So maybe the observed logarithmic slow down is because the percent
> complete is being reported wrong in the threaded case. If that's the
> case we may be looking in the wrong place for problems.
I really doubt it.
Nicolas
^ permalink raw reply
* Re: [PATCH 0/2] [RFT] git-svn: more efficient revision -> commit mapping
From: Harvey Harrison @ 2007-12-10 1:04 UTC (permalink / raw)
To: Eric Wong; +Cc: Junio C Hamano, git
In-Reply-To: <1197233768.7185.6.camel@brick>
On Sun, 2007-12-09 at 12:56 -0800, Harvey Harrison wrote:
> On Sat, 2007-12-08 at 23:27 -0800, Eric Wong wrote:
> > This is very lightly tested, but describes the format I described in:
> >
> > http://article.gmane.org/gmane.comp.version-control.git/67126
> >
> > (more in the commit messages)
> >
> > I'll be out of town the next few days and I'm not sure how much I'll be
> > able to follow up on it while I'm gone. Please test, especially if
> > you're dealing with a repository where large .rev_db files are a
> > problem.
> >
> > Junio: not intended for master just yet, but if you hear nothing but
> > good things about it, feel free :)
> Preliminary tests against the gcc repo are going swimmingly.
>
> Successful git svn rebase against trunk, doing a full git svn fetch
> now to build rev_maps for all svn branches/tags. At halfway through
> space has decreased from ~2GB to 17MB for about half of the needed
> metadata.
>
Eric,
I'm very happy with these patches. For the gcc repo, git-svn metadata
has gone from over 5GB to 33MB. git-svn fetch/rebase are working fine,
will shout if I see any odd behavior.
Harvey
^ permalink raw reply
* git-svn init from Avogadro SVN repo - deleted files showing
From: Marcus D. Hanwell @ 2007-12-10 0:24 UTC (permalink / raw)
To: git, Peter Baumann
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.
Thanks,
Marcus
^ permalink raw reply
* Re: How-to combine several separate git repos?
From: Wink Saville @ 2007-12-09 23:44 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Alex Riesen, git
In-Reply-To: <Pine.LNX.4.64.0712091445470.5349@iabervon.org>
Daniel Barkalow wrote:
> On Sun, 9 Dec 2007, Wink Saville wrote:
>
>
> I think that submodules do what you want. And they may not be ready for
> neophytes to just use, but they're ready for neophytes to try using and
> tell us where things get confused.
>
<snip>
> -Daniel
I would like to try submodules and started to read the man
I'll try submodules and I'll start by reading the man page,
I got to "add" and did the following:
wink@ic2d1:$ mkdir x
wink@ic2d1:$ cd x
wink@ic2d1:$ git init
Initialized empty Git repository in .git/
wink@ic2d1:$ git-submodule add ../android/StateMachine
remote (origin) does not have a url in .git/config
you must specify a repository to clone.
Clone of '' into submodule path 'StateMachine' failed
The documentation for "submodule add" says:
/git-submodule/ [--quiet] [-b branch] add <repository> [<path>]
Add the given repository as a submodule at the given path to the
changeset to be committed next.
From the above, <path> is ambiguous to me, is it referring to the
source or destination. I continue reading and in the options section we
find:
<path>
Path to submodule(s). When specified this will restrict the command
to only operate on the submodules found at the specified paths.
So it seems <path> is the for the source, but some how it can specify
multiple paths. This seems to imply that I could add my three
repositories with one command. But I have no idea how and there are no
examples, but I can guess for my three repositories maybe:
wink@ic2d1:$ rm -rf *
wink@ic2d1:$ git init
Initialized empty Git repository in .git/
wink@ic2d1:$ git add submodule ../android StateMachine test2 test-annotation
fatal: '../android' is outside repository
Nope that didn't work, continue reading, ah I probably need to
"submodule init" first.
It says:
init
Initialize the submodules, i.e. register in .git/config each
submodule name and url found in .gitmodules. The key used in
.git/config is submodule.$name.url. This command does not alter
existing information in .git/config.
This is garbally-gok to me (remember, neophyte) but it does leave a clue,
apparently I need to create .gitmodules so I do:
wink@ic2d1:$ cat .gitmodules
[submodule "StateMachine"]
path = StateMachine
url = ../android/StateMachine
[submodule "test2"]
path = test2
url = ../android/test2
[submodule "test-annotation"]
path = test2
url = ../android/test-annotation
So now I:
wink@ic2d1:$ cd ..
wink@ic2d1:$ rm -rf x
wink@ic2d1:$ mkdir x
wink@ic2d1:$ cd x
wink@ic2d1:$ git init
Initialized empty Git repository in .git/
wink@ic2d1:$ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
wink@ic2d1:$ cp ../gitmodules .gitmodules
wink@ic2d1:$ cat .gitmodules
[submodule "StateMachine"]
path = StateMachine
url = ../android/StateMachine
[submodule "test2"]
path = test2
url = ../android/test2
[submodule "test-annotation"]
path = test2
url = ../android/test-annotation
wink@ic2d1:$ git submodule init
wink@ic2d1:$ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
That's not what I expected according to the documentation I was
expecting .git/config to now contain the [submodule "xxx"] sections
from .gitmodules? But maybe I've got to "submodule add" first or ...
Well, this isn't getting me anywhere so Daniel, I hope that gives
you some insight from a newbies point of view.
My first comment is that needs to be some examples in git submodule help.
Second, I'd suggest .gitmodules be called .gitsubmodules and that
the documentation have a related name. I went into the git/Documentation
directory in my clone of git and looked for "find . -iname '*sub*' and
the only relevant the files were for git-submodule I see no reason for there
not be a a .gitsubmodule. Actually, at the moment I see no reason for
this file at all, but that will probably become apparent soon:)
Note, my git current version is:
wink@ic2d1:$ git --version
git version 1.5.3.5.622.g6fd7a
I've cloned git and built locally so I can change to what ever version
is appropriate. For now I'll search around on the web
Thanks,
Wink Saville
^ permalink raw reply
* Re: [PATCH 2/2] Add support for URLs to git-apply
From: Junio C Hamano @ 2007-12-09 22:54 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Mike Hommey, git
In-Reply-To: <475C5869.4080900@op5.se>
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.
Note that I said my "initial" impression. I reserve the right to change
my mind, as always ;-)
^ permalink raw reply
* Re: [PATCH 2/2] Add support for URLs to git-apply
From: Andreas Ericsson @ 2007-12-09 21:04 UTC (permalink / raw)
To: Mike Hommey; +Cc: git, Junio C Hamano
In-Reply-To: <1197194672-28568-2-git-send-email-mh@glandium.org>
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 :)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: dmalloc and leaks in git
From: Linus Torvalds @ 2007-12-09 20:57 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910712081253t7cd43f87o6001f32fddc01565@mail.gmail.com>
On Sat, 8 Dec 2007, Jon Smirl wrote:
>
> But using dmalloc shows a pervasive problem, none of the git commands
> are cleaning up after themselves. For example I ran a simple command,
> git-status, and thousands of objects were not freed.
One thing to do is to use a better reporting tool.
For example, if you use
valgrind --tool=massif --heap=yes ...
it will generate a postscript file with the allocation history as a graph
of the different allocators in different colors etc. That would likely
show where the big users come from..
Linus
^ permalink raw reply
* Re: [PATCH 0/2] [RFT] git-svn: more efficient revision -> commit mapping
From: Harvey Harrison @ 2007-12-09 20:56 UTC (permalink / raw)
To: Eric Wong; +Cc: Junio C Hamano, git
In-Reply-To: <1197185262-16765-1-git-send-email-normalperson@yhbt.net>
On Sat, 2007-12-08 at 23:27 -0800, Eric Wong wrote:
> This is very lightly tested, but describes the format I described in:
>
> http://article.gmane.org/gmane.comp.version-control.git/67126
>
> (more in the commit messages)
>
> I'll be out of town the next few days and I'm not sure how much I'll be
> able to follow up on it while I'm gone. Please test, especially if
> you're dealing with a repository where large .rev_db files are a
> problem.
>
> Junio: not intended for master just yet, but if you hear nothing but
> good things about it, feel free :)
Preliminary tests against the gcc repo are going swimmingly.
Successful git svn rebase against trunk, doing a full git svn fetch
now to build rev_maps for all svn branches/tags. At halfway through
space has decreased from ~2GB to 17MB for about half of the needed
metadata.
Cheers,
Harvey
^ permalink raw reply
* Re: [PATCH] Restore ls-remote reference pattern matching
From: Junio C Hamano @ 2007-12-09 20:26 UTC (permalink / raw)
To: Sergey Vlasov; +Cc: git, Eyvind Bernhardsen
In-Reply-To: <20071209162632.a16bfd6e.vsu@altlinux.ru>
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...
-- >8 --
Subject: [PATCH] Re-fix ls-remote
An earlier attempt in 2ea7fe0 (ls-remote: resurrect pattern limit support) forgot
that the user string can also be a glob. This should finally fix it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-ls-remote.c | 39 +++++++++++++++++++++------------------
1 files changed, 21 insertions(+), 18 deletions(-)
diff --git a/builtin-ls-remote.c b/builtin-ls-remote.c
index e5d670a..c2caeea 100644
--- a/builtin-ls-remote.c
+++ b/builtin-ls-remote.c
@@ -7,30 +7,22 @@ static const char ls_remote_usage[] =
"git-ls-remote [--upload-pack=<git-upload-pack>] [<host>:]<directory>";
/*
- * pattern is a list of tail-part of accepted refnames. Is there one
- * among them that is a suffix of the path? Directory boundary must
- * be honored when checking this match. IOW, patterns "master" and
- * "sa/master" both match path "refs/hold/sa/master". On the other
- * hand, path "refs/hold/foosa/master" is matched by "master" but not
- * by "sa/master".
+ * Is there one among the list of patterns that match the tail part
+ * of the path?
*/
-
static int tail_match(const char **pattern, const char *path)
{
- int pathlen;
const char *p;
+ char pathbuf[PATH_MAX];
- if (!*pattern)
+ if (!pattern)
return 1; /* no restriction */
- for (pathlen = strlen(path); (p = *pattern); pattern++) {
- int pfxlen = pathlen - strlen(p);
- if (pfxlen < 0)
- continue; /* pattern is longer, will never match */
- if (strcmp(path + pfxlen, p))
- continue; /* no tail match */
- if (!pfxlen || path[pfxlen - 1] == '/')
- return 1; /* fully match at directory boundary */
+ if (snprintf(pathbuf, sizeof(pathbuf), "/%s", path) > sizeof(pathbuf))
+ return error("insanely long ref %.*s...", 20, path);
+ while ((p = *(pattern++)) != NULL) {
+ if (!fnmatch(p, pathbuf, 0))
+ return 1;
}
return 0;
}
@@ -77,12 +69,23 @@ int cmd_ls_remote(int argc, const char **argv, const char *prefix)
usage(ls_remote_usage);
}
dest = arg;
+ i++;
break;
}
if (!dest)
usage(ls_remote_usage);
- pattern = argv + i + 1;
+
+ if (argv[i]) {
+ int j;
+ pattern = xcalloc(sizeof(const char *), argc - i + 1);
+ for (j = i; j < argc; j++) {
+ int len = strlen(argv[j]);
+ char *p = xmalloc(len + 3);
+ sprintf(p, "*/%s", argv[j]);
+ pattern[j - i] = p;
+ }
+ }
remote = nongit ? NULL : remote_get(dest);
if (remote && !remote->url_nr)
die("remote %s has no configured URL", dest);
--
1.5.3.7-1142-gbb4e
^ permalink raw reply related
* [Resend PATCH] git-send-email.perl: Really add angle brackets to In-Reply-To if necessary
From: Mike Hommey @ 2007-12-09 19:58 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <8663z7tznv.fsf@blue.stonehenge.com>
3803bcea tried to fix this, but it only adds the branckes when the given
In-Reply-To begins and ends with whitespaces. It also didn't do anything
to the --in-reply-to argument.
Signed-off-by: Mike Hommey <mh@glandium.org>
---
Randal L. Schwartz wrote:
> Oh, you don't need to \ the < and > though. Cleans it up a bit
> if you get rid of those.
Doh', I forgot to remove them. Here is a cleaned out patch.
git-send-email.perl | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 76baa8e..c0e1dd3 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -367,10 +367,11 @@ if ($thread && !defined $initial_reply_to && $prompting) {
} while (!defined $_);
$initial_reply_to = $_;
- $initial_reply_to =~ s/^\s+<?/</;
- $initial_reply_to =~ s/>?\s+$/>/;
}
+$initial_reply_to =~ s/^\s*<?/</;
+$initial_reply_to =~ s/>?\s*$/>/;
+
if (!defined $smtp_server) {
foreach (qw( /usr/sbin/sendmail /usr/lib/sendmail )) {
if (-x $_) {
--
1.5.3.7
^ permalink raw reply related
* Re: How-to combine several separate git repos?
From: Daniel Barkalow @ 2007-12-09 19:55 UTC (permalink / raw)
To: Wink Saville; +Cc: Alex Riesen, git
In-Reply-To: <475C3E25.30704@saville.com>
On Sun, 9 Dec 2007, Wink Saville wrote:
> 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?
I think that submodules do what you want. And they may not be ready for
neophytes to just use, but they're ready for neophytes to try using and
tell us where things get confused. That is, I don't think git developers
know of anything still wrong with submodules, so we need people to try
using them and say "I can't use submodules now because...". Or, of course,
the code might be fine now and the discussion just too intimidating.
In any case, if you create a new repository, and fetch stuff into it, and
don't push stuff back, you can't screw up the original (obviously), so it
should be safe and possibly informative to play around with submodules.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] git-send-email.perl: Really add angle brackets to In-Reply-To if necessary
From: Randal L. Schwartz @ 2007-12-09 19:51 UTC (permalink / raw)
To: David Kastrup; +Cc: Junio C Hamano, Mike Hommey, git
In-Reply-To: <85lk83r6qq.fsf@lola.goethe.zz>
>>>>> "David" == David Kastrup <dak@gnu.org> writes:
David> How is that supposed to differ from Mike's patch?
Now that I've seen it, not a bit. Sorry, was solving the problem that had
already been solved, in a slightly different way.
Oh, you don't need to \ the < and > though. Cleans it up a bit
if you get rid of those.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ 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