* Re: [PATCH] Glean libexec path from argv[0] for git-upload-pack and git-receive-pack.
From: Steve Haslam @ 2008-07-30 18:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Johannes Sixt
In-Reply-To: <alpine.LSU.1.00.0807302020300.3486@wbgn129.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Wed, 30 Jul 2008, Steve Haslam wrote:
>
>> I think that once git-upload-pack.c et al get the argv[0] path over to
>> setup_path() then there's nothing more to do; setup_path() already uses
>> argv0_path in its list of paths to try. I'm confused to the reference to
>> PATH, though: we're avoiding the PATH environment variable completely.
>>
>
> There is an issue in setting up the argv0_path when Git is called as "git"
> and resolved via the PATH: argv[0] then is literally "git".
>
> And we need argv0_path for other things than just calling programs:
> relative etc/gitconfig and libexecdir.
>
Ah, I see what you meant. And all setup_path() actually does is add to
the end of PATH. I should have understood before.
OK, I will split the patch up and tidy it.
SRH
^ permalink raw reply
* git citool/gui bug
From: Leandro Lucarella @ 2008-07-30 18:53 UTC (permalink / raw)
To: git
Hi! I think I've hit a really silly bug in citool/gui:
1) mkdir test; cd test
2) git init
3) vi test.txt # add content
4) cat test.txt
===============
Hello World!!!!
===============
5) git citool
6) add the test.txt file to the index
7) see test.txt index diff
git citool shows:
new file mode 100644 # black
@@ -0,0 +1,5 @@ # blue
+ # green
=============== # orange
+Hello World!!!! # green
=============== # orange
+ # green
Please Cc me, I'm not in the list.
Thank you!
--
Leandro Lucarella
Integratech S.A.
4571-5252
^ permalink raw reply
* Re: [PATCH v3] Advertise the ability to abort a commit
From: Brian Gernhardt @ 2008-07-30 19:01 UTC (permalink / raw)
To: Anders Melchiorsen; +Cc: git, gitster, peff
In-Reply-To: <1217440391-13259-1-git-send-email-mail@cup.kalibalik.dk>
On Jul 30, 2008, at 1:53 PM, Anders Melchiorsen wrote:
> An empty commit message is now treated as a normal situation, not an
> error.
>
> Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
> ---
>
> So, I decided that I find it wrong to promote functionality
> that results in an error. The error is now changed into a
> normal exit (with status code 1.)
'git commit' should return with an error any time it does not commit.
Otherwise scripts could get confused, thinking everything went fine
when nothing actually got done. Here, the user decided something was
in error and canceled out, the same way using using ^C causes a non-
zero return status.
~~ Brian
^ permalink raw reply
* Re: q: git-fetch a tad slow?
From: Ingo Molnar @ 2008-07-30 19:06 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20080730044855.GA7225@spearce.org>
* Shawn O. Pearce <spearce@spearce.org> wrote:
> > should i pack on both repos? I dont explicitly pack anything, but on
> > the server it goes into regular gc runs. (which will pack most
> > stuff, right?)
>
> git-gc automatically runs `git pack-refs --all --prune` like I
> recommended, unless you disabled it with config gc.packrefs = false.
> So its probably already packed.
>
> What does `find .git/refs -type f | wc -l` give for the repository on
> the central server? If its more than a handful (~20) I would suggest
> running git-gc before testing again.
ah, you are right, it gave 275, then git-gc brought it down to two:
earth4:~/tip> find .git/refs -type f | wc -l
275
earth4:~/tip> git gc
earth4:~/tip> find .git/refs -type f | wc -l
2
i turned off auto-gc recently (two weeks ago) because it was
auto-triggering _way_ too frequently. (like on every fifth merge i was
doing or so)
alas, fetching still seems to be slow:
titan:~/tip> time git-fetch origin
real 0m5.112s
user 0m0.972s
sys 0m3.380s
(but the gc run has not finished yet on the central repo so this isnt
fully valid.)
> But I'm really suspecting that this is just our quadratic matching
> algorithm running up against a large number of branches, causing it to
> suck.
>
> jgit at least uses an O(N) algorithm here, but since it is written in
> Java its of course slow compared to C Git. Takes a while to get that
> JVM running.
>
> I'll try to find some time to reproduce the issue and look at the
> bottleneck here. I'm two days into a new job so my git time has been
> really quite short this week. :-|
fetching the -tip repo:
http://people.redhat.com/mingo/tip.git/README
and then running 'git remote update' will i think already show this
problem for you too. People have been complaining about how slow the
update is.
Ingo
^ permalink raw reply
* Re: [PATCH] 64bit issue in test-parse-options.c
From: Junio C Hamano @ 2008-07-30 19:11 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: H.Merijn Brand, git
In-Reply-To: <20080730140523.GC31392@artemis.madism.org>
Pierre Habouzit <madcoder@debian.org> writes:
> The proper fix is to let integer be an *INT* (long integer is bogus
> anyways) and to put the date in a long using static unsigned long date,
> and make OPT_DATE use this long.
I am still puzzled by the original report of the breakage, as H. Merijn
cannot be the first person to ever ran test-parse-options on 64-bit
machine. Maybe there is a bytesex issue involved as well?
In any case, this should work.
test-parse-options.c | 8 +++++---
t/t0040-parse-options.sh | 11 ++++++++++-
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/test-parse-options.c b/test-parse-options.c
index 2a79e72..6e18083 100644
--- a/test-parse-options.c
+++ b/test-parse-options.c
@@ -2,7 +2,8 @@
#include "parse-options.h"
static int boolean = 0;
-static unsigned long integer = 0;
+static int integer = 0;
+static unsigned long timestamp;
static int abbrev = 7;
static int verbose = 0, dry_run = 0, quiet = 0;
static char *string = NULL;
@@ -32,7 +33,7 @@ int main(int argc, const char **argv)
OPT_INTEGER('i', "integer", &integer, "get a integer"),
OPT_INTEGER('j', NULL, &integer, "get a integer, too"),
OPT_SET_INT(0, "set23", &integer, "set integer to 23", 23),
- OPT_DATE('t', NULL, &integer, "get timestamp of <time>"),
+ OPT_DATE('t', NULL, ×tamp, "get timestamp of <time>"),
OPT_CALLBACK('L', "length", &integer, "str",
"get length of <str>", length_callback),
OPT_GROUP("String options"),
@@ -56,7 +57,8 @@ int main(int argc, const char **argv)
argc = parse_options(argc, argv, options, usage, 0);
printf("boolean: %d\n", boolean);
- printf("integer: %lu\n", integer);
+ printf("integer: %u\n", integer);
+ printf("timestamp: %lu\n", timestamp);
printf("string: %s\n", string ? string : "(not set)");
printf("abbrev: %d\n", abbrev);
printf("verbose: %d\n", verbose);
diff --git a/t/t0040-parse-options.sh b/t/t0040-parse-options.sh
index 03dbe00..e38241c 100755
--- a/t/t0040-parse-options.sh
+++ b/t/t0040-parse-options.sh
@@ -47,6 +47,7 @@ test_expect_success 'test help' '
cat > expect << EOF
boolean: 2
integer: 1729
+timestamp: 0
string: 123
abbrev: 7
verbose: 2
@@ -63,6 +64,7 @@ test_expect_success 'short options' '
cat > expect << EOF
boolean: 2
integer: 1729
+timestamp: 0
string: 321
abbrev: 10
verbose: 2
@@ -88,6 +90,7 @@ test_expect_success 'missing required value' '
cat > expect << EOF
boolean: 1
integer: 13
+timestamp: 0
string: 123
abbrev: 7
verbose: 0
@@ -108,6 +111,7 @@ test_expect_success 'intermingled arguments' '
cat > expect << EOF
boolean: 0
integer: 2
+timestamp: 0
string: (not set)
abbrev: 7
verbose: 0
@@ -135,6 +139,7 @@ test_expect_success 'ambiguously abbreviated option' '
cat > expect << EOF
boolean: 0
integer: 0
+timestamp: 0
string: 123
abbrev: 7
verbose: 0
@@ -161,6 +166,7 @@ test_expect_success 'detect possible typos' '
cat > expect <<EOF
boolean: 0
integer: 0
+timestamp: 0
string: (not set)
abbrev: 7
verbose: 0
@@ -177,7 +183,8 @@ test_expect_success 'keep some options as arguments' '
cat > expect <<EOF
boolean: 0
-integer: 1
+integer: 0
+timestamp: 1
string: default
abbrev: 7
verbose: 0
@@ -197,6 +204,7 @@ cat > expect <<EOF
Callback: "four", 0
boolean: 5
integer: 4
+timestamp: 0
string: (not set)
abbrev: 7
verbose: 0
@@ -223,6 +231,7 @@ test_expect_success 'OPT_CALLBACK() and callback errors work' '
cat > expect <<EOF
boolean: 1
integer: 23
+timestamp: 0
string: (not set)
abbrev: 7
verbose: 0
^ permalink raw reply related
* [PATCH] Add NO_RSYNC to allow building without rsync
From: Aidan Van Dyk @ 2008-07-30 18:52 UTC (permalink / raw)
To: git
This is similar to NO_CURL.
Signed-off-by: Aidan Van Dyk <aidan@highrise.ca>
---
I came about this because SCO OpenServer doesnt' have mkdtemp. But I never use
rsync, so making it optional was an easy fix.
Makefile | 4 ++++
transport.c | 9 ++++++++-
2 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 798a2f2..b0a2985 100644
--- a/Makefile
+++ b/Makefile
@@ -789,6 +789,10 @@ else
CC_LD_DYNPATH = -R
endif
+ifdef NO_RSYNC
+ BASIC_CFLAGS += -DNO_RSYNC
+endif
+
ifdef NO_CURL
BASIC_CFLAGS += -DNO_CURL
else
diff --git a/transport.c b/transport.c
index 6eb65b8..867b01f 100644
--- a/transport.c
+++ b/transport.c
@@ -142,6 +142,7 @@ static void insert_packed_refs(const char *packed_refs, struct ref **list)
}
}
+#ifndef NO_RSYNC
static struct ref *get_refs_via_rsync(struct transport *transport)
{
struct strbuf buf = STRBUF_INIT, temp_dir = STRBUF_INIT;
@@ -232,6 +233,7 @@ static int fetch_objs_via_rsync(struct transport *transport,
return result;
}
+#endif
static int write_one_ref(const char *name, const unsigned char *sha1,
int flags, void *data)
@@ -276,6 +278,7 @@ static int write_refs_to_temp_dir(struct strbuf *temp_dir,
return 0;
}
+#ifndef NO_RSYNC
static int rsync_transport_push(struct transport *transport,
int refspec_nr, const char **refspec, int flags)
{
@@ -345,6 +348,7 @@ static int rsync_transport_push(struct transport *transport,
return result;
}
+#endif
/* Generic functions for using commit walkers */
@@ -731,10 +735,13 @@ struct transport *transport_get(struct remote *remote, const char *url)
ret->url = url;
if (!prefixcmp(url, "rsync://")) {
+#ifdef NO_RSYNC
+ error("git was compiled without rsync support.");
+#else
ret->get_refs_list = get_refs_via_rsync;
ret->fetch = fetch_objs_via_rsync;
ret->push = rsync_transport_push;
-
+#endif
} else if (!prefixcmp(url, "http://")
|| !prefixcmp(url, "https://")
|| !prefixcmp(url, "ftp://")) {
--
1.6.0.rc1.dirty
^ permalink raw reply related
* Compile fix for SCO OPenServer
From: Aidan Van Dyk @ 2008-07-30 18:49 UTC (permalink / raw)
To: git
In-Reply-To: <20071205172125.GF12636@yugib.highrise.ca>
SCO OpenServer also hides the definitions of (at least) u_short and
friends if _XOPEN_SOURCE is defined.
---
Same patch as last time, updated for current master.
git-compat-util.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index cf89cdf..42e3e0b 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -39,7 +39,7 @@
/* Approximation of the length of the decimal representation of this type. */
#define decimal_length(x) ((int)(sizeof(x) * 2.56 + 0.5) + 1)
-#if !defined(__APPLE__) && !defined(__FreeBSD__) && !defined(__USLC__) && !defined(_M_UNIX)
+#if !defined(__APPLE__) && !defined(__FreeBSD__) && !defined(__USLC__) && !defined(_M_UNIX) && !defined(__OPENSERVER__)
#define _XOPEN_SOURCE 600 /* glibc2 and AIX 5.3L need 500, OpenBSD needs 600 for S_ISLNK() */
#define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */
#endif
--
1.6.0.rc1.dirty
^ permalink raw reply related
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Steffen Prohaska @ 2008-07-30 19:25 UTC (permalink / raw)
To: Avery Pennarun
Cc: Eyvind Bernhardsen, Dmitry Potapov, Johannes Schindelin,
Joshua Jensen, Junio C Hamano, git
In-Reply-To: <32541b130807301133w4bfc8288oa2d15911b2317dca@mail.gmail.com>
On Jul 30, 2008, at 8:33 PM, Avery Pennarun wrote:
> On 7/30/08, Steffen Prohaska <prohaska@zib.de> wrote:
>
>> What matters is that git gives you exactly back what you
>> committed. It
>> does so with core.autocrlf=true, unless you check out with a
>> different
>> setting for autocrlf.
>
> You can tell that this statement isn't quite true because if you have
> a file with mixed LF and CRLF line endings, which I do (thanks,
> Windows!) then CRLF->LF conversion is not a reversible operation.
> Interestingly LF->CRLF still is (because an LF->CRLF'd file will never
> have a bare LF, and on such a subset of files, CRLF->LF is
> reversible).
>
> Also note that core.autocrlf=input is *definitely* not a perfectly
> reversible operation.
You are absolutely right. The files your describe are modified by git,
because they are "invalid" text files, as git defines them. For git's
autocrlf mechanism to work, a text file is only allowed to have a
*single* type of line endings. Otherwise it is broken and git tries to
help you fixing it.
> And so here's the problem: svn hands you a file. It may or may not
> have CRLFs in it, and the line endings may actually be a random mix of
> LF and CRLF, as I am actually experiencing at the moment in a
> particular repository at work. If core.autocrlf is anything other
> than "false", git will modify the file, and git-svn won't be apply the
> diff on the next revision.
This sound like a specific problem with svn, not a general problem
of git's autocrlf concept. I work with a git-only workflow and I
never see the problems you describe.
> It's conceivable that core.autocrlf=true will work if your svn
> repository is pure and svn hands you files only with CRLF endings.
> It's somewhat unlikely that most svn repositories are in that state
> (remember: it has to be perfect in *every revision* for git-svn to
> work).
>
> So anyway, I can't see how git-svn can possibly work in the general
> case if core.autocrlf is anything other than false *at git-svn fetch
> time*.
That might be the case. Note though that I cannot contribute
much to this discussion because I never use git-svn.
> And that's what I do, and it works great, modulo a bunch of
> stupid CRLFs that sneak into the repo via svn, but those can be fixed.
> Someday we'll stop using svn, and git-filter-branch can fix them all
> retroactively so that "blame" will work right.
>
> Perhaps git-svn needs to actually ignore the core.autocrlf setting?
From what you describe, I get the impression that git-svn's handling
of line endings could certainly be improved.
Steffen
^ permalink raw reply
* Re: markdown 2 man, was Re: Git Community Book
From: Junio C Hamano @ 2008-07-30 19:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Julian Phillips, Scott Chacon, Petr Baudis, git list
In-Reply-To: <alpine.LSU.1.00.0807301514280.3486@wbgn129.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Note also that Markdown cannot create TOCs automatically, AFAICT. So
> probably it would be not all that easy to convert the User Manual to that
> format.
The use of markdown may mean updates to the User Manual won't be merged
back to his book without effort and manual porting on his side, and the
side porting in the other direction has the same issue as well, but the
contents and the way materials are presented will be vastly different in
future versions anyway; not being able to side-port new material verbatim
may not be an issue. Discussion with Scott seems to suggest that the
overall philosophy of his book is "this is a different book targetted for
different audiences; its initial text happens to heavily borrow from the
existing documents but expected to become vastly improved", in other
words, fork-and-never-return.
That's one valid approach. I or you might have taken a different avenue,
but after all, it's his book, not mine, not yours, nor git list's book.
As I am not in "graphics and screencast" camp, I may probably not be able
to offer much help improving his book, and I suspect some people on this
list might feel the same way. But that's is Ok --- we are not dumping the
User Manual.
We originally hoped (well, at least I did) that Scott's effort on his book
might help us in improving the User Manual as well, but the approach seems
to make it unlikely. But that is nothing to hold against him --- he is
doing his own thing in a way he feels is the best, and that's perfectly
fine. We lost nothing, perhaps except for a chance to cooperate a bit
better and to widen the community.
> If at all, I would have preferred a format switch to Wiki syntax so that
> we can use the same source on the Git wiki as in our Documentation/
> directory.
Yeah, that's also true. I seem to recall markdown was used in ikiwiki?
^ permalink raw reply
* Re: [PATCH] 64bit issue in test-parse-options.c
From: Pierre Habouzit @ 2008-07-30 19:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: H.Merijn Brand, git
In-Reply-To: <7vej5b5grc.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1435 bytes --]
On Wed, Jul 30, 2008 at 07:11:35PM +0000, Junio C Hamano wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
>
> > The proper fix is to let integer be an *INT* (long integer is bogus
> > anyways) and to put the date in a long using static unsigned long date,
> > and make OPT_DATE use this long.
>
> I am still puzzled by the original report of the breakage, as H. Merijn
> cannot be the first person to ever ran test-parse-options on 64-bit
> machine. Maybe there is a bytesex issue involved as well?
Yes there is: I assume HP-UX works on big endian machines, else on
machines where longs are 64 bits, we put timestamps in it which are
probably current dates, which still fit on 31 (or 32) bits, hence do not
touch the most significant 32 bits hence work on 64 bits little endian
machines (like ... x86_64).
So when we parse an integer in it again, the 32 most significant bits
remain 0 hence the test passes.
> In any case, this should work.
>
> test-parse-options.c | 8 +++++---
> t/t0040-parse-options.sh | 11 ++++++++++-
> 2 files changed, 15 insertions(+), 4 deletions(-)
Ack. I wanted to write it but hadn't the time yet, I was just pointing
to the right fix. Thanks for writing the patch :)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Add NO_RSYNC to allow building without rsync
From: Linus Torvalds @ 2008-07-30 19:33 UTC (permalink / raw)
To: Aidan Van Dyk; +Cc: git
In-Reply-To: <20080730185225.GG10399@yugib.highrise.ca>
On Wed, 30 Jul 2008, Aidan Van Dyk wrote:
>
> I came about this because SCO OpenServer doesnt' have mkdtemp. But I never use
> rsync, so making it optional was an easy fix.
Hmm. Without mkdtemp(), maybe you could just do a trivial compat function
somethin glike
char *git_mkdtemp(char *template)
{
char *n = mktemp(template);
if (mkdir(n))
n = NULL;
return n;
}
instead?
Linus
^ permalink raw reply
* Re: [PATCH] Add NO_RSYNC to allow building without rsync
From: Aidan Van Dyk @ 2008-07-30 19:49 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.1.10.0807301231050.3334@nehalem.linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 843 bytes --]
* Linus Torvalds <torvalds@linux-foundation.org> [080730 15:42]:
> Hmm. Without mkdtemp(), maybe you could just do a trivial compat function
> somethin glike
>
> char *git_mkdtemp(char *template)
> {
> char *n = mktemp(template);
> if (mkdir(n))
> n = NULL;
> return n;
> }
>
> instead?
And as I go to whip that up (ya, I'm lazy and just needed a prod), I see
it's already done:
# Define NO_MKDTEMP if you don't have mkdtemp in the C library.
But since rsync isn't available on this compile anyways, I still think
NO_RSYNC is worth having on it's own, just like NO_CURL or NO_TCLTK
a.
--
Aidan Van Dyk Create like a god,
aidan@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] 64bit issue in test-parse-options.c
From: H.Merijn Brand @ 2008-07-30 19:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pierre Habouzit, git
In-Reply-To: <7vej5b5grc.fsf@gitster.siamese.dyndns.org>
On Wed, 30 Jul 2008 12:11:35 -0700, Junio C Hamano <gitster@pobox.com>
wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
>
> > The proper fix is to let integer be an *INT* (long integer is bogus
> > anyways) and to put the date in a long using static unsigned long date,
> > and make OPT_DATE use this long.
>
> I am still puzzled by the original report of the breakage, as H. Merijn
> cannot be the first person to ever ran test-parse-options on 64-bit
> machine. Maybe there is a bytesex issue involved as well?
Itanium 2 / 64, and endianness indeed
> In any case, this should work.
Yes, that was what I was thinking too, but I had no time to go for the
test cases too. I had it to get to work ASAP.
> test-parse-options.c | 8 +++++---
> t/t0040-parse-options.sh | 11 ++++++++++-
> 2 files changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/test-parse-options.c b/test-parse-options.c
> index 2a79e72..6e18083 100644
> --- a/test-parse-options.c
> +++ b/test-parse-options.c
> @@ -2,7 +2,8 @@
> #include "parse-options.h"
>
> static int boolean = 0;
> -static unsigned long integer = 0;
> +static int integer = 0;
> +static unsigned long timestamp;
> static int abbrev = 7;
> static int verbose = 0, dry_run = 0, quiet = 0;
> static char *string = NULL;
> @@ -32,7 +33,7 @@ int main(int argc, const char **argv)
> OPT_INTEGER('i', "integer", &integer, "get a integer"),
> OPT_INTEGER('j', NULL, &integer, "get a integer, too"),
> OPT_SET_INT(0, "set23", &integer, "set integer to 23", 23),
> - OPT_DATE('t', NULL, &integer, "get timestamp of <time>"),
> + OPT_DATE('t', NULL, ×tamp, "get timestamp of <time>"),
> OPT_CALLBACK('L', "length", &integer, "str",
> "get length of <str>", length_callback),
> OPT_GROUP("String options"),
> @@ -56,7 +57,8 @@ int main(int argc, const char **argv)
> argc = parse_options(argc, argv, options, usage, 0);
>
> printf("boolean: %d\n", boolean);
> - printf("integer: %lu\n", integer);
> + printf("integer: %u\n", integer);
> + printf("timestamp: %lu\n", timestamp);
> printf("string: %s\n", string ? string : "(not set)");
> printf("abbrev: %d\n", abbrev);
> printf("verbose: %d\n", verbose);
>
>
> diff --git a/t/t0040-parse-options.sh b/t/t0040-parse-options.sh
> index 03dbe00..e38241c 100755
> --- a/t/t0040-parse-options.sh
> +++ b/t/t0040-parse-options.sh
> @@ -47,6 +47,7 @@ test_expect_success 'test help' '
> cat > expect << EOF
> boolean: 2
> integer: 1729
> +timestamp: 0
> string: 123
> abbrev: 7
> verbose: 2
> @@ -63,6 +64,7 @@ test_expect_success 'short options' '
> cat > expect << EOF
> boolean: 2
> integer: 1729
> +timestamp: 0
> string: 321
> abbrev: 10
> verbose: 2
> @@ -88,6 +90,7 @@ test_expect_success 'missing required value' '
> cat > expect << EOF
> boolean: 1
> integer: 13
> +timestamp: 0
> string: 123
> abbrev: 7
> verbose: 0
> @@ -108,6 +111,7 @@ test_expect_success 'intermingled arguments' '
> cat > expect << EOF
> boolean: 0
> integer: 2
> +timestamp: 0
> string: (not set)
> abbrev: 7
> verbose: 0
> @@ -135,6 +139,7 @@ test_expect_success 'ambiguously abbreviated option' '
> cat > expect << EOF
> boolean: 0
> integer: 0
> +timestamp: 0
> string: 123
> abbrev: 7
> verbose: 0
> @@ -161,6 +166,7 @@ test_expect_success 'detect possible typos' '
> cat > expect <<EOF
> boolean: 0
> integer: 0
> +timestamp: 0
> string: (not set)
> abbrev: 7
> verbose: 0
> @@ -177,7 +183,8 @@ test_expect_success 'keep some options as arguments' '
>
> cat > expect <<EOF
> boolean: 0
> -integer: 1
> +integer: 0
> +timestamp: 1
> string: default
> abbrev: 7
> verbose: 0
> @@ -197,6 +204,7 @@ cat > expect <<EOF
> Callback: "four", 0
> boolean: 5
> integer: 4
> +timestamp: 0
> string: (not set)
> abbrev: 7
> verbose: 0
> @@ -223,6 +231,7 @@ test_expect_success 'OPT_CALLBACK() and callback errors work' '
> cat > expect <<EOF
> boolean: 1
> integer: 23
> +timestamp: 0
> string: (not set)
> abbrev: 7
> verbose: 0
--
H.Merijn Brand Amsterdam Perl Mongers http://amsterdam.pm.org/
using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
^ permalink raw reply
* Re: Compile fix for SCO OPenServer
From: Junio C Hamano @ 2008-07-30 20:01 UTC (permalink / raw)
To: Aidan Van Dyk; +Cc: git, Boyd Lynn Gerber
In-Reply-To: <20080730184956.GF10399@yugib.highrise.ca>
Aidan Van Dyk <aidan@highrise.ca> writes:
> SCO OpenServer also hides the definitions of (at least) u_short and
> friends if _XOPEN_SOURCE is defined.
I thought that was covered by 457bb45 (Port to 12 other Platforms., 2008-06-08).
> ---
> Same patch as last time, updated for current master.
Sign-off?
Boyd, does this make any of the earlier symbols you added redundant?
>
> git-compat-util.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/git-compat-util.h b/git-compat-util.h
> index cf89cdf..42e3e0b 100644
> --- a/git-compat-util.h
> +++ b/git-compat-util.h
> @@ -39,7 +39,7 @@
> /* Approximation of the length of the decimal representation of this type. */
> #define decimal_length(x) ((int)(sizeof(x) * 2.56 + 0.5) + 1)
>
> -#if !defined(__APPLE__) && !defined(__FreeBSD__) && !defined(__USLC__) && !defined(_M_UNIX)
> +#if !defined(__APPLE__) && !defined(__FreeBSD__) && !defined(__USLC__) && !defined(_M_UNIX) && !defined(__OPENSERVER__)
> #define _XOPEN_SOURCE 600 /* glibc2 and AIX 5.3L need 500, OpenBSD needs 600 for S_ISLNK() */
> #define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */
> #endif
> --
> 1.6.0.rc1.dirty
^ permalink raw reply
* Re: Compile fix for SCO OPenServer
From: Boyd Lynn Gerber @ 2008-07-30 20:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Aidan Van Dyk, git
In-Reply-To: <7vtze73zwg.fsf@gitster.siamese.dyndns.org>
On Wed, 30 Jul 2008, Junio C Hamano wrote:
> Aidan Van Dyk <aidan@highrise.ca> writes:
> > SCO OpenServer also hides the definitions of (at least) u_short and
> > friends if _XOPEN_SOURCE is defined.
>
> I thought that was covered by 457bb45 (Port to 12 other Platforms., 2008-06-08).
I thought it was covered as well.
> Sign-off?
>
> Boyd, does this make any of the earlier symbols you added redundant?
I have just tried this on 4 OpenServer 6.0 machines fresh installed and I
do not need this added. I am trying to figure out what is different on
his. It appears he is using the exact same version of the compiler as
well.
My uname -a gives me this...
SCO_SV tech0 5 6.0.0 i386
and the gcc -V gives me the exact same compiler. So I do not know why he
has to have the additional __OPENSERVER__. This does break my OpenServer
5.0.7 fresh install as well. So I would not use it. What I do not
understand is why the !defined(__USLC__) does not catch it. It should.
> > git-compat-util.h | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/git-compat-util.h b/git-compat-util.h
> > index cf89cdf..42e3e0b 100644
> > --- a/git-compat-util.h
> > +++ b/git-compat-util.h
> > @@ -39,7 +39,7 @@
> > /* Approximation of the length of the decimal representation of this type. */
> > #define decimal_length(x) ((int)(sizeof(x) * 2.56 + 0.5) + 1)
> >
> > -#if !defined(__APPLE__) && !defined(__FreeBSD__) && !defined(__USLC__) && !defined(_M_UNIX)
> > +#if !defined(__APPLE__) && !defined(__FreeBSD__) && !defined(__USLC__) && !defined(_M_UNIX) && !defined(__OPENSERVER__)
> > #define _XOPEN_SOURCE 600 /* glibc2 and AIX 5.3L need 500, OpenBSD needs 600 for S_ISLNK() */
> > #define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */
> > #endif
> > --
> > 1.6.0.rc1.dirty
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Boyd Gerber <gerberb@zenez.com>
ZENEZ 1042 East Fort Union #135, Midvale Utah 84047
^ permalink raw reply
* Re: [PATCH] Add NO_RSYNC to allow building without rsync
From: Junio C Hamano @ 2008-07-30 20:11 UTC (permalink / raw)
To: Aidan Van Dyk; +Cc: git
In-Reply-To: <20080730185225.GG10399@yugib.highrise.ca>
Aidan Van Dyk <aidan@highrise.ca> writes:
> This is similar to NO_CURL.
I am not sure if this is a good change.
We link with libcurl so supporting NO_CURL makes sense for an environment
without the library, but for rsync transport we just spawn it as a
separate process. The net effect on a machine without rsync installed is
the same (you cannot use rsync transport), but you can later choose to
install rsync and things will start working without recompiling git.
> Signed-off-by: Aidan Van Dyk <aidan@highrise.ca>
> ---
>
> I came about this because SCO OpenServer doesnt' have mkdtemp. But I never use
> rsync, so making it optional was an easy fix.
Perhaps "make NO_MKDTEMP=YesPlease" is a much better fix for your
particular environment?
The patch is seriously whitespace damaged, in any case.
^ permalink raw reply
* Re: Compile fix for SCO OPenServer
From: Boyd Lynn Gerber @ 2008-07-30 20:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Aidan Van Dyk, git
In-Reply-To: <7vtze73zwg.fsf@gitster.siamese.dyndns.org>
On Wed, 30 Jul 2008, Junio C Hamano wrote:
> Aidan Van Dyk <aidan@highrise.ca> writes:
>
> > SCO OpenServer also hides the definitions of (at least) u_short and
> > friends if _XOPEN_SOURCE is defined.
>
> I thought that was covered by 457bb45 (Port to 12 other Platforms., 2008-06-08).
>
> Boyd, does this make any of the earlier symbols you added redundant?
On my machine !defined(__USLC__) covers both UnixWare 7.1.4 and OpenServer
6.0.0. !defined(_M_UNIX) covers my OpenServer 5.0.7 machine. The
!defined(__USLC__) also covers my Novell OS's and others that use the
USLC (Unix System Labotories Compiler).
> > git-compat-util.h | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/git-compat-util.h b/git-compat-util.h
> > index cf89cdf..42e3e0b 100644
> > --- a/git-compat-util.h
> > +++ b/git-compat-util.h
> > @@ -39,7 +39,7 @@
> > /* Approximation of the length of the decimal representation of this type. */
> > #define decimal_length(x) ((int)(sizeof(x) * 2.56 + 0.5) + 1)
> >
> > -#if !defined(__APPLE__) && !defined(__FreeBSD__) && !defined(__USLC__) && !defined(_M_UNIX)
> > +#if !defined(__APPLE__) && !defined(__FreeBSD__) && !defined(__USLC__) && !defined(_M_UNIX) && !defined(__OPENSERVER__)
> > #define _XOPEN_SOURCE 600 /* glibc2 and AIX 5.3L need 500, OpenBSD needs 600 for S_ISLNK() */
> > #define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */
> > #endif
> > --
> > 1.6.0.rc1.dirty
>
--
Boyd Gerber <gerberb@zenez.com>
ZENEZ 1042 East Fort Union #135, Midvale Utah 84047
^ permalink raw reply
* Re: Compile fix for SCO OPenServer
From: Junio C Hamano @ 2008-07-30 20:18 UTC (permalink / raw)
To: Boyd Lynn Gerber; +Cc: Aidan Van Dyk, git
In-Reply-To: <alpine.LNX.1.10.0807301403360.13032@xenau.zenez.com>
Boyd Lynn Gerber <gerberb@zenez.com> writes:
> On Wed, 30 Jul 2008, Junio C Hamano wrote:
>> Aidan Van Dyk <aidan@highrise.ca> writes:
>> > SCO OpenServer also hides the definitions of (at least) u_short and
>> > friends if _XOPEN_SOURCE is defined.
>>
>> I thought that was covered by 457bb45 (Port to 12 other Platforms., 2008-06-08).
>
> I thought it was covered as well.
>
>> Sign-off?
>>
>> Boyd, does this make any of the earlier symbols you added redundant?
>
> I have just tried this on 4 OpenServer 6.0 machines fresh installed and I
> do not need this added. I am trying to figure out what is different on
> his. It appears he is using the exact same version of the compiler as
> well.
>
> My uname -a gives me this...
>
> SCO_SV tech0 5 6.0.0 i386
>
> and the gcc -V gives me the exact same compiler. So I do not know why he
> has to have the additional __OPENSERVER__. This does break my OpenServer
> 5.0.7 fresh install as well. So I would not use it. What I do not
> understand is why the !defined(__USLC__) does not catch it. It should.
Thanks for a prompt response.
Could you work with Aidan to come up with the optimal solution that does
not break anybody? I won't queue this patch until the issue is sorted
out.
^ permalink raw reply
* Re: Compile fix for SCO OPenServer
From: Aidan Van Dyk @ 2008-07-30 20:43 UTC (permalink / raw)
To: Boyd Lynn Gerber; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LNX.1.10.0807301403360.13032@xenau.zenez.com>
[-- Attachment #1: Type: text/plain, Size: 2621 bytes --]
* Boyd Lynn Gerber <gerberb@zenez.com> [080730 16:09]:
> I have just tried this on 4 OpenServer 6.0 machines fresh installed and I
> do not need this added. I am trying to figure out what is different on
> his. It appears he is using the exact same version of the compiler as
> well.
>
> My uname -a gives me this...
>
> SCO_SV tech0 5 6.0.0 i386
>
> and the gcc -V gives me the exact same compiler. So I do not know why he
> has to have the additional __OPENSERVER__. This does break my OpenServer
> 5.0.7 fresh install as well. So I would not use it. What I do not
> understand is why the !defined(__USLC__) does not catch it. It should.
Sorry, a bit premature on my end...
I tried a "default" gmake, and hit an error right away:
UX:cc: ERROR: Invalid subargument: -Wall
And immediately pulled my changes from last january into the fix it. My
changes included a local config.mak CFLAGS override which was the real
fix.
To build with no source changes, I need:
NO_MKDTEMP=1 SNPRINTF_RETURNS_BOGUS=1 CFLAGS=-g NO_POSIX_ONLY_PROGRAMS=1
How about something like this:
diff --git a/Makefile b/Makefile
index 798a2f2..c42040f 100644
--- a/Makefile
+++ b/Makefile
@@ -602,6 +602,7 @@ ifeq ($(uname_S),SCO_SV)
endif
ifeq ($(uname_R),5)
CC = cc
+ CFLAGS = -g
BASIC_CFLAGS += -Kthread
endif
NEEDS_SOCKET = YesPlease
@@ -615,6 +616,8 @@ ifeq ($(uname_S),SCO_SV)
BASIC_LDFLAGS += -L/usr/local/lib
NO_STRCASESTR = YesPlease
NO_MEMMEM = YesPlease
+ NO_MKDTEMP = YesPlease
+ SNPRINTF_RETURNS_BOGUS = YesPlease
INSTALL = ginstall
TAR = gtar
endif
Unfortunately, I have access to only that one SCO box, so I have no idea
of mkdtemp and sprintf problems are on all SCO, or just R=5 ones.
That allows me to build with NO_POSIX_ONLY_PROGRAMS=1, because for some reason, the
linker complains on linking git-shell:
Undefined first referenced
symbol in file
hexval_table abspath.o
null_sha1 abspath.o
trust_executable_bit abspath.o
has_symlinks abspath.o
UX:ld: ERROR: Symbol referencing errors. No output written to git-shell
These are all extern varualbes declared in cache.h, but no defined in
any of the objects git-shell links, normally not a problem, but this is SCO.
--
Aidan Van Dyk Create like a god,
aidan@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Add NO_RSYNC to allow building without rsync
From: Aidan Van Dyk @ 2008-07-30 20:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vod4f3zfu.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 777 bytes --]
* Junio C Hamano <gitster@pobox.com> [080730 16:11]:
> > I came about this because SCO OpenServer doesnt' have mkdtemp. But I never use
> > rsync, so making it optional was an easy fix.
>
> Perhaps "make NO_MKDTEMP=YesPlease" is a much better fix for your
> particular environment?
Yes, I found that out after...
> The patch is seriously whitespace damaged, in any case.
Ooops... copy-n-paste from git-format-patch|more on some crappy sco terminal
through a screen session... I guess someone in there translated tabs to
spaces...
a.
--
Aidan Van Dyk Create like a god,
aidan@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* git help broken
From: Kevin Ballard @ 2008-07-30 20:52 UTC (permalink / raw)
To: Git Mailing List
`git help diff` no longer finds the git-diff manpage (as of tip of
next branch). I haven't tested, but I suspect
940208a771066229bc6a486f6a058e332b71cfe4 is responsible.
-Kevin Ballard
--
Kevin Ballard
http://kevin.sb.org
kevin@sb.org
http://www.tildesoft.com
^ permalink raw reply
* Re: [PATCH] git-svn: Abort with an error if 'fetch' parameter is invalid.
From: Avery Pennarun @ 2008-07-30 20:56 UTC (permalink / raw)
To: Avery Pennarun; +Cc: git, gitster, normalperson
In-Reply-To: <1217451235-9609-1-git-send-email-apenwarr@gmail.com>
On 7/30/08, Avery Pennarun <apenwarr@stasis.open.versabanq.com> wrote:
> ...
Please excuse the broken From: line on the above patch. The
@gmail.com address is correct.
Avery
^ permalink raw reply
* Re: cvs diff -l equivalent?
From: Mikael Magnusson @ 2008-07-30 20:57 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: git
In-Reply-To: <20080730082030.GA12555@cuci.nl>
2008/7/30 Stephen R. van den Berg <srb@cuci.nl>:
> Someone popped this question on me. The closest I got was:
>
> git diff .
>
> But that still recurses. Any solutions without patching?
Another option than the ones suggested:
git diff|filterdiff -x '*/*/*'
filterdiff is available from the "patchutils" package.
--
Mikael Magnusson
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Avery Pennarun @ 2008-07-30 21:07 UTC (permalink / raw)
To: Steffen Prohaska
Cc: Eyvind Bernhardsen, Dmitry Potapov, Johannes Schindelin,
Joshua Jensen, Junio C Hamano, git
In-Reply-To: <56C07978-D6C9-4219-8B92-6217BD33F6D4@zib.de>
On 7/30/08, Steffen Prohaska <prohaska@zib.de> wrote:
> > And so here's the problem: svn hands you a file. It may or may not
> > have CRLFs in it, and the line endings may actually be a random mix of
> > LF and CRLF, as I am actually experiencing at the moment in a
> > particular repository at work. If core.autocrlf is anything other
> > than "false", git will modify the file, and git-svn won't be apply the
> > diff on the next revision.
>
> This sound like a specific problem with svn, not a general problem
> of git's autocrlf concept. I work with a git-only workflow and I
> never see the problems you describe.
My apologies, I think I got this thread mixed up with a different
thread about the fact that git-svn doesn't work with autocrlf.
FWIW, this problem would apply to any system that incrementally
imports into git from another system using binary deltas.
Have fun,
Avery
^ permalink raw reply
* Re: [PATCH v3] Advertise the ability to abort a commit
From: Avery Pennarun @ 2008-07-30 21:09 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Anders Melchiorsen, git, gitster, peff
In-Reply-To: <E2809CE9-1DEB-48DA-8E42-8BEAB376FED2@silverinsanity.com>
On 7/30/08, Brian Gernhardt <benji@silverinsanity.com> wrote:
> 'git commit' should return with an error any time it does not commit.
> Otherwise scripts could get confused, thinking everything went fine when
> nothing actually got done. Here, the user decided something was in error
> and canceled out, the same way using using ^C causes a non-zero return
> status.
The patch uses a non-zero exit code, which is an error status. But as
that's the case, I'm not sure why it's described in the changelog as
treating it "not as an error."
Have fun,
Avery
^ 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