On Wed, Jul 06, 2005 at 12:42:20AM +0200, Sam Ravnborg wrote:
I receive the following error:
git-update-cache: symbol lookup error: git-update-cache: undefined
symbol: deflateBound
open(/usr/lib/libz.so.1, O_RDONLY)= 3
This is the reason.
For a strange reason when
The function calls opendir() without a matching closedir().
Signed-off-by: Junio C Hamano [EMAIL PROTECTED]
---
sha1_file.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
7a47797264a0be7955f3422a6e79e3311ab2775f
diff --git a/sha1_file.c b/sha1_file.c
--- a/sha1_file.c
+++
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Here is a patch to add a commify function to cg-Xlib. I'll follow
this up with a patch that uses the new function to commify the
number and size of objects pulled in cg-pull.
Signed-off-by: Frank Sorenson [EMAIL PROTECTED]
Add a commify function
Hi,
Sven Verdoolaege:
to get an idea of what the files may be. Looks like the new perl version
is leaking file descriptors..
Matthias?
That was my mistake, actually.
Thanks for spotting this.
Ouch. For me, the main danger of lots of Python programming is that
I tend not to see
This change is made so that gitk --all produces the same result for
every user irrespective of whether git-rev-parse --all produces
the same result for every user. By using --topo-order rather than
--merge-order this can be guaranteed and the existing (non-timestamp dependent)
behaviour of
This patch introduces a --topo-order switch to git-rev-list.
When this --switch is specified, a minimal topological sort
weaker than the --merge-order sort is applied to the output
list.
The invariant of the resulting list is:
a is reachable from b = ord(b) ord(a)
Signed-off-by: Jon
This patch introduces an in-place topological sort procedure to commit.c.
Given a list of commits, sort_in_topological_order() will perform an in-place
topological sort of that list.
The invariant that applies to the resulting list is:
a reachable from b = ord(b) ord(a)
This invariant
This patch adds a hacky special case to the rev-list main to restore the order
in which
the --merge-order sort algorithm receives arguments.
A subsequent patch will abstract this out more cleanly.
Signed-off-by: Jon Seymour [EMAIL PROTECTED]
---
rev-list.c |5 -
1 files changed, 4
Swap the order of insert_by_date arguments so that it
matches the order of commit_list_insert.
This patch anticipates a future change which will call the
function via a pointer.
Signed-off-by: Jon Seymour [EMAIL PROTECTED]
---
commit.c |8
commit.h |6 +-
epoch.c|
Per a suggestion from Linus, I have introduced the rev_list_fns structure into
rev-list.c
The intent of this change is to make use of a strategy pattern to configure
the behaviour of git-rev-list and so help limit the ever-increasing
proliferation of boolean switches throughout the body of the
The function write_one_ref() is passed the list of refs received
from the other end, which was obtained by directory traversal
under $GIT_DIR/refs; this can contain paths other than what
git-init-db prepares and would fail to clone when there is
such.
Signed-off-by: Junio C Hamano [EMAIL
This patch implements a small tidy up of rev-list.c to reduce
(but not eliminate) the amount of ugliness associated
with the merge_order flag.
Signed-off-by: Jon Seymour [EMAIL PROTECTED]
---
Linus: I decided not to abstract this out as a function
as _too_ much abstraction can be a bad thing
IIRC our strategy was to let the users' umask take care of the
final mode bits. This patch fixes places that deviate from it.
Signed-off-by: Junio C Hamano [EMAIL PROTECTED]
---
apply.c|2 +-
csum-file.c|2 +-
entry.c|4 ++--
init-db.c |2 +-
In message [EMAIL PROTECTED] Linus Torvalds wrote:
If you make it print out its pid and then pause, you can use
ls -l /proc/pid/fd/
to get an idea of what the files may be. Looks like the new perl version
is leaking file descriptors..
It does. In case it's still of interest:
Functions that are useful to other t6xxx testcases are moved into t6000-lib.sh
To use these functions in a test case, use a test-case pre-amble like:
. ./test-lib.sh
. ../t6000-lib.sh # t6xxx specific functions
Signed-off-by: Jon Seymour [EMAIL PROTECTED]
---
This patch series introduces tests
This patch introduces some unit tests for the git-rev-list --bisect
functionality.
Signed-off-by: Jon Seymour [EMAIL PROTECTED]
---
t/t6002-rev-list-bisect.sh | 247
1 files changed, 247 insertions(+), 0 deletions(-)
create mode 100755
This trivial patch removes the semicolon as the sed seperator in the
t/t6000-lib.sh test script
and replaces it with white space. This makes BSD sed(1) much happier.
Signed-off-by: Mark Allen [EMAIL PROTECTED]
Signed-off-by: Jon Seymour [EMAIL PROTECTED]
---
I've applied this to the code that
BUG: cg-clone accepts '_' in git+ssh: URI's, but cg-push does not.
I suggest '_' be added to the allowed character table in send-pack.c
John
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
This test case demonstrates a problem with --merge-order.
A
|
B
|\
C D
|/
E
|
F
git-rev-list --merge-order A B doesn't produce the expected output of
A
B
D
C
E
F
Signed-off-by: Jon Seymour [EMAIL PROTECTED]
---
This patch is known designed to apply on top of:
[PATCH 1/6] Temporary fixup to
This patch passes the test case in the first patch of this series.
Signed-off-by: Jon Seymour [EMAIL PROTECTED]
---
epoch.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
e4f793b932b30a7bee16610e311630515fe88330
diff --git a/epoch.c b/epoch.c
--- a/epoch.c
+++ b/epoch.c
@@ -612,7
On Wed, 6 Jul 2005, Junio C Hamano wrote:
By invitation.
When we are cloning a repository on a local filesystem [...]
Hmm.. Did you test the ssh case?
+case $local_use,$is_local in
+default,f)
+ ;;
It would seem that you don't do anything at all for the non-local
Functions that are useful to other t6xxx testcases are moved into t6000-lib.sh
To use these functions in a test case, use a test-case pre-amble like:
. ./test-lib.sh
. ../t6000-lib.sh # t6xxx specific functions
Signed-off-by: Jon Seymour [EMAIL PROTECTED]
---
t/t6000-lib.sh
This test case demonstrates a problem with --merge-order.
A
|
B
|\
C D
|/
E
|
F
git-rev-list --merge-order A B doesn't produce the expected output of
A
B
D
C
E
F
The problem is fixed by a subsequent patch.
Signed-off-by: Jon Seymour [EMAIL PROTECTED]
---
t/t6001-rev-list-merge-order.sh |
This patch passes the test case introduced by the previous patch.
Signed-off-by: Jon Seymour [EMAIL PROTECTED]
---
epoch.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
6f7f90901ec4aafd12ac4179110b78fc426395cd
diff --git a/epoch.c b/epoch.c
--- a/epoch.c
+++ b/epoch.c
@@ -612,7
This trivial patch removes the semicolon as the sed seperator in the
t/t6000-lib.sh test script
and replaces it with white space. This makes BSD sed(1) much happier.
Signed-off-by: Mark Allen [EMAIL PROTECTED]
Signed-off-by: Jon Seymour [EMAIL PROTECTED]
---
I've applied this to the code that
This patch implements a small tidy up of rev-list.c to reduce
(but not eliminate) the amount of ugliness associated
with the merge_order flag.
Signed-off-by: Jon Seymour [EMAIL PROTECTED]
---
Linus: I decided not to abstract this out as a function
as _too_ much abstraction can be a bad thing
This patch introduces some unit tests for the git-rev-list --bisect
functionality.
Signed-off-by: Jon Seymour [EMAIL PROTECTED]
---
t/t6002-rev-list-bisect.sh | 247
1 files changed, 247 insertions(+), 0 deletions(-)
create mode 100755
git-rev-list --topo-order HEAD HEAD
caused a segmentation violation.
This has now been fixed.
Signed-off-by: Jon Seymour [EMAIL PROTECTED]
---
commit.c | 15 +++
commit.h |3 +++
epoch.h| 13 ++---
rev-list.c |8
4 files changed, 24
This change is made so that gitk --all produces the same result for
every user irrespective of whether git-rev-parse --all produces
the same result for every user. By using --topo-order rather than
--merge-order this can be guaranteed and the existing (non-timestamp dependent)
behaviour of
This patch introduces a --topo-order switch to git-rev-list.
When this --switch is specified, a minimal topological sort
weaker than the --merge-order sort is applied to the output
list.
The invariant of the resulting list is:
a is reachable from b = ord(b) ord(a)
Signed-off-by: Jon
I have re-issued the patches I have created in the last day after checking
that they apply correctly when applied in this order to the
current Linus HEAD (b43d44779bf98977b211256f936d0edda8a9625a)
Introduction of --topo-order and tidy up of rev-list.c
[PATCH 1/13] Temporary fixup to rev-list.c
This patch adds a hacky special case to the rev-list main to restore the order
in which
the --merge-order sort algorithm receives arguments.
A subsequent patch will abstract this out more cleanly.
Signed-off-by: Jon Seymour [EMAIL PROTECTED]
---
rev-list.c |5 -
1 files changed, 4
Per a suggestion from Linus, I have introduced the rev_list_fns structure into
rev-list.c
The intent of this change is to make use of a strategy pattern to configure
the behaviour of git-rev-list and so help limit the ever-increasing
proliferation of boolean switches throughout the body of the
Swap the order of insert_by_date arguments so that it
matches the order of commit_list_insert.
This patch anticipates a future change which will call the
function via a pointer.
Signed-off-by: Jon Seymour [EMAIL PROTECTED]
---
commit.c |8
commit.h |6 +-
epoch.c|
John Ellson [EMAIL PROTECTED] wrote:
BUG: cg-clone accepts '_' in git+ssh: URI's, but cg-push does not.
Right. '_' is illegal in domain names...
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Petr Baudis wrote:
I don't know. Could you give some supporting argumentation, please? Is
it really that hard to read for the Americans without the commas? It is
at least harder to read for me as an European - we don't have any
commas in there,
Hi, Junio C Hamano wrote:
I wanted to have something like this in the past for some reason
I do not exactly remember anymore, but basically it was to
record here is the list of related objects.
One use I'd have for that is regression testing -- collect all IDs in one
bag and then say gitk bad
Horst von Brand wrote:
John Ellson [EMAIL PROTECTED] wrote:
BUG: cg-clone accepts '_' in git+ssh: URI's, but cg-push does not.
Right. '_' is illegal in domain names...
OK, but its legal in the path part of URI's, I believe, and I'm more
bothered by the assymetry between cg-clone and
rpmbuild -ta cogito-0.12.tar.gz fails because cogito.spec.in refers to
.bz2 in its Source: line, instead of to .gz.
This is obviously a trivial patch. Do I need prior approval to send
patches to this group? What is the the significance of
Signed-off-by: Is there a FAQ I should read?
I just updated to the latest git tree, and now get the following when I
try to pull from a ssh repo:
$ git-pull-script [EMAIL PROTECTED]:/public_html/udev.git/
fatal: I don't like '@'. Sue me.
So I drop the @ and then get:
$ git-pull-script someserver.org:/public_html/udev.git/
fatal: I
On Wed, 6 Jul 2005, Greg KH wrote:
I just updated to the latest git tree, and now get the following when I
try to pull from a ssh repo:
$ git-pull-script [EMAIL PROTECTED]:/public_html/udev.git/
fatal: I don't like '@'. Sue me.
So I drop the @ and then get:
$ git-pull-script
On Wed, Jul 06, 2005 at 01:46:27PM -0700, Greg KH wrote:
Ok, below is a patch for this. It works, but then errors out with:
bash: git-upload-pack: command not found
fatal: unexpected EOF
So I'm guessing that I have to convince the server owner to update their
version of git
On Wed, 6 Jul 2005, Greg KH wrote:
Ok, below is a patch for this. It works, but then errors out with:
bash: git-upload-pack: command not found
fatal: unexpected EOF
So I'm guessing that I have to convince the server owner to update their
version of git too?
The easiest way
On Mon, 2005-07-04 at 14:32 +0200, Peter Osterlund wrote:
I agree with the other comments, it's probably not wise to rely on
wiggle, and wiggle sometimes makes a mess. However, it often does the
right thing, and with a configurable merge program and an undo
function, this should not be a
On Wed, Jul 06, 2005 at 01:37:55PM -0700, Linus Torvalds wrote:
On Wed, 6 Jul 2005, Greg KH wrote:
I just updated to the latest git tree, and now get the following when I
try to pull from a ssh repo:
$ git-pull-script [EMAIL PROTECTED]:/public_html/udev.git/
fatal: I don't like
When sed uses \n rather than ; as a separator (for BSD sed(1) compat),
it is cleaner to use a file directly, rather than an environment
variable containing \n characters.
This change changes t/t6000 write to sed.script directly and changes
the other tests to remove knowledge of sed.script.
Signed-off-by: Jon Seymour [EMAIL PROTECTED]
---
Linus: the last test fails with --topo-order at the moment. I haven't
seen your most recent changes, so it may still fail for trivial
reasons even then. If so, I'll post an update.
t/t6003-rev-list-topo-order.sh | 417
This change ensures that git-rev-list --merge-order produces the same result
irrespective of what position the --merge-order argument appears in the argument
list.
Signed-off-by: Jon Seymour [EMAIL PROTECTED]
---
Linus: if you'd prefer to fix this a different way, that's fine by me!
---
On Thu, 7 Jul 2005, Jon Seymour wrote:
Linus: the last test fails with --topo-order at the moment. I haven't
seen your most recent changes, so it may still fail for trivial
reasons even then. If so, I'll post an update.
It passes for me, so I think the SEEN flag thing fixed it.
When we are cloning a repository on a local filesystem, it is
faster to just create a hard linkfarm of .git/object hierarchy
and copy the .git/refs files. By default, the script uses the
clone-pack method, but it can be told with the -l flag to do the
hard linkfarm (falling back on recursive file
Now that duplicates are elided early, there is no need for the
SHOWN flag.
This patch removes the SHOWN flag and its uses from rev-list.c
Signed-off-by: Jon Seymour [EMAIL PROTECTED]
---
rev-list.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
SEEN and VISITED do the same thing.
This change moves the SEEN flag into epoch.h, then replaces
uses of VISITED with SEEN and removes the definition
of the VISITED flag.
The merge-order code needs to clear the SEEN flag
set by the argument parsing to ensure correct
operation. So it clears that
Since --merge-order is the only thing that cares about the rev-list
parse order, change the rev-list list to match the parse order
and remove the corresponding compensating reversal from epoch.c.
Signed-off-by: Jon Seymour [EMAIL PROTECTED]
---
[PATCH] Move SEEN flag into epoch.h, replace use of
Applied the --merge-order, --max-age fix to fix
the --topo-order problem demonstrated by the test
case in the previous patch.
Signed-off-by: Jon Seymour [EMAIL PROTECTED]
---
rev-list.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
8238686fd422959dae50a908b3761aa545be1c4f
diff
Hi,
I've recently posted the following patches, in this order:
These ones are tidy ups:
[PATCH] Remove use of SHOWN flag
[PATCH] Move SEEN flag into epoch.h, replace use of VISITED flag with SEEN flag
[PATCH] Simplification - remove unnecessary list reversal from epoch.c
This series contains a
Linus Torvalds [EMAIL PROTECTED] writes:
On Tue, 5 Jul 2005, Eric W. Biederman wrote:
True but if you can you will get multiple tags with the
same suggested name. So you need so way to find the one you
care about.
I do agree that it would make sense to have a tagger field with the same
Ok, you asked for it:
...the GIT bucket.
jon.
... ducks for cover ...
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 7/6/05, Jon Seymour [EMAIL PROTECTED] wrote:
Ok, you asked for it:
...the GIT bucket.
jon.
... ducks for cover ...
Groan ... as well you should.
My tree has re-appeared now. Thanks to whoever fixed it.
-Tony
-
To unsubscribe from this list: send the line unsubscribe git in
the
58 matches
Mail list logo
