* 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
* Re: [PATCH v3] Advertise the ability to abort a commit
From: Brian Gernhardt @ 2008-07-30 21:16 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Anders Melchiorsen, git, gitster, peff
In-Reply-To: <32541b130807301409t2f1f3a80n44c62447c628f03a@mail.gmail.com>
On Jul 30, 2008, at 5:09 PM, Avery Pennarun wrote:
> 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."
Sorry, was reading through the list too quickly. Of course an exit
code of 1 is an error. I'll go back to hiding under my rock now.
~~ Brian
^ permalink raw reply
* Re: Compile fix for SCO OPenServer
From: Boyd Lynn Gerber @ 2008-07-30 21:28 UTC (permalink / raw)
To: Aidan Van Dyk; +Cc: Junio C Hamano, git
In-Reply-To: <20080730204339.GJ10399@yugib.highrise.ca>
On Wed, 30 Jul 2008, Aidan Van Dyk wrote:
> * 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 doing a fresh
working directory. And just for the fun of it try...
This
tech0 > CC=cc CXX=CC CFLAGS="-Kalloca -Kthread" CPPFLAGS="-Kalloca
-Kthread" ./configure
tech0 > gmake
and
tech0 > CC=cc CXX=CC ./configure
tech0 > gmake
worked without any issues for me.
> 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
The above does work on OpenServer 6, UnixWare 7.1.4 and OpenServer 5.0.7
> 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.
I do not see the problem on my systems.
--
Boyd Gerber <gerberb@zenez.com>
ZENEZ 1042 East Fort Union #135, Midvale Utah 84047
^ permalink raw reply
* Re: cvs diff -l equivalent?
From: Linus Torvalds @ 2008-07-30 21:25 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: git
In-Reply-To: <20080730082030.GA12555@cuci.nl>
On Wed, 30 Jul 2008, Stephen R. van den Berg wrote:
> Someone popped this question on me. The closest I got was:
>
> git diff .
>
> But that still recurses. Any solutions without patching?
Not without patching, no. When generating a patch, git diff always
recurses.
I suspect adding some kind of "-l" flag would be about five lines of code,
though, so if you really need it... Hint, hint.
Linus
^ permalink raw reply
* Re: Git Community Book
From: J. Bruce Fields @ 2008-07-30 21:39 UTC (permalink / raw)
To: Scott Chacon; +Cc: Petr Baudis, git list
In-Reply-To: <d411cc4a0807291130p228f77d5r1f390090ec29aef4@mail.gmail.com>
> > So my confusion still is - where does this stand wrt. the user manual?
> > Why didn't you just start with the manual and work on that? I thought
> > you were planning to do that, but apparently we misunderstood each other
> > in the last mails.
> >
On Tue, Jul 29, 2008 at 11:30:55AM -0700, Scott Chacon wrote:
>
> I was originally planning on doing that, but the problem is the
> graphics, diagrams and screencasts. Unless I am mistaken, there is
> not a single outside media reference in any of these guides - the
> diagrams that are there are all ascii drawings. I'm assuming there is
> a reason for that. If I wanted to add images and screencast embeds
> into the guide, how would that work?
>
Yeah, some possible obstacles:
- Size: People probably won't want large binary blobs added to
the git repository.
- Editability: We want to be able to keep the materials up to
date and accurate.
- Source readability: the current documentation can all be read
in place without doing a build.
- Build requirements: I seem to recall complaints about the
toolchain required to build the existing documentation.
At least for simple diagrams it might be possible to solve most of those
problems with an appropriate diagram-description-language that could be
compiled into image files. Screencasts are probably totally out,
though.
In cases where you do find you're working with the same material, any
improvements you could contribute back to the in-tree documentation
would of course be appreciated.
> Well, that's what the point of this is - to ask everyone to help me
> review it, and possibly help me add to it. The user manual is great,
> but even I don't reference it very often because I find it difficult
> to find content in it I need quickly.
If you had notes on any particular examples (I looked for X in place Y,
then place Z, and finally found it where I least expected it in place
Q...), they'd be appreciated.
> The specific order I choose is very different from the User Guide and
> is likely to bother a number of people, which you mentioned (and I'm
> sure Dscho will _hate_) because I introduce the object model at the
> beginning. (I'm still working on that section, trying to simplify it
> and add in some other diagrams and a short screencast I have that I
> think will be helpful) This is because I have had a lot of positive
> feedback that primary frustration from people comes from them thinking
> of Git as a super-better Subversion.
>
> I would venture to say that
> _most_ of the users coming to Git now are currently fluent in
> Subversion. Even if they are from Perforce or CVS (the other two ones
> I will occasionally run into), their mental model of what an SCM does
> is the same - delta storage. I've found that by ridding them of that
> notion off the bat, they have _far_ fewer problems and frustrations
> with Git than when I just try to show them the first 10 commands in
> sort of a cookbook style. It's not a complicated model, it doesn't
> take long to teach, and in _my personal_ experience (which is not to
> say it's necessarily correct), it helps people the most in picking it
> up and really loving the tool.
I've considered doing the same for the user manual, actually, for some
of the same reasons--my main concern would be that it be done very
quickly, so as not to make people feel like it was a big obstacle on
their way to actually doing what they need to do.
So, anyway, that's to say that suggestions for reorganization of the
in-tree documentation (as opposed to just smaller-scale fixes) would
also be welcomed....
--b.
>
> The book is built so that it is just as easy to start in the 'Basic
> Usage' section and go back later, but if you're going to sit down and
> just start reading, I think it would be better to explain why Git is
> different at a fundamental level right off the bat.
>
> Scott
> --
> 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
^ permalink raw reply
* Re: [PATCH] Add NO_RSYNC to allow building without rsync
From: Boyd Lynn Gerber @ 2008-07-30 21:42 UTC (permalink / raw)
To: Aidan Van Dyk; +Cc: Junio C Hamano, git
In-Reply-To: <20080730204948.GK10399@yugib.highrise.ca>
On Wed, 30 Jul 2008, Aidan Van Dyk wrote:
> * 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...
I do have rsync. I use it all the time on OpenServer 6. I have automated
rsync backups of certain Openserver 6 machines.
tech0 > rsync --version
rsync version 3.0.2 protocol version 30
Copyright (C) 1996-2008 by Andrew Tridgell, Wayne Davison, and others.
Web site: http://rsync.samba.org/
Capabilities:
64-bit files, 64-bit inums, 32-bit timestamps, 64-bit long ints,
socketpairs, hardlinks, symlinks, no IPv6, batchfiles, inplace,
append, ACLs, no xattrs, iconv, no symtimes
tech0.zenez.com and osr600.zenez.com are OpenServer 6 machines.
--
Boyd Gerber <gerberb@zenez.com>
ZENEZ 1042 East Fort Union #135, Midvale Utah 84047
^ permalink raw reply
* Re: [PATCH v3] Advertise the ability to abort a commit
From: Anders Melchiorsen @ 2008-07-30 21:53 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Brian Gernhardt, git, gitster, peff
In-Reply-To: <32541b130807301409t2f1f3a80n44c62447c628f03a@mail.gmail.com>
"Avery Pennarun" <apenwarr@gmail.com> writes:
> 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."
A matter of terminology, I guess. Apologies if I used the wrong word.
I figured that a non-zero return value was not necessarily an error,
but could also be an unusual exit. Like when calling "git" for help.
However, printing out "fatal:" and a lowercase note is definitely an
error situation.
Cheers,
Anders.
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Dmitry Potapov @ 2008-07-30 21:45 UTC (permalink / raw)
To: Eyvind Bernhardsen
Cc: Johannes Schindelin, Avery Pennarun, Joshua Jensen,
Junio C Hamano, git
In-Reply-To: <A8BF9951-AB9D-4391-A6CB-E9778064F4A8@orakel.ntnu.no>
On Tue, Jul 29, 2008 at 11:17:23PM +0200, Eyvind Bernhardsen wrote:
>
> My point was that autocrlf penalises Windows users just as much as it
> does Linux users, so why should it be turned on by default on
> Windows?
Because it does make sense on Windows (I mentioned some reasons for that
in my previous email), and it does NOT make any sense on Linux unless
you copy files from Windows.
> >
> >And the main argument for having that in this way is that people
> >with LF
> >text files should be unnecessary penalized for Windows being
> >different.
>
> I know, but my point is that I don't like to be unnecessarily
> penalised any more when I am using Windows than when I'm using Linux
> or OS X.
It seems you still have not realized that from the very day when you
started to use Windows, you are penalized for that day-in, day-out.
Let's take something simple. For instance, the hello-world program:
cat <<=== > hello.c
#include <stdio.h>
int main() {
printf ("Hello world!\n");
return 0;
}
===
You can compile it on Linux and Windows (using Microsoft Visual C).
Now, if you run it on Linux, it will print 13 symbols (exactly
as many as there are symbols in the printf string) while on Windows
you will get 14 bytes. It means that printf and as many other C
function on Windows does conversion and penalize you already!
> I would like the default to be "no conversion", and for
> conversion to be enabled not based on platform, but as a policy
> decision on the repositories where it actually matters.
If Microsoft C library did not do any conversion, I suspect we would
have this CRLF conversion at all!
> You can have anything you like in _your_ repository, of course, but if
> you're not publishing it anywhere, who cares what your line endings
> are? Your line endings only matter when you publish.
You can publish only what you have. So, it must decided before.
> That's why I
> want a setting that is propagated: so that when you clone a repository
> with a LF-only policy, Git knows what to do.
LF-only policy is the only sane policy for any text files. It has nothing
to do with clone.
>
> I think the real penalty is that with autocrlf enabled, Git no longer
> stores exactly what I committed.
And what is wrong with that? In any case, Git deltifies and compress
your files. Why does it not bother you? So, what matters here is
whether you are able to get back exactly what you put or not. That's
why Git has this safecrlf option! Of course, it is guarantee to get
exactly the same back only if you have the same autocrlf setting,
but if you have different autocrlf settings, it means that you want
*different* representation of text files!
> >Files that do not need conversion (such as *.bat) should be marked as
> >"-crlf" in .gitattributes.
>
> Yes, and I see you checked that "crlf=input" does actually work when
> you want LF-only, sorry about that. The syntax is _horrible_, though.
>
> >Of course, those who are very careful and have good editors can set
> >autocrlf=false even on Windows...
>
> Right, or who know that the repository they're using will only be
> shared with other Windows users.
WRONG! Using storing CRLF in text files is a completely idiotic idea.
Those who do so asked for troubles, so they should not complain!
>
> Internally, Git doesn't really care, does it?
It DOES!!! Such things like merges and diffs and many other every day
commands do care about end-of-lines and the ONLY end-of-line they
recognize is '\n'. In fact, there are more than 400 places in Git where
'\n' is used. Of course, not all of them may be qualified as internals
but many of them do.
So, as long as Git internally consider only LF as the end-of-line.
>
> Heh. Where I work, we hacked CVS for Windows to get away from that
> behaviour :)
Maybe, you used Cygwin version of CVS, which had LF, but those Windows
versions of CVS I used produced CRLF on Windows.
> >
> >The problem is how to determine when it is necessary and when it is
> >not. If I never commit with wrong EOLs, I don't think it is necessary
> >for me to have this conversion... On the other hand, I don't mind
> >having
> >this check as default. It does not really bother me much, and if I
> >can
> >turn it off, it is fine with me. But I suppose other people may feel
> >differently about this issue.
>
> Well, what I want is to be able to say "it is necessary to do eol
> conversion in this repository",
You always can do that in _your_ repository:
git config core.autocrlf ...
> allowing the default to be "don't do
> eol conversion" on Windows, too. For a setting like that to be
> useful, it has to be propagated when the repository is cloned.
Why? Other people may have other preferences.
> I want it to be versioned because you might want to change it without
> messing with the content that's already in the repository. This is
> actually my main motivation, since I have lots of CRLF-infused CVS
> history to deal with.
Well, you can try to use .gitattributes, but I believe it would be far
more reasonable to clean this mess with line-ending than finding a
way to continue insanity with different ending in different text files.
>
> It should apply on Linux as well as Windows because there is always
> the chance that a user will manage to commit a CRLF on Linux (a
> colleague of mine once complained that CVS on Linux doesn't do eol
> conversion; he edited files on Windows, but checked them in on
> Linux).
For those who need it, Git provides autocrlf=input. But the question
here is what should be default. I don't think that those who copies
files directly from Windows to Linux are majority. OTOH, I don't
mind autocrlf=input as default. If it can be turned off, it is fine
with me :)
> It would probably be okay to have a setting that turns all
> conversion off, but wouldn't that be kind of rude?
How so?
Dmitry
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Dmitry Potapov @ 2008-07-30 22:02 UTC (permalink / raw)
To: Avery Pennarun
Cc: Steffen Prohaska, Eyvind Bernhardsen, Johannes Schindelin,
Joshua Jensen, Junio C Hamano, git
In-Reply-To: <32541b130807301407m59eef936m5e07dd33a4eb5b04@mail.gmail.com>
On Wed, Jul 30, 2008 at 05:07:49PM -0400, Avery Pennarun wrote:
>
> FWIW, this problem would apply to any system that incrementally
> imports into git from another system using binary deltas.
Not necessary. It depends on how import is done. You should not apply
this binary deltas to your working tree, but to files in the repo. And
obviously those files that are imported should be stored as is without
any conversion. In the same way as if you clone some git repo, you do
not apply any commit conversion to any existing commit. This conversion
should be done for *new* commits that you create locally.
So, the problem with git-svn is mostly due to how the import is done. Of
course, the other part of that problem is that conversion setting in Git
and SVN for text files specified very differently.
Dmitry
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Avery Pennarun @ 2008-07-30 22:14 UTC (permalink / raw)
To: Dmitry Potapov
Cc: Steffen Prohaska, Eyvind Bernhardsen, Johannes Schindelin,
Joshua Jensen, Junio C Hamano, git
In-Reply-To: <20080730220236.GD7008@dpotapov.dyndns.org>
On 7/30/08, Dmitry Potapov <dpotapov@gmail.com> wrote:
> On Wed, Jul 30, 2008 at 05:07:49PM -0400, Avery Pennarun wrote:
> > FWIW, this problem would apply to any system that incrementally
> > imports into git from another system using binary deltas.
>
> Not necessary. It depends on how import is done. You should not apply
> this binary deltas to your working tree, but to files in the repo. And
> obviously those files that are imported should be stored as is without
> any conversion. In the same way as if you clone some git repo, you do
> not apply any commit conversion to any existing commit. This conversion
> should be done for *new* commits that you create locally.
>
> So, the problem with git-svn is mostly due to how the import is done. Of
> course, the other part of that problem is that conversion setting in Git
> and SVN for text files specified very differently.
Hmm, if your first paragraphis true (do not apply any commit
conversion to any existing commit), then in fact SVN's method for
specifying text files doesn't really matter, right? It's just a bug
in git-svn.
Is it possible to have git-svn override core.autocrlf temporarily? If
someone can give me a hint how to do that, I don't mind working up a
patch for that. I can't see any situation where *not* doing so would
even work (unless core.autocrlf=false already, of course).
Have fun,
Avery
^ permalink raw reply
* [PATCH] builtin-help: always load_command_list() in cmd_help()
From: Miklos Vajna @ 2008-07-30 22:38 UTC (permalink / raw)
To: Kevin Ballard; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <C0DB03B0-8AF5-4B6A-A9DB-16608128EB31@sb.org>
When cmd_help() is called, we always need the list of main and other
commands, not just when the list of all commands is shown. Before this
patch 'git help diff' invoked 'man gitdiff' because cmd_to_page()
thought 'diff' is not a git command.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
On Wed, Jul 30, 2008 at 01:52:26PM -0700, Kevin Ballard <kevin@sb.org> wrote:
> `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.
This fixed the issue for me.
Thanks!
help.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/help.c b/help.c
index 88c0d5b..968f368 100644
--- a/help.c
+++ b/help.c
@@ -690,6 +690,7 @@ int cmd_help(int argc, const char **argv, const char *prefix)
{
int nongit;
const char *alias;
+ unsigned int longest = load_command_list("git-", &main_cmds, &other_cmds);
setup_git_directory_gently(&nongit);
git_config(git_help_config, NULL);
@@ -698,7 +699,6 @@ int cmd_help(int argc, const char **argv, const char *prefix)
builtin_help_usage, 0);
if (show_all) {
- unsigned int longest = load_command_list("git-", &main_cmds, &other_cmds);
printf("usage: %s\n\n", git_usage_string);
list_commands("git commands", longest, &main_cmds, &other_cmds);
printf("%s\n", git_more_info_string);
--
1.6.0.rc0.14.g95f8.dirty
^ permalink raw reply related
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