* [PATCH] git-commit: Having $GIT_COMMITTER_NAME implies -s
From: Andreas Ericsson @ 2005-11-16 23:38 UTC (permalink / raw)
To: git
I've been trying, in vain, to tell my colleagues to use the -s flag.
With this patch I can at least fix up their .profile's myself.
Signed-off-by: Andreas Ericsson <ae@op5.se>
---
git-commit.sh | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
applies-to: a2fe76123d6f5b835d3312a70a02ed4d07e25f8e
d32c78570e25a9718721937b1ee9051e950ad1fd
diff --git a/git-commit.sh b/git-commit.sh
index 41955e8..ff9502c 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -134,8 +134,7 @@ then
cat "$GIT_DIR/MERGE_MSG"
fi | git-stripspace >"$GIT_DIR"/COMMIT_EDITMSG
-case "$signoff" in
-t)
+if [ "$signoff" = t -o "$GIT_COMMITTER_NAME" ]; then
{
echo
git-var GIT_COMMITTER_IDENT | sed -e '
@@ -143,8 +142,7 @@ t)
s/^/Signed-off-by: /
'
} >>"$GIT_DIR"/COMMIT_EDITMSG
- ;;
-esac
+fi
if [ -f "$GIT_DIR/MERGE_HEAD" ]; then
echo "#"
---
0.99.9.GIT
^ permalink raw reply related
* [PATCH] daemon.c: fix arg parsing bugs
From: Andreas Ericsson @ 2005-11-16 23:38 UTC (permalink / raw)
To: git
Allow --init-timeout and --timeout to be specified without falling
through to usage().
Make sure openlog() is called even if implied by --inetd, or messages
will be sent to wherever LOG_USER ends up.
Signed-off-by: Andreas Ericsson <ae@op5.se>
---
daemon.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
applies-to: 1e3fcf60526c196a46433e6947c9104ca236f230
83a3edea8623834fd7827f80cad2af4927f5a19e
diff --git a/daemon.c b/daemon.c
index e184752..2b81152 100644
--- a/daemon.c
+++ b/daemon.c
@@ -594,6 +594,7 @@ int main(int argc, char **argv)
}
if (!strcmp(arg, "--inetd")) {
inetd_mode = 1;
+ log_syslog = 1;
continue;
}
if (!strcmp(arg, "--verbose")) {
@@ -602,7 +603,6 @@ int main(int argc, char **argv)
}
if (!strcmp(arg, "--syslog")) {
log_syslog = 1;
- openlog("git-daemon", 0, LOG_DAEMON);
continue;
}
if (!strcmp(arg, "--export-all")) {
@@ -611,9 +611,11 @@ int main(int argc, char **argv)
}
if (!strncmp(arg, "--timeout=", 10)) {
timeout = atoi(arg+10);
+ continue;
}
if (!strncmp(arg, "--init-timeout=", 15)) {
init_timeout = atoi(arg+15);
+ continue;
}
if (!strcmp(arg, "--")) {
ok_paths = &argv[i+1];
@@ -626,9 +628,11 @@ int main(int argc, char **argv)
usage(daemon_usage);
}
+ if (log_syslog)
+ openlog("git-daemon", 0, LOG_DAEMON);
+
if (inetd_mode) {
fclose(stderr); //FIXME: workaround
- log_syslog = 1;
return execute();
}
---
0.99.9.GIT
^ permalink raw reply related
* Re: A case for tailor
From: Matthias Urlichs @ 2005-11-16 23:40 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0511151931001.1157@wbgn013.biozentrum.uni-wuerzburg.de>
Hi, Johannes Schindelin wrote:
> Possible explanation: at some early stage, the trunk was named "trunk",
> but somehow (don´t ask me how, I am a fan of git, not svn) renamed to
> "head".
Well, you *could* use "-T trunk" to import the first part, ^C when it
starts complaining about 'head', duplicate the last line of .git/svn2git
(incrementing the SVN change number), and continue with "-T head".
That hackery sortof depends on Upstream not changing anything *else* while
renaming 'trunk' to 'head' ...
Of course, the second possibility is to allow patterns as prefixes, drop
the distinction of "trunk" and "branch", and store the refs as full
paths under .git/refs/heads/**. You're welcome to submit a patch; please
don't forget backwards compatibility for those poor souls who need to do
incremental imports. ;-)
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Got a dictionary? I want to know the meaning of life.
^ permalink raw reply
* Re: [PATCH] Fix git_config_set() for mean cases
From: Matthias Urlichs @ 2005-11-16 23:26 UTC (permalink / raw)
To: git
In-Reply-To: <7vhdac738c.fsf@assigned-by-dhcp.cox.net>
Hi, Junio C Hamano wrote:
> Why do you spell apostrophe with 0xb4 not ASCII 0x27?
Because on German keyboards these two characters are right next to each
other, I'd suspect...
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
"A horrible little boy came up to me and said, `You know in your book
The Martian Chronicles?' I said, `Yes?' He said, `You know where you
talk about Deimos rising in the East?' I said, `Yes?' He said `No.'
-- So I hit him."
-- attributed to Ray Bradbury
^ permalink raw reply
* Re: recent patch breaks the build ?
From: Johannes Schindelin @ 2005-11-16 23:25 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: Andrew Wozniak, Junio C Hamano, git
In-Reply-To: <20051116203334.GA3968@reactrix.com>
Hi,
On Wed, 16 Nov 2005, Nick Hengeveld wrote:
> On Wed, Nov 16, 2005 at 02:47:56PM -0500, Andrew Wozniak wrote:
>
> > Unfortunately, now there are other failures:
> >
> > gcc -o http-push.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>'
> > http-push.c
> > http-push.c: In function `start_mkcol':
> > http-push.c:479: `CURLOPT_HTTPGET' undeclared (first use in this
> > function)
>
> http-push requires a curl option that looks like it was added around
> version 7.8.1. If you have the option to upgrade your version of curl,
> it should fix the problem. You can also disable building http-push but
> keep http-fetch by defining NO_EXPAT.
It was 7.8.1. I checked. You might want to add this somewhere:
#if LIBCURL_VERSION_NUM < 0x070801
#error http-push needs curl >= 7.8.1 (because of CURLOPT_HTTPGET)
#endif
I tried quite a few things to work around it. Alas, I am now convinced
that no set of option setting does exactly the same thing as
CURLOPT_HTTPGET for a specific curl version < 7.8.1 (the one I tested
with).
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] git email submissions
From: Matthias Urlichs @ 2005-11-16 23:20 UTC (permalink / raw)
To: git
In-Reply-To: <437B73E2.3080903@pobox.com>
Hi, Jeff Garzik wrote:
> Smarter programs would send the overall description and pack file as
> "[patch 0/N]", and then post the for-review patches in separate emails
> as "[patch M/N]".
So you want to send the stuff twice? Ouch.
Seriously: We can mail patches, and we can re-base our changes.
Anything that's not covered by this is inherently complicated, such that
specifying the starting point(s) of a git-send-pack-mail invocation needs
to be handled by a program, else we *will* get *lots* of pilot errors.
Surprise: We already have a solution: host your archive someplace
and let git push+fetch handle everything.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Alan Turing thought about criteria to settle the question of whether
machines can think, a question of which we now know that it is about
as relevant as the question of whether submarines can swim.
-- Dijkstra
^ permalink raw reply
* Re: git-pack-redundant returns the most containing pack
From: Lukas Sandström @ 2005-11-16 23:23 UTC (permalink / raw)
To: git; +Cc: Alex Riesen, Lukas Sandström
In-Reply-To: <20051116230956.GA21444@steel.home>
Alex Riesen wrote:
> ...which very confusing: "git-repack -a -d" leaves the repository with
> exactly the same packs as before, by creating a super-pack, and then
> happily removing it, because pack-redundant returns the newly created
> pack!
>
> So, even if it is logically correct, it's hardly useful in practice.
>
That's bad. Your new pack should contain some objects not present in
the older packfiles and thus it shouldn't be removed, unless there
were no new objects to pack.
If no new objects were packed, the sum of the old packs might be smaller
than the new superpack, or the old packs could contain unreachable objects,
which makes git-pack-redundant unable to detect that they should be removed.
Could you try updating to the latest snapshot? There was a bug in a
list handling function which was fixed recently, perhaps your problem
is related.
^ permalink raw reply
* Re: [PATCH] Fix git_config_set() for mean cases
From: Johannes Schindelin @ 2005-11-16 23:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhdac738c.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 16 Nov 2005, Junio C Hamano wrote:
> Why do you spell apostrophe with 0xb4 not ASCII 0x27? Not that
> it matters because I'll apply it with -u flag to git-am to
> convert it to UTF-8 in the log message, but I am just curious.
Efficiency. I often do the patches on my iBook w/ German keyboard. The
apostrophe 0xb4 (upward accent) is just beside my back space key, i.e. in
a favorite location for my right little finger.
OTOH, 0x27 (the real apostrophe) is just beside the Enter key, which is
the only key Apple made too small. Way too small. So I try to avoid that
key, since I hit it by accident already too often. Furthermore, on the
German keyboard you have to hold Shift down for the apostrophe, while you
do not for 0xb4.
Besides, the character is there, so why not use it? ;-)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 3/3] git --help COMMAND brings up the git-COMMAND man-page., take two
From: H. Peter Anvin @ 2005-11-16 23:17 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, git
In-Reply-To: <437BBDD6.40809@op5.se>
Andreas Ericsson wrote:
>
> True, but it's possible to have a 180 iq and still know nothing about
> programming. Anyhow, I sent the first patch too, so please blame me if
> anyone. If I was hoping to be admired I'd go play video-games with my 6
> year old cousin.
>
The point was: mistakes happen. No point in arguing about whose fault
it was.
-hpa
^ permalink raw reply
* Re: [PATCH 3/3] git --help COMMAND brings up the git-COMMAND man-page., take two
From: Andreas Ericsson @ 2005-11-16 23:16 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Junio C Hamano, git
In-Reply-To: <437BAA5F.5060608@zytor.com>
H. Peter Anvin wrote:
> Junio C Hamano wrote:
>
>> "H. Peter Anvin" <hpa@zytor.com> writes:
>>
>>> The way this made it into the actual tree was to call /usr/bin/man,
>>> but still using execlp(). This is clearly bogus. There *ARE* good
>>> reasons to use PATH resolutions for this, since man is one of the
>>> interactive commands the user may want to wrapper.
>>
>>
>> Oh, that was my call, so please do not blame Andreas.
>> I just sent out a proposed patch to address all the points
>> discussed on the list for the last several hours.
>>
>
> FWIW, I rarely blame people for bad code; *everyone* does something
> stupid every now and then, and for most of us, far more often than that.
> "This piece of code is stupid" != "the author of this piece of code is
> stupid", a distinction which unfortunately often gets lost.
>
True, but it's possible to have a 180 iq and still know nothing about
programming. Anyhow, I sent the first patch too, so please blame me if
anyone. If I was hoping to be admired I'd go play video-games with my 6
year old cousin.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* git-pack-redundant returns the most containing pack
From: Alex Riesen @ 2005-11-16 23:09 UTC (permalink / raw)
To: Lukas Sandström; +Cc: git
...which very confusing: "git-repack -a -d" leaves the repository with
exactly the same packs as before, by creating a super-pack, and then
happily removing it, because pack-redundant returns the newly created
pack!
So, even if it is logically correct, it's hardly useful in practice.
^ permalink raw reply
* Re: Sourceforge doesn't like git cvsimport
From: Johannes Schindelin @ 2005-11-16 23:05 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Git Mailing List
In-Reply-To: <437B7416.8030704@zytor.com>
Hi,
On Wed, 16 Nov 2005, H. Peter Anvin wrote:
> : tazenda 23 ; telnet cvs.sourceforge.net 2401
> Trying 66.35.250.207...
> Connected to cvs.sourceforge.net.
> Escape character is '^]'.
> BEGIN AUTH REQUEST
> /cvsroot/bochs
> anonymous
>
> END AUTH REQUEST
> cvs [pserver aborted]: descramble: unknown scrambling method
> Connection closed by foreign host.
I track a few projects from sourceforge. In the last two weeks they had
serious problems, I often could not connect for more than a day. (And yes,
I mean the anonymous CVS gateway, not the SSH which is only available to
developers of that particular project.)
Usually I am lucky at 3am (+0200).
Ciao,
Dscho
^ permalink raw reply
* [PATCH] git-apply: fail if a patch cannot be applied.
From: Junio C Hamano @ 2005-11-16 22:15 UTC (permalink / raw)
To: git; +Cc: Catalin Marinas, Karl Hasselström
In-Reply-To: <7vr79g8mys.fsf@assigned-by-dhcp.cox.net>
Recently we fixed 'git-apply --stat' not to barf on a binary
differences. But it accidentally broke the error detection when
we actually attempt to apply them.
This commit fixes the problem and adds test cases.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Junio C Hamano <junkio@cox.net> writes:
> Catalin Marinas <catalin.marinas@gmail.com> writes:
>
>> ... When pushing a patch, if
>> a merge is needed (like in your case, the base of the foo patch has
>> changed), StGIT first tries "git-diff-tree | git-apply" for speed
>> reasons. If this fails, it falls back to a three-way merge.
>
> I think many of the scripts rely on git-apply failing reliably
> for unapplicable patches. I'll do a new test script in git.git/t
> and if it fails on binary files, try to fix it today.
apply.c | 11 ++++---
t/t4103-apply-binary.sh | 78 +++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 85 insertions(+), 4 deletions(-)
create mode 100644 t/t4103-apply-binary.sh
applies-to: 4dda103301d7b70ec6e6e361d4a8d2cac24eccb4
92927ed0aac56a86f85049215791fcd106af4b62
diff --git a/apply.c b/apply.c
index 590adc6..a002e15 100644
--- a/apply.c
+++ b/apply.c
@@ -891,7 +891,7 @@ static int parse_chunk(char *buffer, uns
patchsize = parse_single_patch(buffer + offset + hdrsize, size - offset - hdrsize, patch);
- if (!patchsize && !metadata_changes(patch)) {
+ if (!patchsize) {
static const char binhdr[] = "Binary files ";
if (sizeof(binhdr) - 1 < size - offset - hdrsize &&
@@ -899,9 +899,12 @@ static int parse_chunk(char *buffer, uns
sizeof(binhdr)-1))
patch->is_binary = 1;
- if (patch->is_binary && !apply && !check)
- ;
- else
+ /* Empty patch cannot be applied if:
+ * - it is a binary patch or
+ * - metadata does not change and is not a binary patch.
+ */
+ if ((apply || check) &&
+ (patch->is_binary || !metadata_changes(patch)))
die("patch with only garbage at line %d", linenr);
}
diff --git a/t/t4103-apply-binary.sh b/t/t4103-apply-binary.sh
new file mode 100644
index 0000000..948d5b5
--- /dev/null
+++ b/t/t4103-apply-binary.sh
@@ -0,0 +1,78 @@
+#!/bin/sh
+#
+# Copyright (c) 2005 Junio C Hamano
+#
+
+test_description='git-apply handling binary patches
+
+'
+. ./test-lib.sh
+
+# setup
+
+cat >file1 <<EOF
+A quick brown fox jumps over the lazy dog.
+A tiny little penguin runs around in circles.
+There is a flag with Linux written on it.
+A slow black-and-white panda just sits there,
+munching on his bamboo.
+EOF
+cat file1 >file2
+cat file1 >file4
+
+git-update-index --add --remove file1 file2 file4
+git-commit -m 'Initial Version' 2>/dev/null
+
+git-checkout -b binary
+tr 'x' '\0' <file1 >file3
+cat file3 >file4
+git-add file2
+tr '\0' 'v' <file3 >file1
+rm -f file2
+git-update-index --add --remove file1 file2 file3 file4
+git-commit -m 'Second Version'
+
+git-diff-tree -p master binary >B.diff
+git-diff-tree -p -C master binary >C.diff
+
+test_expect_success 'stat binary diff -- should not fail.' \
+ 'git-checkout master
+ git-apply --stat --summary B.diff'
+
+test_expect_success 'stat binary diff (copy) -- should not fail.' \
+ 'git-checkout master
+ git-apply --stat --summary C.diff'
+
+test_expect_failure 'check binary diff -- should fail.' \
+ 'git-checkout master
+ git-apply --check B.diff'
+
+test_expect_failure 'check binary diff (copy) -- should fail.' \
+ 'git-checkout master
+ git-apply --check C.diff'
+
+# Now we start applying them.
+
+test_expect_failure 'apply binary diff -- should fail.' \
+ 'git-checkout master
+ git-apply B.diff'
+
+git-reset --hard
+
+test_expect_failure 'apply binary diff -- should fail.' \
+ 'git-checkout master
+ git-apply --index B.diff'
+
+git-reset --hard
+
+test_expect_failure 'apply binary diff (copy) -- should fail.' \
+ 'git-checkout master
+ git-apply C.diff'
+
+git-reset --hard
+
+test_expect_failure 'apply binary diff (copy) -- should fail.' \
+ 'git-checkout master
+ git-apply --index C.diff'
+
+test_done
---
0.99.9.GIT
^ permalink raw reply related
* Re: [PATCH 3/3] git --help COMMAND brings up the git-COMMAND man-page., take two
From: H. Peter Anvin @ 2005-11-16 21:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbr0law3z.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> "H. Peter Anvin" <hpa@zytor.com> writes:
>
>>The way this made it into the actual tree was to call /usr/bin/man, but
>>still using execlp(). This is clearly bogus. There *ARE* good reasons
>>to use PATH resolutions for this, since man is one of the interactive
>>commands the user may want to wrapper.
>
> Oh, that was my call, so please do not blame Andreas.
> I just sent out a proposed patch to address all the points
> discussed on the list for the last several hours.
>
FWIW, I rarely blame people for bad code; *everyone* does something
stupid every now and then, and for most of us, far more often than that.
"This piece of code is stupid" != "the author of this piece of code is
stupid", a distinction which unfortunately often gets lost.
I say "rarely", because there are of course a small number of people who
*consistently* produce crap. However, even they occationally produce
something useful -- it's just not that often, and one has to carefully
review it first. With sufficient thrust pigs fly just fine[*], and
heck, even RBJ even occationally says something correct.
-hpa
[*] It is, however, not necessarily a good idea. It can be dangerous
for the people on the ground, and annoys the pig.
^ permalink raw reply
* Re: fix git-pack-redundant crashing sometimes
From: Lukas Sandström @ 2005-11-16 21:37 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds, Alex Riesen, junkio, Lukas Sandström
In-Reply-To: <Pine.LNX.4.64.0511151552400.11232@g5.osdl.org>
Linus Torvalds wrote:
>
> On Tue, 15 Nov 2005, Alex Riesen wrote:
>
>>Sorry, it doesn't. The code loops here:
>>
>>401 /* find the permutations which contain all missing objects */
>>402 perm_all = perm = get_all_permutations(non_unique);
>
>
> Looks like the whole thing is exponential.
>
Slightly less, but not far from.
> A good way to do sane pack handling is to keep a _sorted_ list of all
> objects each pack has. At that point it becomes much easier to see which
> objects only exist in one particular pack.
>
git-pack-redundant already does this.
> The sorting itself is O(nlogn), and the "does this pack have any unique
> objects" (or "is this pack a superset of all other packs") question should
> then be O(n).
>
Ah, but the question is: "Does this set of packs contain a superset of
all objects available in packfiles?" The answer to the question for a
certain set is indeed O(n), but the number of sets which have to be tested
are ~ O(e**n). (Where n is the number of non-unique packs.)
/Lukas
^ permalink raw reply
* Re: Disallow empty pattern in "git grep"
From: Junio C Hamano @ 2005-11-16 21:18 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0511160934480.13959@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Yeah, maybe we should allow an empty pattern, and just check the number of
> arguments instead.
I think this patch is OK; I do not see a reason for wanting an
empty pattern.
^ permalink raw reply
* Re: fix git-pack-redundant crashing sometimes
From: Alex Riesen @ 2005-11-16 21:11 UTC (permalink / raw)
To: Lukas Sandström; +Cc: git, junkio
In-Reply-To: <437A6B8A.8060905@etek.chalmers.se>
Lukas Sandström, Wed, Nov 16, 2005 00:13:14 +0100:
> After giving it a quick look, I don't think it locks up. It is just horribly
> slow. get_all_permutations returns (nice ASCII-art follows)
>
> ___n___
> \
> \ ____1____
> n! * / k!(n-k)!
> /______
> k=1
>
> permutations, which for your case (22 packs) adds up to 4194303.
>
> I'll look into an optimization so we won't have to call is_superset
> for every one of them.
>
> OTOH, I might be wrong and it could very well be an infinite loop.
> Mind running it over the night? I won't look further into this in
> 20 hours or so anyway.
It doesn't lock up:
$ time git-pack-redundant --all --alt-odb
.git/objects/pack/pack-3c5133604508466855453f3e609428f4bbba9131.idx
.git/objects/pack/pack-3c5133604508466855453f3e609428f4bbba9131.pack
...
real 24m55.277s
user 24m50.778s
sys 0m0.582s
Now I shall be called "too impatient", perhaps?
^ permalink raw reply
* Re: [PATCH 1/3] C implementation of the 'git' program, take two.
From: Alex Riesen @ 2005-11-16 21:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Linus Torvalds, Andreas Ericsson, git
In-Reply-To: <Pine.LNX.4.63.0511160316510.14820@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin, Wed, Nov 16, 2005 03:18:05 +0100:
> > Then, you just prepend it to the PATH, with a : in between (and if the
> > pathname has a ":" in it, tough, there's nothing we can do about it).
>
> You mean like "c:/cygwin/git"? Yes, I know, the default is
> "/cygdrive/c/cygwin/git", but there are people out there with ":" in their
> pathname.
>
and you can't possibly be hinting at "\" as path element separator...
Cygwin rewrites values in PATH (well, poorly: there are things like
"z:.", which admins of another stupid thing, novel netware, are so much
fond of).
^ permalink raw reply
* Re: [PATCH] Fix git_config_set() for mean cases
From: H. Peter Anvin @ 2005-11-16 20:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vhdac738c.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>
>>There were problems when the keys´ case didn´t match, and also when the
>>section was in the same line as the key.
>>
>>This patch also adds a test case, so you see that it works now.
>>
>>Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
>
>
> Why do you spell apostrophe with 0xb4 not ASCII 0x27? Not that
> it matters because I'll apply it with -u flag to git-am to
> convert it to UTF-8 in the log message, but I am just curious.
>
Not to mention the fact that it's just plain wrong -- U+00B4 is accute
accent, not apostrophe.
-hpa
^ permalink raw reply
* Re: [QUESTION] Access to a huge GIT repository.
From: Junio C Hamano @ 2005-11-16 20:35 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90511161201h54c5fa73l20b5dcf3b5c19399@mail.gmail.com>
Martin Langhoff <martin.langhoff@gmail.com> writes:
> On 11/17/05, Junio C Hamano <junkio@cox.net> wrote:
>> The underlying network transfer program, 'git-clone-pack', can
>> be told to clone only specified branches. If somebody is
>> interested, updating the 'git-clone' wrapper to use it should
>> not be too hard -- obviously this needs to be done for other
>> transports as well, though.
>
> cg-clone already does this.
Yes, but it can be improved. It does fetch-pack for git native
transports, which means the receiving end expands the pack. I
think we would either need to teach cg-clone to tell cg-fetch
that it is cloning and invoke git-clone-pack, or add an optional
"do not expand" option to git-fetch-pack (git-clone-pack always
keeps the downloaded pack unexpanded). Huge pack transfer
spends long time on the downloader side unpacking the pack.
> If you just pull tagrefs and all the objects needed for them, chances
> are you'll get the whole repo anyway ;-)
Yes, that's why we changed ls-remote to report the magic ^{}
entries and it is used in cg-fetch::fetch_tags.
^ permalink raw reply
* Re: recent patch breaks the build ?
From: Nick Hengeveld @ 2005-11-16 20:33 UTC (permalink / raw)
To: Andrew Wozniak; +Cc: Junio C Hamano, git
In-Reply-To: <437B8CEC.8040002@mc.com>
On Wed, Nov 16, 2005 at 02:47:56PM -0500, Andrew Wozniak wrote:
> Unfortunately, now there are other failures:
>
> gcc -o http-push.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>'
> http-push.c
> http-push.c: In function `start_mkcol':
> http-push.c:479: `CURLOPT_HTTPGET' undeclared (first use in this
> function)
http-push requires a curl option that looks like it was added around
version 7.8.1. If you have the option to upgrade your version of curl,
it should fix the problem. You can also disable building http-push but
keep http-fetch by defining NO_EXPAT.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: [PATCH] symref support for import scripts
From: Junio C Hamano @ 2005-11-16 20:26 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git
In-Reply-To: <20051116195737.GE27727@kiste.smurf.noris.de>
Matthias Urlichs <smurf@smurf.noris.de> writes:
> The only thing we want to do with HEAD, in order to accomplish that,
> is to find the SHA1 it points to, before and after the import.
> No use of git-symbolic-ref is necessary for that.
True. 'git-rev-parse --verify HEAD^0' would be sufficient.
^ permalink raw reply
* Re: recent patch breaks the build ?
From: Junio C Hamano @ 2005-11-16 20:25 UTC (permalink / raw)
To: git
In-Reply-To: <437B8CEC.8040002@mc.com>
Andrew Wozniak <awozniak@mc.com> writes:
> Unfortunately, now there are other failures:
> ...
> I grep'd for these defines and they are nowhere to be found! Is some
> other package needed to resolve these undefines on my RH7.2 build host?
Probably. Maybe you can look at INSTALL and report missing
dependencies? Also the top of the Makefile (huge ugly comment
section).
^ permalink raw reply
* Re: [PATCH] Fix git_config_set() for mean cases
From: Junio C Hamano @ 2005-11-16 20:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0511161045310.16596@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> There were problems when the keys´ case didn´t match, and also when the
> section was in the same line as the key.
>
> This patch also adds a test case, so you see that it works now.
>
> Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Why do you spell apostrophe with 0xb4 not ASCII 0x27? Not that
it matters because I'll apply it with -u flag to git-am to
convert it to UTF-8 in the log message, but I am just curious.
^ permalink raw reply
* Re: recent patch breaks the build ?
From: Andreas Ericsson @ 2005-11-16 20:18 UTC (permalink / raw)
To: Andrew Wozniak; +Cc: git
In-Reply-To: <437B8CEC.8040002@mc.com>
Andrew Wozniak wrote:
> Yes, that suggestion worked - it is similar to other code fragments and
> ifdefs within the same file.
>
> Unfortunately, now there are other failures:
>
> gcc -o http-push.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>'
> http-push.c
> http-push.c: In function `start_mkcol':
> http-push.c:479: `CURLOPT_HTTPGET' undeclared (first use in this function)
>
....
> I grep'd for these defines and they are nowhere to be found! Is some
> other package needed to resolve these undefines on my RH7.2 build host?
>
curl and curl-devel. Or you can build with
make NO_CURL=YesPlease
which just means you won't have http and https transports available.
This shouldn't be much of a problem on a server though.
> I'm really surprised that the unmodified tarball source fails to build.
> Just curious, is the git project rebuilt on a "nightly" basis to verify
> recent patches?
>
I have no idea, but since it's a developer tool in pre-1.0 I think the
general consensus is that user-friendliness in the build-process comes
somewhere between "not so important" and "what? users? oh, those living
in the *other* land!"
Perhaps you should try the RPM's at
http://www.kernel.org/pub/software/scm/git-core/ ?
If nothing else it will tell you what other packages you need.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ 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