Re: t5570 trap use in start/stop_git_daemon
Jeff King peff.net> writes:
>
> On Fri, Feb 13, 2015 at 02:44:03AM -0500, Jeff King wrote:
>
> > On Thu, Feb 12, 2015 at 03:31:12PM -0500, Randall S. Becker wrote:
> >
> Hmm, today I learned something new about ksh. Apparently when you use
> the "function" keyword to define a function like:
>
> function foo {
> trap 'echo trapped' EXIT
> }
> echo before
> foo
> echo after
>
> then the trap runs when the function exits! If you declare the same
> function as:
>
> foo() {
> trap 'echo trapped' EXIT
> }
>
> it behaves differently. POSIX shell does not have the function keyword,
> of course, and we are not using it here. Bash _does_ have the function
> keyword, but seems to behave POSIX-y even when it is present. I.e.,
> running the first script:
>
> $ ksh foo.sh
> before
> trapped
> after
>
> $ bash foo.sh
> before
> after
> trapped
>
> $ dash foo.sh
> foo.sh: 3: foo.sh: function: not found
> foo.sh: 5: foo.sh: Syntax error: "}" unexpected
>
> Switching to the second form, all three produce:
>
> before
> after
> trapped
>
> I don't know if that is all helpful to your bug-tracking or analysis,
> but for whatever reason it looks like your ksh is using localized traps
> for both forms of function. But as far as I know, bash has never behaved
> that way (I just grepped its CHANGES file for mentions of trap and found
> nothing likely).
>
> -Peff
>
Both versions produce your first output on our platform
$ ksh foo1.sh
before
trapped
after
$ bash foo1.sh
before
after
trapped
$ ksh foo2.sh
before
trapped
after
$ bash foo2.sh
before
after
trapped
$
This might have been one (or even _the_) reason why we picked bash as our
SHELL_PATH in config.mak.uname (I don't remember, it's more than 2 years
ago), not sure which shell Randall's test used?
bye, Jojo
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: read() MAX_IO_SIZE bytes, more than SSIZE_MAX?
Sorry to be a pain, but i think this sententence neede mending + * to override this, if the definition of SSIZE_MAX platform is broken. Bye, Jojo
Re: read() MAX_IO_SIZE bytes, more than SSIZE_MAX?
Joachim Schmitz schmitz-digital.de> writes: > > Junio C Hamano pobox.com> writes: > > > > OK, then let's do this. > > Except for the type "taht" -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: read() MAX_IO_SIZE bytes, more than SSIZE_MAX?
Junio C Hamano pobox.com> writes: > OK, then let's do this. > Yep, that'd do, thanks. bye, Jojo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: read() MAX_IO_SIZE bytes, more than SSIZE_MAX?
Junio C Hamano pobox.com> writes: > > > > something like this: > > > > /* allow overwriting from e.g. Makefile */ > > #if !defined(MAX_IO_SIZE) > > # define MAX_IO_SIZE (8*1024*1024) > > #endif > > /* for plattforms that have SSIZE and have it smaller */ > > #if defined(SSIZE_MAX && (SSIZE_MAX < MAX_IO_SIZE) > > # undef MAX_IO_SIZE /* avoid warning */ > > # define MAX_IO_SIZE SSIZE_MAX > > #endif > > No, not like that. If you do (1), that is only so that the Makefile can override > a broken definition a platform may give to SSIZE_MAX. So > > (1) if Makefile gives one, use it without second-guessing with SSIZE_MAX. > (2) if SSIZE_MAX is defined, and if it is smaller than our internal > default, use it. > (3) all other cases, us our internal default. oops, yes, of course /* allow overwriting from e.g. Makefile */ #ifndef(MAX_IO_SIZE) # define MAX_IO_SIZE (8*1024*1024) /* for plattforms that have SSIZE and have it smaller */ # if defined(SSIZE_MAX) && (SSIZE_MAX < MAX_IO_SIZE) # undef MAX_IO_SIZE /* avoid warning */ # define MAX_IO_SIZE SSIZE_MAX # endif #endif -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: read() MAX_IO_SIZE bytes, more than SSIZE_MAX?
Junio C Hamano pobox.com> writes:
>
> On Sat, Feb 7, 2015 at 12:32 PM, Torsten Bögershausen
web.de> wrote:
> > I don't know every platform of the planet well enough to be helpful
here,
> > especially the ones which don't follow all the specifications.
> >
> > In other words: As long as we can not guarantee that SSIZE_MAX is
defined,
> > (and is defined to somethong useful for xread()/xwrite() )
> > we should be more defensive here:
> >
> > tweak only on platform where we know it is needed and we know that it
works.
>
> Yup, I agree that is a sensible way to go.
>
> (1) if Makefile overrides the size, use it; otherwise
> (2) if SSIZE_MAX is defined, and it is smaller than our internal
> default, use it; otherwise
> (3) use our internal default.
>
> And leave our internal default to 8MB.
>
> That way, nobody needs to do anything differently from his current build
set-up,
> and I suspect that it would make step (1) optional.
>
something like this:
/* allow overwriting from e.g. Makefile */
#if !defined(MAX_IO_SIZE)
# define MAX_IO_SIZE (8*1024*1024)
#endif
/* for plattforms that have SSIZE and have it smaller */
#if defined(SSIZE_MAX && (SSIZE_MAX < MAX_IO_SIZE)
# undef MAX_IO_SIZE /* avoid warning */
# define MAX_IO_SIZE SSIZE_MAX
#endif
Steps 2 and 3 only , indeed step 1 not needed...
Bye,
JojoN�r��yb�X��ǧv�^�){.n�+ا���ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf
Re: read() MAX_IO_SIZE bytes, more than SSIZE_MAX?
Joachim Schmitz schmitz-digital.de> writes: > and as a (rather strange) > consequence mmap() (from compat/mmap.c) fails with EACCESS (why EACCESS?), > because xpread() returns something > 0. Seems mmap() should either set errno to EINVAL or not set it at all an just 'forward' whatever xpread() has set. As per http://man7.org/linux/man-pages/man2/mmap.2.html mmap() sets EINVAL if (amongst other things) it doesn't like the value of len, exactly the case here. bye, Jojo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: read() MAX_IO_SIZE bytes, more than SSIZE_MAX?
Randall S. Becker nexbridge.com> writes: > > On 2015-02-07 13:07PM Randall S. Becker wrote: > >On 2015-02-07 12:30PM Torsten Bögershausen wrote: > >>On 2015-02-07 17.45, Joachim Schmitz wrote: > Although I do agree with Jojo, that MAX_IO_SIZE seems to be a platform > constant and should be defined in terms of SSIZE_MAX. So something like: > > #ifndef MAX_IO_SIZE > # ifdef SSIZE_MAX > # define MAX_IO_SIZE (SSIZE_MAX) > # else > # define MAX_IO_SIZE (8*1024*1024) > # endif > #endif > > would be desirable. It would be way too large on some platforms. those 8MB had been chosen for a good reason, I assume: /* * Limit size of IO chunks, because huge chunks only cause pain. OS X * 64-bit is buggy, returning EINVAL if len >= INT_MAX; and even in * the absence of bugs, large chunks can result in bad latencies when * you decide to kill the process. */ However it should never be larger than SSIZE_MAX
Re: read() MAX_IO_SIZE bytes, more than SSIZE_MAX?
Joachim Schmitz schmitz-digital.de> writes: > > Torsten Bögershausen web.de> writes: > > > > > On 2015-02-07 17.45, Joachim Schmitz wrote: > b) never ever should read() be asked to read more than SSIZE_MAX, this > should be true for every platform on the planet? You may want to have is > smaller than SSIZE_MAX (like the current 8MB vs. the possible 2TB on > Linux), but surely never larger? Se also $gmane/232469, where that issue cropped up for MacOS X 64bit? Bye, Jojo
Re: read() MAX_IO_SIZE bytes, more than SSIZE_MAX?
Torsten Bögershausen web.de> writes: > > On 2015-02-07 17.45, Joachim Schmitz wrote: > > How about changing wrapper.c like this: > > #ifndef MAX_IO_SIZE > #define MAX_IO_SIZE (8*1024*1024) > #endif > - > and to change config.mak.uname like this: > > ifeq ($(uname_S),NONSTOP_KERNEL) > > BASIC_CFLAGS += -DMAX_IO_SIZE=(32*1024) > Does this work for you ? Of course it would, but, a) 32k is smaller than we can go (and yes, we could make it 52k) b) never ever should read() be asked to read more than SSIZE_MAX, this should be true for every platform on the planet? You may want to have is smaller than SSIZE_MAX (like the current 8MB vs. the possible 2TB on Linux), but surely never larger? Bye, Jojo
Re: read() MAX_IO_SIZE bytes, more than SSIZE_MAX?
Joachim Schmitz schmitz-digital.de> writes: > because xpread() returns something > 0. something < 0 of course (presumably -1)... bye, Jojo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
read() MAX_IO_SIZE bytes, more than SSIZE_MAX?
Hi there While investigating the problem with hung git-upload-pack we think to have found a bug in wrapper.c: #define MAX_IO_SIZE (8*1024*1024) This is then used in xread() to split read()s into suitable chunks. So far so good, but read() is only guaranteed to read as much as SSIZE_MAX bytes at a time. And on our platform that is way lower than those 8MB (only 52kB, POSIX allows it to be as small as 32k), and as a (rather strange) consequence mmap() (from compat/mmap.c) fails with EACCESS (why EACCESS?), because xpread() returns something > 0. How large is SSIZE_MAX on other platforms? What happens there if you try to read() more? Should't we rather use SSIZE_MAX on all platforms? If I'm reading the header files right, on Linux it is LONG_MAX (2TB?), so I guess we should really go for MIN(8*1024*1024,SSIZE_MAX)? bye, Jojo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
hang in git-upload-pack
Hi there In HP-Nonstop we're experiencing hangs in git-upload-pack, which seems to be the result of reads from / writes to pipes don't ever finish or don't get interrupted properly (SIGPIPE, SIGCHLD?) Any idea why that might be and how to fix it? bye, Jojo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] sequencer: trivial fix
> From: Joachim Schmitz [mailto:j...@schmitz-digital.de] > Sent: Wednesday, May 29, 2013 1:30 PM > To: 'Felipe Contreras' > Cc: 'git@vger.kernel.org' > Subject: RE: [PATCH 1/2] sequencer: trivial fix > > And for the record: I agree with you that these 2 things should rather not be > in a single patch as they are completely unrelated. I take that back: your patches 'overlap' so the 2nd won't apply without the 1st Bye, Jojo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] sequencer: trivial fix
> From: Felipe Contreras [mailto:felipe.contre...@gmail.com] > Sent: Wednesday, May 29, 2013 1:24 PM > To: Joachim Schmitz > Cc: git@vger.kernel.org > Subject: Re: [PATCH 1/2] sequencer: trivial fix > > On Wed, May 29, 2013 at 6:13 AM, Joachim Schmitz > wrote: > >> From: Felipe Contreras [mailto:felipe.contre...@gmail.com] > >> Sent: Wednesday, May 29, 2013 12:52 PM > >> To: Joachim Schmitz > >> Cc: git@vger.kernel.org > >> Subject: Re: [PATCH 1/2] sequencer: trivial fix > >> > >> On Wed, May 29, 2013 at 4:58 AM, Joachim Schmitz > >> wrote: > >> > Felipe Contreras wrote: > >> >> > >> >> Junio C Hamano wrote: > >> > >> >>> It probably is better to fold this patch into the other one when it > >> >>> is rerolled to correct the option name gotcha "on the tin". > >> >> > >> >> > >> >> Why? This patch is standalone and fixes an issue that is independent > >> >> of the other patch. Why squash two patches that do *two* different > >> >> things? > >> >> > >> >> Anyway, I'll happily drop this patch if you want this memory leak to > >> >> remain. But then I'll do the same in the other patch. > >> >> > >> >> This mantra of avodiing 'goto' is not helping anybody. > >> > > >> > > >> > adding 5 letters (to change the next "if" into an "else if") versus your > >> > addition of several lines and some 15 additional letters (ignoring the > >> > whitsspace) is IMHO enough to see what is better? > >> > >> This has nothing to do with what Junio said. > > > > Well, it has, but you had snipped it. But replied to the goto issue > > regardless > > I didn't snip anything, this is a different context. You did in your reply to me > >> This is better done without "goto" in general. > > He din't say: > __ > It probably is better to fold this patch into the other one when it > is rerolled to correct the option name gotcha "on the tin", AND you > fix the goto issue. > __ > > You added that last part in your mind. Moreover, he didn't say goto > was an issue, he simply stated an opinion about some generality. I added nothing in my mind, I just copy/paste that statement and was commenting on that and only that. At least intended to. Whenever anybody added more else branches, that's the time to possible switch to the goto style. And for the record: I agree with you that these 2 things should rather not be in a single patch as they are completely unrelated. Bye, Jojo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] sequencer: trivial fix
> From: Felipe Contreras [mailto:felipe.contre...@gmail.com] > Sent: Wednesday, May 29, 2013 12:52 PM > To: Joachim Schmitz > Cc: git@vger.kernel.org > Subject: Re: [PATCH 1/2] sequencer: trivial fix > > On Wed, May 29, 2013 at 4:58 AM, Joachim Schmitz > wrote: > > Felipe Contreras wrote: > >> > >> Junio C Hamano wrote: > > >>> It probably is better to fold this patch into the other one when it > >>> is rerolled to correct the option name gotcha "on the tin". > >> > >> > >> Why? This patch is standalone and fixes an issue that is independent > >> of the other patch. Why squash two patches that do *two* different > >> things? > >> > >> Anyway, I'll happily drop this patch if you want this memory leak to > >> remain. But then I'll do the same in the other patch. > >> > >> This mantra of avodiing 'goto' is not helping anybody. > > > > > > adding 5 letters (to change the next "if" into an "else if") versus your > > addition of several lines and some 15 additional letters (ignoring the > > whitsspace) is IMHO enough to see what is better? > > This has nothing to do with what Junio said. Well, it has, but you had snipped it. But replied to the goto issue regardless > This is better done without "goto" in general. Bye, Jojo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] sequencer: trivial fix
Felipe Contreras wrote:
Junio C Hamano wrote:
Neil Horman writes:
On Mon, May 27, 2013 at 11:52:18AM -0500, Felipe Contreras wrote:
We should free objects before leaving.
Signed-off-by: Felipe Contreras
---
sequencer.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/sequencer.c b/sequencer.c
index ab6f8a7..7eeae2f 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -626,12 +626,15 @@ static int do_pick_commit(struct commit
*commit, struct replay_opts *opts)
rerere(opts->allow_rerere_auto); } else {
int allow = allow_empty(opts, commit);
- if (allow < 0)
- return allow;
+ if (allow < 0) {
+ res = allow;
+ goto leave;
+ }
if (!opts->no_commit)
res = run_git_commit(defmsg, opts, allow);
}
+leave:
free_message(&msg);
free(defmsg);
--
1.8.3.rc3.312.g47657de
Acked-by: Neil Horman
This is better done without "goto" in general.
The other patch 2/2/ adds one more "we need to exit from the middle
of the flow" and makes it look handier to add an exit label here,
but it would be even better to express the logic of that patch as a
normal cascade of if/else if/..., which is small enough and we do
not need the "leave:" label.
Linux kernel developers would disagree. In C 'goto' is quite of then
the only sane option, and you can see 'goto' used in the Linux kernel
all over the place for that reason.
In this particular case it also makes perfect sense.
It probably is better to fold this patch into the other one when it
is rerolled to correct the option name gotcha "on the tin".
Why? This patch is standalone and fixes an issue that is independent
of the other patch. Why squash two patches that do *two* different
things?
Anyway, I'll happily drop this patch if you want this memory leak to
remain. But then I'll do the same in the other patch.
This mantra of avodiing 'goto' is not helping anybody.
adding 5 letters (to change the next "if" into an "else if") versus your
addition of several lines and some 15 additional letters (ignoring the
whitsspace) is IMHO enough to see what is better?
bye, Jojo
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] cherry-pick: add --skip-commits option
Felipe Contreras wrote: Pretty much what it says on the tin. Only that it add --skip-empty and not --skip-commit ?!? Bye, Jojo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fast-import: Remove redundant assignment of 'oe' to itself.
Stefano Lattarini wrote:
On 05/26/2013 10:05 PM, Stefan Beller wrote:
Reported by cppcheck.
Signed-off-by: Stefan Beller
---
fast-import.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fast-import.c b/fast-import.c
index 5f539d7..0142e3a 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -2914,7 +2914,7 @@ static void cat_blob(struct object_entry *oe,
unsigned char sha1[20]) static void parse_cat_blob(void)
{
const char *p;
- struct object_entry *oe = oe;
This was done on purpose, to avoid spurious warnings with (at least)
some versions of GCC.
+ struct object_entry *oe;
unsigned char sha1[20];
/* cat-blob SP LF */
This strange construct has been removed in other places meanwhile. It is
violating C-standards (C89, C99) and as such causes warnings with other
compilers, so this is fighting fire with fire. As it is a pointer it may be
more sensible to initialize with NULL, should appease all compilers and
still be correct.
Bye, Jojo
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 11/13] remote-hg: force remote push
Jed Brown wrote: Felipe Contreras writes: On Thu, Apr 4, 2013 at 2:48 PM, Jed Brown wrote: ... We have to assume that every Git (remote-hg) User is dealing with Hg Team No, we don't. Really? If there is no Hg Team, why bother with an Hg upstream? Huh? the counterpart of "every user" wpuld be "some users" and not "no user" or "no HG team", isn't it? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] drop some "int x = x" hacks to silence gcc warnings
Joachim Schmitz wrote: Johannes Sixt wrote: Am 3/21/2013 12:03, schrieb Jeff King: I was fooling around with clang and noticed that it complains about the "int x = x" construct under -Wall. That is IMHO a deficiency in clang, since the idiom has a well-defined use in silencing -Wuninitialized warnings. IMO, that's a myth. The construct invokes undefined behavior at least since C99, and the compilers are right to complain about it. And I complained about this a couple months ago, as the compiler on Actually on August 20th, 2012... HP-NonStop stumbles across this too (by emitting a warning) Bye, Jojo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] drop some "int x = x" hacks to silence gcc warnings
Johannes Sixt wrote: Am 3/21/2013 12:03, schrieb Jeff King: I was fooling around with clang and noticed that it complains about the "int x = x" construct under -Wall. That is IMHO a deficiency in clang, since the idiom has a well-defined use in silencing -Wuninitialized warnings. IMO, that's a myth. The construct invokes undefined behavior at least since C99, and the compilers are right to complain about it. And I complained about this a couple months ago, as the compiler on HP-NonStop stumbles across this too (by emitting a warning) Bye, Jojo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: how to check pending commits to be pushed?
Patricia Bittencourt Egeland wrote: Hi, Does someone know how to identify pending commits to be pushed in a local super repository (with quite some submodules), with git-1.6.5-1 ? git status ? Bye, Jojo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/4] Auto-generate mergetool lists
John Keeping wrote:
On Mon, Jan 28, 2013 at 01:50:19PM -0800, Junio C Hamano wrote:
What are the situations where a valid user-defined tools is
unavailable, by the way?
The same as a built-in tool: the command isn't available.
Currently I'm extracting the command word using:
cmd=$(eval -- "set -- $(git config mergetool.$tool.cmd); echo
\"$1\"")
Shouldnt this work?
cmd=$((git config "mergetool.$tool.cmd" || git config "difftool.$tool.cmd")
| awk '{print $1}')
(it's slightly more complicated due to handling difftool.$tool.cmd as
well, but that's essentially it). Then it just uses the same "type
$cmd" test as for built-in tools.
I don't know if there's a better way to extract the first word, but
that's the best I've come up with so far.
John
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] l10n: de.po: translate 11 new messages
Ralf Thielow wrote: Translate 11 new messages came from git.pot update in 46bc403 (l10n: Update git.pot (11 new, 7 removed messages)). Signed-off-by: Ralf Thielow --- po/de.po | 37 ++--- 1 file changed, 18 insertions(+), 19 deletions(-) diff --git a/po/de.po b/po/de.po index 3779f4c..ed8330a 100644 --- a/po/de.po +++ b/po/de.po @@ -5,7 +5,7 @@ # msgid "" msgstr "" -"Project-Id-Version: git 1.8.1\n" +"Project-Id-Version: git 1.8.2\n" Not "Projekt-Id-Version ..."? #: builtin/reset.c:33 msgid "mixed" @@ -7916,9 +7915,9 @@ msgid "reset HEAD but keep local changes" msgstr "setzt Zweigspitze (HEAD) zurück, behält aber lokale Änderungen" Not "reset -> setze" and "keep" -> halte (imperativ)? Or is the enlish text wrong and should be "resets" and "keeps" Bye, Jojo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] l10n: de.po: fix some minor issues
Ralf Thielow wrote: This fixes some minor issues and improves the German translation a bit. The following things were changed: - use complete sentences in option related messages - translate "use" consistently as "verwendet" - don't translate "make sense" as "macht Sinn" While your translations for these are OK, I wonder whether the original english message needs to get fixed/changed, e.g. rather than "does't make sense" use "are mutually exclusive" or "cannot be used with" or "cannot be used together" like in other places? Bye, Jojo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/2] Make git-svn work with gitdir links
Junio C Hamano wrote: Barry Wardell writes: These patches fix a bug which prevented git-svn from working with repositories which use gitdir links. Changes since v2: - Rebased onto latest master. - Added test case which verifies that the problem has been fixed. - Fixed problems with git svn (init|clone|multi-init). - All git-svn test cases now pass (except two in t9101 which also failed before these patches). Barry Wardell (2): git-svn: Add test for git-svn repositories with a gitdir link git-svn: Simplify calculation of GIT_DIR Thanks for your persistence ;-) As this is a pretty old topic, I'll give two URLs for people who are interested to view the previous threads: http://thread.gmane.org/gmane.comp.version-control.git/192133 http://thread.gmane.org/gmane.comp.version-control.git/192127 You would want to mark it as test_expect_failure in the first patch and then flip it to text_expect_success in the second patch where you fix the breakage? Otherwise, after applying the first patch, the testsuite will break needlessly. I'd just apply them the other way round, 1st fix the problem, 2nd add a test for it Bye, Jojo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Change old system name 'GIT' to 'Git'
Junio C Hamano wrote: David Aguilar writes: On Sat, Jan 19, 2013 at 1:59 AM, Thomas Ackermann wrote: @@ -55,7 +55,7 @@ History Viewers - *gitweb* (shipped with git-core) - GITweb provides full-fledged web interface for GIT repositories. + GITweb provides full-fledged web interface for Git repositories. What about GITweb? diff --git a/Documentation/git-update-ref.txt b/Documentation/git-update-ref.txt index d377a35..0df13ff 100644 --- a/Documentation/git-update-ref.txt +++ b/Documentation/git-update-ref.txt @@ -73,7 +73,7 @@ in ref value. Log lines are formatted as: Where "oldsha1" is the 40 character hexadecimal value previously stored in , "newsha1" is the 40 character hexadecimal value of and "committer" is the committer's name, email address -and date in the standard GIT committer ident format. +and date in the standard Git committer ident format. IMO some of these look nicer when everything is lowercase. e.g. "standard git committer ident format". I do not think we ever intended to change the *name* of the software. In the early days, we wrote GIT in places where, if we were doing a fancier typography, we would have used drop-caps for the latter two (i.e. it is "Git" spelled in a font whose lower case alphabets have the same shape as upper case ones but are smaller). So there were only "git" vs "Git". If I were to decide today to change the spellings, with an explicit purpose of making things more consistent across documentation, it may make sense to use even a simpler rule that is less error-prone for people who write new sentences that has to have the word. How about treating it just like any other ordinary word? That is, we say "git" (without double-quotes, of course), unless it comes at the beginning of a sentence? Because then it could get confused with "git", the command? That would be lower case even at the beginning of a sentence, wouldn't it? Bye, Jojo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: erratic behavior commit --allow-empty
Jan Engelhardt wrote: On Tuesday 2012-10-02 10:26, Johannes Sixt wrote: Note that git commit -m A --allow-empty *DID* create a commit. Only, that it received the same name (SHA1) as the commit you created before it because it had the exact same contents (files, parents, author, committer, and timestamps). Obviously, your script was executed sufficiently fast that the two commits happend in the same second. What about introducing nanosecond-granular timestamps into Git? Not every platform (supported by git) does have a nanosecond clock resolution Bye, Jojo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] archive-tar: fix sanity check in config parsing
Jeff King wrote:
On Sun, Jan 13, 2013 at 06:42:01PM +0100, René Scharfe wrote:
When parsing these config variable names, we currently check that
the second dot is found nine characters into the name, disallowing
filter names with a length of five characters. Additionally,
git archive crashes when the second dot is omitted:
$ ./git -c tar.foo=bar archive HEAD >/dev/null
fatal: Data too large to fit into virtual memory space.
Instead we should check if the second dot exists at all, or if
we only found the first one.
Eek. Thanks for finding it. Your fix is obviously correct.
--- a/archive-tar.c
+++ b/archive-tar.c
@@ -335,7 +335,7 @@ static int tar_filter_config(const char *var,
const char *value, void *data) if (prefixcmp(var, "tar."))
return 0;
dot = strrchr(var, '.');
- if (dot == var + 9)
+ if (dot == var + 3)
return 0;
For the curious, the original version of the patch[1] read:
+ if (prefixcmp(var, "tarfilter."))
+ return 0;
+ dot = strrchr(var, '.');
+ if (dot == var + 9)
+ return 0;
and when I shortened the config section to "tar" in a re-roll of the
series, I missed the corresponding change to the offset.
Wouldn't it then be better ti use strlen("tar") rather than a 3? Or at least
a comment?
Bye, Jojo
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Test failures with python versions when building git 1.8.1
Jeff King wrote:
On Tue, Jan 01, 2013 at 11:18:46PM -0800, Junio C Hamano wrote:
Jeff King writes:
[1] This symlink is doubly wrong, because any use of symbolic links
in the test scripts needs to depend on the SYMLINKS prereq, and
this does not.
Yeah, I think we have discussed this once already in
http://thread.gmane.org/gmane.comp.version-control.git/210688/focus=210714
Thanks for the pointer; it looks like nothing productive came of the
earlier discussion. To give a hat trick of failure to this line of
code, I notice that the existing code also does not properly put
quotes around $GIT_BUILD_DIR.
[2] In both the current code and what I showed above, the test
scripts depend on things in contrib/. This is probably a bad
idea in general, as the quality of what goes into contrib is
not as closely watched (especially with respect to things like
portability). Certainly I would not have known to look more
carefully at a patch to contrib/svn-fe for breakage to the test
suite.
As long as such tests are made skippable with appropriate
prerequisites, I do not think it is bad to have their tests in t/; I
would say it is rather better than having them in contrib/ and leave
it not run by anybody, which happened to some of the stuff in
contrib/ already.
Good point. While my sense of decorum wants to keep contrib totally
split out, from a practical point of view, it is better to have more
people run the tests and report failures than not.
Whether we end up doing something with contrib and tests or not, the
patch below gives a minimal fix in the meantime. Dan, does it fix your
problem?
-- >8 --
Subject: [PATCH] t9020: don't run python from $PATH
In t9020, we symlink in a python script from contrib to help
with the testing. However, we don't munge its #!-line, which
means we may run the wrong python (we want the one in
PYTHON_PATH). On top of this, we use a symlink without
checking the SYMLINKS prereq, and we fail to properly quote
GIT_BUILD_DIR, which may have spaces.
Instead of symlinking, let's just write a small script which
will feed the contrib script to PYTHON_PATH. To avoid
quoting issues, we just export the variables the script
needs to run.
Signed-off-by: Jeff King
---
t/t9020-remote-svn.sh | 5 -
t/test-lib.sh | 2 +-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/t/t9020-remote-svn.sh b/t/t9020-remote-svn.sh
index 4f2dfe0..416623b 100755
--- a/t/t9020-remote-svn.sh
+++ b/t/t9020-remote-svn.sh
@@ -14,7 +14,10 @@ export PATH="$HOME:$PATH"
# We override svnrdump by placing a symlink to the svnrdump-emulator
in . export PATH="$HOME:$PATH"
With this patch that comment is no longer true.
-ln -sf $GIT_BUILD_DIR/contrib/svn-fe/svnrdump_sim.py "$HOME/svnrdump"
+export GIT_BUILD_DIR
+write_script svnrdump <<\EOF
+exec "$PYTHON_PATH" "$GIT_BUILD_DIR"/contrib/svn-fe/svnrdump_sim.py
"$@" +EOF
init_git () {
rm -fr .git &&
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Python version auditing followup
> From: Junio C Hamano [mailto:gits...@pobox.com] > Sent: Friday, December 21, 2012 7:28 PM > To: Joachim Schmitz > Cc: git@vger.kernel.org > Subject: Re: Python version auditing followup > > "Joachim Schmitz" writes: > > >> > We have a working 2.4.2 for HP-NonStop and some major problems getting > >> > 2.7.3 to work. > >> > >> I do not think a platform that stops at 2.4.2 instead of going to > >> higher 2.4.X series deserves to be called "long term maintained by > >> their vendors". It sounds more like "attempted to supply 2.4.X and > >> abandoned the users once one port was done" to me. > > > > Well, not entirely wrong, but not all true at too. > > I guess I need to defend the vendor here: It is not really the > > Vendor (HP) that provided Python 2.4.2 or tries to provide 2.7.3, > > it is a volunteer and community effort. HP did sponsor the 2.4.2 > > port though (by allowing an HP employee to do the port inn his > > regular working hours). It is not doing this any longer (since > > 2007). Since then it is a small group doing this on a purely > > voluntary basis in their spare time (one HP employee amongst them, > > me). Same goes for the git port BTW. > > For the purpose of "if we draw the line at 2.6, would it hurt many > people who have been happily using the existing release of Git that > was happy with 2.4", it is dubious HP-NonStop counts. It is not > like the users on that platform have been happily using Python based > Porcelain at the fringe of Git, and drawing the line at 2.6 will not > give them any regression. You asked for opions and obhections, you got mine ;-) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Python version auditing followup
> From: Junio C Hamano [mailto:gits...@pobox.com] > Sent: Thursday, December 20, 2012 10:39 PM > To: Joachim Schmitz > Cc: git@vger.kernel.org > Subject: Re: Python version auditing followup > > "Joachim Schmitz" writes: > > > Junio C Hamano wrote: > >> I personally would think 2.6 is recent enough. Which platforms that > >> are long-term-maintained by their vendors still pin their Python at > >> 2.4.X? 2.4.6 was in 2008 that was source only, 2.4.4 was in late > >> 2006 that was the last 2.4 with binary release. > >> > >> Objections? Comments? > > > > We have a working 2.4.2 for HP-NonStop and some major problems getting > > 2.7.3 to work. > > I do not think a platform that stops at 2.4.2 instead of going to > higher 2.4.X series deserves to be called "long term maintained by > their vendors". It sounds more like "attempted to supply 2.4.X and > abandoned the users once one port was done" to me. Well, not entirely wrong, but not all true at too. I guess I need to defend the vendor here: It is not really the Vendor (HP) that provided Python 2.4.2 or tries to provide 2.7.3, it is a volunteer and community effort. HP did sponsor the 2.4.2 port though (by allowing an HP employee to do the port inn his regular working hours). It is not doing this any longer (since 2007). Since then it is a small group doing this on a purely voluntary basis in their spare time (one HP employee amongst them, me). Same goes for the git port BTW. And for every other port provided on http://ituglib.connect-cummunity.org (this machine is sponsored by HP). Almost every other port, as some pretty recently made it into the officially supported O/S version, so far: Samba, bash, coreutils, vim, gzip, bzip2, Perl, PHP. Bye, Jojo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Python version auditing followup
Junio C Hamano wrote: e...@thyrsus.com (Eric S. Raymond) writes: That was the first of three patches I have promised. In order to do the next one, which will be a development guidelines recommend compatibility back to some specific version X, I need a policy decision. How do we set X? I don't think X can be < 2.4, nor does it need to be - 2.4 came out in 2004 and eight years is plenty of deployment time. The later we set it, the more convenient for developers. But of course by setting it late we trade away some portability to older systems. In previous discussion of this issue I recommended X = 2.6. That is still my recommendation. Thoughts, comments, objections? I personally would think 2.6 is recent enough. Which platforms that are long-term-maintained by their vendors still pin their Python at 2.4.X? 2.4.6 was in 2008 that was source only, 2.4.4 was in late 2006 that was the last 2.4 with binary release. Objections? Comments? We have a working 2.4.2 for HP-NonStop and some major problems getting 2.7.3 to work. Bye, Jojo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mergetools/p4merge: Honor $TMPDIR for the /dev/null placeholder
Junio C Hamano wrote: David Aguilar writes: Use mktemp to create the /dev/null placeholder for p4merge. This keeps it out of the current directory. Reported-by: Jeremy Morton Signed-off-by: David Aguilar --- I consider this a final finishing touch on a new 1.8.1 feature, so hopefully we can get this in before 1.8.1. Does everybody have mktemp(1), which is not even in POSIX.1? HP-NonStop doesn't have it, unless you're on the latest release, which added GNU coreutils. Bye, Jojo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Dec 2012, #04; Sun, 16)
Matt Kraai wrote: Junio C Hamano wrote: It could turn out that we may be able to get rid of sys/param.h altogether, but one step at a time. Inputs from people on minority platforms are very much appreciated---does your platform build fine when the inclusion of the file is removed from git-compat-util.h? QNX builds fine when sys/param.h is not included. HP-NonStop build fine too without it. Bye, Jojo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Port to QNX
Matt Kraai wrote: From: Matt Kraai Signed-off-by: Matt Kraai --- Makefile | 19 +++ git-compat-util.h | 8 ++-- 2 files changed, 25 insertions(+), 2 deletions(-) snip diff --git a/git-compat-util.h b/git-compat-util.h index 2e79b8a..6c588ca 100644 --- a/git-compat-util.h +++ b/git-compat-util.h @@ -75,7 +75,7 @@ # endif #elif !defined(__APPLE__) && !defined(__FreeBSD__) && !defined(__USLC__) && \ !defined(_M_UNIX) && !defined(__sgi) && !defined(__DragonFly__) && \ - !defined(__TANDEM) + !defined(__TANDEM) && !defined(__QNX__) #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 @@ -99,7 +99,7 @@ #include #include #include -#ifdef __TANDEM /* or HAVE_STRINGS_H or !NO_STRINGS_H? */ +#if defined(__TANDEM) || defined(__QNX__) /* or HAVE_STRINGS_H or !NO_STRINGS_H? */ #include /* for strcasecmp() */ There's another recent thread, discussing to change this to "#ifdef HAVE_STRING_H" plus the infrastructure in Makefile and configure.ac. Bye, Jojo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 4/4] Declare that HP NonStop systems require strings.h
> From: Johannes Sixt [mailto:j...@kdbg.org] > Sent: Saturday, December 15, 2012 12:17 AM > To: Joachim Schmitz > Cc: gits...@pobox.com; fedora@gmail.com; Git Mailing List > Subject: Re: [PATCH 4/4] Declare that HP NonStop systems require strings.h > > Am 14.12.2012 23:46, schrieb Joachim Schmitz: > > Johannes Sixt wrote: > >> Am 14.12.2012 20:57, schrieb David Michael: > >>> This platform previously included strings.h automatically. However, > >>> the build system now requires an explicit option to do so. > >>> > >>> Signed-off-by: David Michael > >>> --- > >>> Makefile | 1 + > >>> 1 file changed, 1 insertion(+) > >>> > >>> diff --git a/Makefile b/Makefile > >>> index fb78f7f..e84b0cb 100644 > >>> --- a/Makefile > >>> +++ b/Makefile > >>> @@ -1357,6 +1357,7 @@ ifeq ($(uname_S),NONSTOP_KERNEL) > >>> # Added manually, see above. > >>> NEEDS_SSL_WITH_CURL = YesPlease > >>> HAVE_LIBCHARSET_H = YesPlease > >>> +HAVE_STRINGS_H = YesPlease > >>> NEEDS_LIBICONV = YesPlease > >>> NEEDS_LIBINTL_BEFORE_LIBICONV = YesPlease > >>> NO_SYS_SELECT_H = UnfortunatelyYes > >> > >> If NONSTOP_KERNEL is the platform that defines __TANDEM, then this > >> should be squashed into the previous patch, shouldn't it? > > > > Patch 4/4 does not work without 3/4, Not for HP-NonStop. > > That is clear from the order of the patches in the series. > > To put it in a different way: Do all supported platforms still work > after 3/4, but without 4/4? Sorry I didn't make myself clear, I left out a "and vice versa" Bye, Jojo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] Declare that HP NonStop systems require strings.h
Johannes Sixt wrote: Am 14.12.2012 20:57, schrieb David Michael: This platform previously included strings.h automatically. However, the build system now requires an explicit option to do so. Signed-off-by: David Michael --- Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/Makefile b/Makefile index fb78f7f..e84b0cb 100644 --- a/Makefile +++ b/Makefile @@ -1357,6 +1357,7 @@ ifeq ($(uname_S),NONSTOP_KERNEL) # Added manually, see above. NEEDS_SSL_WITH_CURL = YesPlease HAVE_LIBCHARSET_H = YesPlease +HAVE_STRINGS_H = YesPlease NEEDS_LIBICONV = YesPlease NEEDS_LIBINTL_BEFORE_LIBICONV = YesPlease NO_SYS_SELECT_H = UnfortunatelyYes If NONSTOP_KERNEL is the platform that defines __TANDEM, then this should be squashed into the previous patch, shouldn't it? Patch 4/4 does not work without 3/4, Not for HP-NonStop. Bye, Jojo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Build fixes for another obscure Unix
David Michael wrote: Hi, On Thu, Dec 13, 2012 at 12:18 PM, Pyeron, Jason J CTR (US) wrote: Would there be any interest in applying such individual compatibility fixes for this system, even if a full port doesn't reach completion? What are the down sides? Can your changes be shown to not impact builds on other systems? I've pushed a handful of small compatibility patches to GitHub[1] which are enough to successfully compile the project. The default values of the new variables should make them unnoticeable to other systems. Are there any concerns with this type of change? If they would be acceptable, I can try sending the first four of those patches to the list properly. (I expect the last two may be tweaked as I continue working with the port.) I do have a concern with strings.h, though. That file will be included for most people who run ./configure, when it wasn't before. Do you think it's worth making a more detailed test to see if strcasecmp is still undefined after string.h is included, rather than just testing for the header's existence? Thanks. David [1] https://github.com/dm0-/git/commits For what's it worth: I ACK your HP-NonStop patch (as you can see by my comment in git-compat-util.h I was thinking along the same line) https://github.com/dm0-/git/commit/933d72a5cfdc63fa9c3c68afa2f4899d9c3f791e together with its prerequisit https://github.com/dm0-/git/commit/301032c6488aeabb94ccc81bfb6d65ff2c23b924 ACKed by: Joachim Schmitz -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix sizeof usage in get_permutations
Matthew Daley wrote:
Currently it gets the size of an otherwise unrelated, unused variable
instead of the expected struct size.
Signed-off-by: Matthew Daley
---
builtin/pack-redundant.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin/pack-redundant.c b/builtin/pack-redundant.c
index f5c6afc..7544687 100644
--- a/builtin/pack-redundant.c
+++ b/builtin/pack-redundant.c
@@ -301,14 +301,14 @@ static void pll_free(struct pll *l)
*/
static struct pll * get_permutations(struct pack_list *list, int n)
{
- struct pll *subset, *ret = NULL, *new_pll = NULL, *pll;
+ struct pll *subset, *ret = NULL, *new_pll = NULL;
if (list == NULL || pack_list_size(list) < n || n == 0)
return NULL;
if (n == 1) {
while (list) {
- new_pll = xmalloc(sizeof(pll));
+ new_pll = xmalloc(sizeof(struct pll));
new_pll->pl = NULL;
pack_list_insert(&new_pll->pl, list);
new_pll->next = ret;
@@ -321,7 +321,7 @@ static struct pll * get_permutations(struct
pack_list *list, int n) while (list->next) {
subset = get_permutations(list->next, n - 1);
while (subset) {
- new_pll = xmalloc(sizeof(pll));
+ new_pll = xmalloc(sizeof(struct pll));
Why not just
new_pll = xmalloc(sizeof(*new_pll));
new_pll->pl = subset->pl;
pack_list_insert(&new_pll->pl, list);
new_pll->next = ret;
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] Completion must sort before using uniq
> From: Sascha Cunz [mailto:sascha...@babbelbox.org] > Sent: Friday, November 23, 2012 1:26 PM > To: Joachim Schmitz > Cc: 'Marc Khouzam'; git@vger.kernel.org; sze...@ira.uka.de; > felipe.contre...@gmail.com > Subject: Re: [PATCH] Completion must sort before using uniq > > > I can't see the difference and in fact don't understand uniq's -u option al > > all Linux man pages say: "only print unique lines", but that is what uniq > > does by default anyway?!? > > From the german translation of uniq's man-page, you can deduct that "only > print unique lines" actually means: "print lines that are _not repeated_ in > the input". > > A short test confirms that. i.e.: > > printf "a\nb\nb\nc\n" | uniq -u > > gives: > a > c Ah, OK, then I rest my case. Sorry for the noise. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] Completion must sort before using uniq
Re-adding git@vger... > From: Marc Khouzam [mailto:marc.khou...@gmail.com] > Sent: Friday, November 23, 2012 11:51 AM > To: Joachim Schmitz > Cc: sze...@ira.uka.de; felipe.contre...@gmail.com > Subject: Re: [PATCH] Completion must sort before using uniq > > On Fri, Nov 23, 2012 at 3:10 AM, Joachim Schmitz > wrote: > > Marc Khouzam wrote: > >> The uniq program only works with sorted input. The man page states > >> "uniq prints the unique lines in a sorted file". > > ... > >> --- a/contrib/completion/git-completion.bash > >> +++ b/contrib/completion/git-completion.bash > >> @@ -321,7 +321,7 @@ __git_refs () > >>if [[ "$ref" == "$cur"* ]]; then > >>echo "$ref" > >>fi > >> - done | uniq -u > >> + done | sort | uniq -u > > > > Is 'sort -u' not universally available and sufficient here? It is POSIX > > at least: > > http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sort.html > > "-u Unique: suppress all but one in each set of lines having equal > keys. If used with the -c option, check that there are no lines with > duplicate keys, in addition to checking that the input file is > sorted." > > What the code aims to do is to only show lines that are not > duplicated. 'sort -u' would still output one line for each duplicated > one. It seems 'sort -u' is the equivalent of 'sort | uniq' but won't > replace 'sort | uniq -u'. I can't see the difference and in fact don't understand uniq's -u option al all Linux man pages say: "only print unique lines", but that is what uniq does by default anyway?!? > Is 'sort | uniq -u' not POSIX? It is. It is one process more though. Bye, Jojo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8] fix git-config with duplicate variable entries
Junio C Hamano wrote: Jeff King writes: ... Not exactly. There are three classes of people: - wrote scripts using --get; found out that --get barfs if you feed two or more of the same, and have long learned to accept it as a limitation and adjusted their configuration files to avoid it. They have been doing just fine and wouldn't benefit from this series at all. - wrote scripts using --get, relying on it barfing if fed zero (i.e. missing) or two or more (i.e. ambiguous), perhaps a way to keep their configuration files (arguably unnecessarily) clean. They are directly harmed by this series. - wrote scripts using --get-all and did the last-one-wins themselves. They wouldn't benefit directly from this series, unless they are willing to spend a bit of time to remove their own last-one-wins logic and replace --get-all with --get (but the same effort is needed to migrate to --get-one). - wanted to write scripts using --get, but after finding out that it barfs if you feed two, gave up emulating the internal, without realizing that they could do so with --get-all. They can now write their scripts without using --get-all. There are three classes ofpeople: those that can count and those that can't Sorry could not resist ;-) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Completion must sort before using uniq
Marc Khouzam wrote: The uniq program only works with sorted input. The man page states "uniq prints the unique lines in a sorted file". ... --- a/contrib/completion/git-completion.bash +++ b/contrib/completion/git-completion.bash @@ -321,7 +321,7 @@ __git_refs () if [[ "$ref" == "$cur"* ]]; then echo "$ref" fi - done | uniq -u + done | sort | uniq -u Is 'sort -u' not universally available and sufficient here? It is POSIX at least: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sort.html Bye, Jojo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2] fix 'make test' for HP NonStop
> From: Jeff King [mailto:p...@peff.net] > Sent: Monday, October 29, 2012 8:07 AM > To: Joachim Schmitz > Cc: git@vger.kernel.org > Subject: Re: [PATCH v2] fix 'make test' for HP NonStop > > On Thu, Oct 25, 2012 at 12:57:10PM +0200, Joachim Schmitz wrote: > > > diff --git a/Makefile b/Makefile > > index f69979e..35380dd 100644 > > --- a/Makefile > > +++ b/Makefile > > @@ -1381,6 +1381,15 @@ ifeq ($(uname_S),NONSTOP_KERNEL) > > MKDIR_WO_TRAILING_SLASH = YesPlease > > # RFE 10-120912-4693 submitted to HP NonStop development. > > NO_SETITIMER = UnfortunatelyYes > > + > > + # for 'make test' > > + # some test don't work with /bin/diff, some fail with /bin/tar > > + # some need bash, and some need /usr/local/bin in PATH first > > + SHELL_PATH=/usr/local/bin/bash > > + SANE_TOOL_PATH=/usr/local/bin > > I think we can drop these comments, as the reasoning really should just > go in the commit message. OK by me. > > + # as of H06.25/J06.14, we might better use this > > + #SHELL_PATH=/usr/coreutils/bin/bash > > + #SANE_TOOL_PATH=/usr/coreutils/bin:/usr/local/bin > > Is there any reason not to put both into the default SANE_TOOL_PATH? If > /usr/coreutils/bin does not exist on older versions, it will be a > harmless no-op. I guess we arestuck with picking one $SHELL_PATH, > though. And because of that have to modify something anyway... But I don't really mind about an extended SANE_TOOL_PATH > -Peff Bye, Jojo -- 8< -- This fixes the vast majority of test failures on HP NonStop. Some test don't work with /bin/diff, some fail with /bin/tar, so let's put /usr/local/bin in PATH first. Some tests fail with /bin/sh (link to /bin/ksh) so use bash instead Signed-off-by: Joachim Schmitz --- Makefile | 9 + 1 file changed, 9 insertions(+) diff --git a/Makefile b/Makefile index f69979e..35380dd 100644 --- a/Makefile +++ b/Makefile @@ -1381,6 +1381,10 @@ ifeq ($(uname_S),NONSTOP_KERNEL) MKDIR_WO_TRAILING_SLASH = YesPlease # RFE 10-120912-4693 submitted to HP NonStop development. NO_SETITIMER = UnfortunatelyYes + SANE_TOOL_PATH=/usr/coreutils/bin:/usr/local/bin + SHELL_PATH=/usr/local/bin/bash + # as of H06.25/J06.14, we might better use this + #SHELL_PATH=/usr/coreutils/bin/bash endif ifneq (,$(findstring MINGW,$(uname_S))) pathsep = ; -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] fix 'make test' for HP NonStop
> From: Jeff King [mailto:p...@peff.net] > Sent: Thursday, October 25, 2012 12:53 PM > To: Joachim Schmitz > Cc: git@vger.kernel.org > Subject: Re: [PATCH] fix 'make test' for HP NonStop > > On Thu, Oct 25, 2012 at 12:51:59PM +0200, Joachim Schmitz wrote: > > > > But then I would think using /usr/local would be the sane thing to put > > > there, if that is the closest to "standard" for your platform. > > > > OK, yes, hardcoding /usr/local seems OK too. > > Would I need to re-roll? > > Please do. Done. For some reason not 'chained' to this thread though Bye, Jojo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2] fix 'make test' for HP NonStop
This fixes the vast majority of test failures on HP NonStop.
Signed-off-by: Joachim Schmitz
---
v2: hardcode /usr/local rather than using ${prefix}
Makefile | 9 +
1 file changed, 9 insertions(+)
diff --git a/Makefile b/Makefile
index f69979e..35380dd 100644
--- a/Makefile
+++ b/Makefile
@@ -1381,6 +1381,15 @@ ifeq ($(uname_S),NONSTOP_KERNEL)
MKDIR_WO_TRAILING_SLASH = YesPlease
# RFE 10-120912-4693 submitted to HP NonStop development.
NO_SETITIMER = UnfortunatelyYes
+
+ # for 'make test'
+ # some test don't work with /bin/diff, some fail with /bin/tar
+ # some need bash, and some need /usr/local/bin in PATH first
+ SHELL_PATH=/usr/local/bin/bash
+ SANE_TOOL_PATH=/usr/local/bin
+ # as of H06.25/J06.14, we might better use this
+ #SHELL_PATH=/usr/coreutils/bin/bash
+ #SANE_TOOL_PATH=/usr/coreutils/bin:/usr/local/bin
endif
ifneq (,$(findstring MINGW,$(uname_S)))
pathsep = ;
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] fix 'make test' for HP NonStop
> From: Jeff King [mailto:p...@peff.net]
> Sent: Thursday, October 25, 2012 12:49 PM
> To: Joachim Schmitz
> Cc: git@vger.kernel.org
> Subject: Re: [PATCH] fix 'make test' for HP NonStop
>
> On Thu, Oct 25, 2012 at 12:21:44PM +0200, Joachim Schmitz wrote:
>
> > > > + # for 'make test'
> > > > + # some test don't work with /bin/diff, some fail with /bin/tar
> > > > + # some need bash, and some need ${prefix}/bin in PATH first
> > > > + SHELL_PATH=${prefix}/bin/bash
> > > > + SANE_TOOL_PATH=${prefix}/bin
> > >
> > > This feels a little too specific to go in our Makefile. Do we have any
> > > reason to think that where you are installing git is going to be the
> > > same place you have bash and other sane tools? Wouldn't this mean that
> > > things work when you run "make" but mysteriously break when you run
> > > "make prefix=/my/local/install/of/git"?
> >
> > Well, "make" won't break (I think), but "make test" very well might.
>
> Sure.
>
> > Well, so far all OpenSource packages ported to HP NonStop (at least
> > the ones on ituglib.connect-community.org) use prefix=/usr/local and
> > there is no intention to change that.
>
> But then I would think using /usr/local would be the sane thing to put
> there, if that is the closest to "standard" for your platform.
OK, yes, hardcoding /usr/local seems OK too.
Would I need to re-roll?
Bye, Jojo
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] fix 'make test' for HP NonStop
> From: Jeff King [mailto:p...@peff.net]
> Sent: Thursday, October 25, 2012 11:58 AM
> To: Joachim Schmitz
> Cc: git@vger.kernel.org
> Subject: Re: [PATCH] fix 'make test' for HP NonStop
>
> On Mon, Oct 22, 2012 at 04:30:17PM +0200, Joachim Schmitz wrote:
>
> > + # for 'make test'
> > + # some test don't work with /bin/diff, some fail with /bin/tar
> > + # some need bash, and some need ${prefix}/bin in PATH first
> > + SHELL_PATH=${prefix}/bin/bash
> > + SANE_TOOL_PATH=${prefix}/bin
>
> This feels a little too specific to go in our Makefile. Do we have any
> reason to think that where you are installing git is going to be the
> same place you have bash and other sane tools? Wouldn't this mean that
> things work when you run "make" but mysteriously break when you run
> "make prefix=/my/local/install/of/git"?
Well, "make" won't break (I think), but "make test" very well might.
Well, so far all OpenSource packages ported to HP NonStop (at least the ones on
ituglib.connect-community.org) use prefix=/usr/local and there is no intention
to change that.
A few (bash, vim, coreutils, tar, gzip, bzip2) get delivered with the system
meanwhile (rather than having to be downloaded and installed by the customer)
and live in /usr/corutiles. Still more are needed (e.g. diff , make).
The next lines in my patch cater for that, it is missing though an automatic
switch.
Such a switch would be possible, using 'uname -r' and 'uname -v', but pretty
convoluted
Pseudo code:
If (`uname -r` = J06 && `uname -v` >= 14) || (`uname -r`= H06 && `uname -v` >=
25)
SHELL_PATH=/usr/coreutils/bin/bash
SANE_TOOL_PATH=/usr/coreutils/bin:${prefix}/bin
else
SHELL_PATH=${prefix}/bin/bash
SANE_TOOL_PATH=${prefix}/bin
endif
I didn't deem it worth the effort. As mentioned it'd most likely still need
stuff from /usr/local/bin
And someone wanting prefix somewhere else could still do
PATH=/usr/local/bin:$PATH make prefix=/my/local/install/of/git
And so find what's need in either the 1st or 2nd path of PATH
Bye, Jojo
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
git daemon test fails
Here's one test failing (on HP NonStop, git-1.8.0), which needs to get enable first. /home/jojo/git/git/t $ PATH=/usr/local/bin:$PATH GIT_TEST_GIT_DAEMON=true bash ./t5570-git-daemon.sh ok 1 - setup repository ok 2 - create git-accessible bare repository ok 3 - clone git repository [946798748] Connection from 127.0.0.1:1569 [946798748] Extended attributes (21 bytes) exist [946798748] Request upload-pack for '/repo.git' [577699972] [946798748] Disconnected ok 4 - fetch changes via git protocol [275710128] Connection from 127.0.0.1:1570 [275710128] Extended attributes (21 bytes) exist [275710128] Request upload-pack for '/repo.git' [577699972] [275710128] Disconnected not ok 5 - remote detects correct HEAD # TODO known breakage ok 6 - prepare pack objects ok 7 - fetch notices corrupt pack [611254461] Connection from 127.0.0.1:1571 [611254461] Extended attributes (21 bytes) exist [611254461] Request upload-pack for '/repo_bad2.git' [611254461] error: non-monotonic index ./objects/pack/pack-a8625557c4445f4dac0b3b70b03f0a619d8edbff.idx [611254461] error: unable to find 8a64388133550192054d8f512739602b36fdd015 [611254461] error: non-monotonic index ./objects/pack/pack-a8625557c4445f4dac0b3b70b03f0a619d8edbff.idx [611254461] error: non-monotonic index ./objects/pack/pack-a8625557c4445f4dac0b3b70b03f0a619d8edbff.idx [611254461] error: refs/heads/master does not point to a valid object! [611254461] error: non-monotonic index ./objects/pack/pack-a8625557c4445f4dac0b3b70b03f0a619d8edbff.idx [611254461] error: refs/heads/other does not point to a valid object! [611254461] error: git upload-pack: git-pack-objects died with error. [611254461] fatal: git upload-pack: aborting due to possible repository corruption on the remote side. [577699972] [611254461] Disconnected (with error) ok 8 - fetch notices corrupt idx [711917757] Connection from 127.0.0.1:9908 [711917757] Extended attributes (21 bytes) exist [711917757] Request upload-pack for '/nowhere.git' [711917757] '/home/jojo/git/git/t/trash directory.t5570-git-daemon/repo/nowhere.git' does not appear to be a git repository [577699972] [711917757] Disconnected (with error) ok 9 - clone non-existent [779026621] Connection from 127.0.0.1:9909 [779026621] Extended attributes (21 bytes) exist [779026621] Request receive-pack for '/repo.git' [779026621] 'receive-pack': service not enabled for '/home/jojo/git/git/t/trash directory.t5570-git-daemon/repo/repo.git' [577699972] [779026621] Disconnected (with error) ok 10 - push disabled [846135485] Connection from 127.0.0.1:9910 [846135485] Extended attributes (21 bytes) exist [846135485] Request upload-pack for '/repo.git' [846135485] '/home/jojo/git/git/t/trash directory.t5570-git-daemon/repo/repo.git' does not appear to be a git repository [577699972] [846135485] Disconnected (with error) ok 11 - read access denied [913244349] Connection from 127.0.0.1:9911 [913244349] Extended attributes (21 bytes) exist [913244349] Request upload-pack for '/repo.git' [913244349] '/home/jojo/git/git/t/trash directory.t5570-git-daemon/repo/repo.git': repository not exported. [577699972] [913244349] Disconnected (with error) ok 12 - not exported [1013907645] Connection from 127.0.0.1:9912 [1013907645] Extended attributes (21 bytes) exist [1013907645] Request upload-pack for '/nowhere.git' [1013907645] '/home/jojo/git/git/t/trash directory.t5570-git-daemon/repo/nowhere.git' does not appear to be a git repository [577699972] [1013907645] Disconnected (with error) not ok - 13 clone non-existent # test_remote_error'no such repository' clone nowhere.git ok 14 - push disabled ok 15 - read access denied ok 16 - not exported # still have 1 known breakage(s) # failed 1 among remaining 15 test(s) 1..16 So one test fails. But in real live here on HP NonStop "git clone" fails for any repository larger than a certain size (56k?) and it fails on the daemon side (as e.g. a "git clone git://Gitgub/com/git/git.git" works just fine) $ git clone git://localhost/some-repo.git Cloning into 'some-repo'... remote: warning: no threads support, ignoring --threads remote: Counting objects: 485, done. remote: Compressing objects: 100% (472/472), done. here it sits forever or until a timeout hits (if one is configured) fatal: The remote end hung up unexpectedly fatal: early EOF fatal: index-pack failed If I allow upload-archive, I get some 47k downloaded, then it hangs (and doesn't get killed by a timeout, so that "git-daemon --timeout" only affects upload-pack apparently?) Also it is always only a tar file, regardless whether I request zip, tar or tar.gz. Any ideas anyone? Bye, Jojo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] fix 'make test' for HP NonStop
This fixes the vast majority of test failures on HP NonStop.
Signed-off-by: Joachim Schmitz
---
A few more still insist on /usr/local/bin being 1st in PATH and having done that
we're down to one single failing test, t0301 #12 "helper (cache --timeout=1)
times out"
Makefile | 9 +
1 file changed, 9 insertions(+)
diff --git a/Makefile b/Makefile
index f69979e..35380dd 100644
--- a/Makefile
+++ b/Makefile
@@ -1381,6 +1381,15 @@ ifeq ($(uname_S),NONSTOP_KERNEL)
MKDIR_WO_TRAILING_SLASH = YesPlease
# RFE 10-120912-4693 submitted to HP NonStop development.
NO_SETITIMER = UnfortunatelyYes
+
+ # for 'make test'
+ # some test don't work with /bin/diff, some fail with /bin/tar
+ # some need bash, and some need ${prefix}/bin in PATH first
+ SHELL_PATH=${prefix}/bin/bash
+ SANE_TOOL_PATH=${prefix}/bin
+ # as of H06.25/J06.14, we might better use this
+ #SHELL_PATH=/usr/coreutils/bin/bash
+ #SANE_TOOL_PATH=/usr/coreutils/bin:${prefix}/bin
endif
ifneq (,$(findstring MINGW,$(uname_S)))
pathsep = ;
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: make test
"Joachim Schmitz" schrieb im Newsbeitrag
news:...
> Hi folks
>
> I'm trying to understand why certain tests in 'make test' fail. Here's the
> first one
>
> $ ../git --version
> git version 1.8.0.rc2.5.g6b89306
> $ GIT_TEST_CMP_USE_COPIED_CONTEXT=true ./t-basic.sh # our diff doesn't
> understand -u
> ok 1 - .git/objects should be empty after git init in an empty repo
> ...
> ok 3 - success is reported like this
> not ok 4 - pretend we have a known breakage # TODO known breakage
>
> This is expected, right?
>
> ok 5 - pretend we have fixed a known breakage (run in sub test-lib)
> ...
> ok 11 - tests clean up after themselves
>
> the next is not though? Why might it be failing, where to check?
>
> not ok - 12 tests clean up even on failures
> #
> # mkdir failing-cleanup &&
> # (
> # cd failing-cleanup &&
> #
> # cat >failing-cleanup.sh <<-EOF &&
> # #!/bin/sh
> #
> # test_description='Failing tests with cleanup commands'
> #
> # # Point to the t/test-lib.sh, which isn't in ../ as usual
> # TEST_DIRECTORY="/home/jojo/git/git/t"
> # . "$TEST_DIRECTORY"/test-lib.sh
> #
> # test_expect_success 'tests clean up even after a failure' '
> # touch clean-after-failure &&
> # test_when_finished rm clean-after-failure &&
> # (exit 1)
> # '
> # test_expect_success 'failure to clean up causes the test to
> fail' '
> # test_when_finished "(exit 2)"
> # '
> # test_done
> #
> # EOF
> #
> # chmod +x failing-cleanup.sh &&
> # test_must_fail ./failing-cleanup.sh >out 2>err &&
> # ! test -s err &&
> # ! test -f "trash
> directory.failing-cleanup/clean-after-failure" &&
> # sed -e 's/Z$//' -e 's/^> //' >expect <<-\EOF &&
> # > not ok - 1 tests clean up even after a failure
> # > # Z
> # > # touch clean-after-failure &&
> # > # test_when_finished rm clean-after-failure &&
> # > # (exit 1)
> # > # Z
> # > not ok - 2 failure to clean up causes the test to fail
> # > # Z
> # > # test_when_finished "(exit 2)"
> # > # Z
> # > # failed 2 among 2 test(s)
> # > 1..2
> # EOF
> # test_cmp expect out
> # )
> #
> ok 13 - git update-index without --add should fail adding
> ...
> ok 47 - very long name in the index handled sanely
> # still have 1 known breakage(s)
> # failed 1 among remaining 46 test(s)
> 1..47
As mentioned elsethread this works if using bash rather than the system's sh
(which is a ksh)
But there are several other failures. After some investigations and experiments
I found the following tests to fail with the system
provided grep (for which I had to set GIT_TEST_CMP_USE_COPIED_CONTEXT), but
succeed with GNU grep:
t3308 #14, #15, #17and #19
t3310 #10, #12, #14 and #18
t4047 #38 and #39
t4050 #2 and #3
t4116 #3, #4 and #5
t5509 #2
t7401 #18
The following fail with the system provided tar, but succeed with GNU tar:
t0024 #2
t4116 #4,
t5000 #14, #16, #20, #24, #26 and #51
t5001 #2, #6, #10 and #15
The following tests fail with the system provided sh (which is a ksh really),
but succeed with bash:
t #12
t0001 #20
t1450 #17 and #18
(t0204 #3 and #8 succeed in sh but fail in bash. They succeed in bash too when
/usr/local/bin is in PATH first though, which would
sort the diff and tar problem too, need to investigate why)
t3006 #2 and #3
t3403 #4, #5, #8 and #9
t3404 #2 - #13, #14 - #18, #20 - #41, #44, #46 - #70
t3409 #2 - #5
t3410 #2 and #3
t3411 #2 and #3
t3412 #8, #10 - #12, #15, #17, #23, #25, -26, #28, #29, #31
t3413 #3, #5 - #10, #14, #15
and many more...
The following needs bash and /usr/local/bin first in PATH
("PATH=/usr/local/bin:$PATH make test")
t0204 #3 and #8 (or just sh, see above)
t3032 #11
t3900 #24, #25
t4201 #8
t5000 #14
t5150 #6
I though "SANE_TOOL_PATH=/usr/local/bin" plus "SHELL_PATH=/usr/local/bin/bash"
would to fix the all but it does not and instead
brings up some other failures too:
t5521 #2
RE: make test
> From: Joachim Schmitz [mailto:j...@schmitz-digital.de] > Sent: Monday, October 15, 2012 3:18 PM > To: 'Andreas Schwab'; 'Johannes Sixt' > Cc: 'git@vger.kernel.org' > Subject: RE: make test > > > From: Andreas Schwab [mailto:sch...@linux-m68k.org] > > Sent: Monday, October 15, 2012 2:35 PM > > To: Johannes Sixt > > Cc: Joachim Schmitz; git@vger.kernel.org > > Subject: Re: make test > > > > Johannes Sixt writes: > > > > > Am 10/15/2012 13:58, schrieb Joachim Schmitz: > > >> ++ mkdir failing-cleanup > > >> ++ cd failing-cleanup > > >> ++ cat > > >> ++ chmod +x failing-cleanup.sh > > >> ++ test_must_fail ./failing-cleanup.sh > > >> + eval_ret=1 > > > > > > I wonder why the log does not show the commands of function > > > test_must_fail. > > > > That's because stderr is redirected. > > > > cat err > ++ ./failing-cleanup.sh > ++ exit_code=0 > ++ test 0 = 0 > ++ echo 'test_must_fail: command succeeded: ./failing-cleanup.sh' > test_must_fail: command succeeded: ./failing-cleanup.sh > ++ return 1 That test (as well as quite a few more) do pass when using bash rather than our sh (which really is a ksh) Bye, Jojo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC/PATCH 3/4] test-lib: provide lazy TIME_COMMAND prereq
> From: Michael J Gruber [mailto:g...@drmicha.warpmail.net] > Sent: Tuesday, October 16, 2012 5:07 PM > To: Joachim Schmitz > Cc: git@vger.kernel.org; 'Junio C Hamano' > Subject: Re: [RFC/PATCH 3/4] test-lib: provide lazy TIME_COMMAND prereq > > Joachim Schmitz venit, vidit, dixit 16.10.2012 16:13: > >> From: Michael J Gruber [mailto:g...@drmicha.warpmail.net] > >> Sent: Tuesday, October 16, 2012 1:40 PM > >> To: git@vger.kernel.org > >> Cc: Joachim Schmitz; Junio C Hamano > >> Subject: [RFC/PATCH 3/4] test-lib: provide lazy TIME_COMMAND prereq > >> > >> Some test want to use the time command (not the shell builtin) and test > >> for its availability at /usr/bin/time. > >> > >> Provide a lazy prereq TIME_COMMAND which tests for /usr/bin/time and > >> /bin/time. If any is found, set TEST_COMMAND_PATH to the first match. > >> > >> Signed-off-by: Michael J Gruber > >> --- > >> Rather than iterating over 2 or more hardcoded paths, one could use > >> "test -P time" or allow a make variable TIME_COMMAND_PATH whose > > > > test -P time won't work for me: > > test -P: unary operator expected > > > > I do have another one in /usr/local/bin, maybe that could get added too? > > Yikes. > > If we introduce a make variable TIME_COMMAND_PATH we can even get rid of > 2/4 (but have to change Makefile or t/Makefile). I don't mind too much. /usr/bin/time and /bin/time should be enough. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC/PATCH 3/4] test-lib: provide lazy TIME_COMMAND prereq
> From: Michael J Gruber [mailto:g...@drmicha.warpmail.net] > Sent: Tuesday, October 16, 2012 1:40 PM > To: git@vger.kernel.org > Cc: Joachim Schmitz; Junio C Hamano > Subject: [RFC/PATCH 3/4] test-lib: provide lazy TIME_COMMAND prereq > > Some test want to use the time command (not the shell builtin) and test > for its availability at /usr/bin/time. > > Provide a lazy prereq TIME_COMMAND which tests for /usr/bin/time and > /bin/time. If any is found, set TEST_COMMAND_PATH to the first match. > > Signed-off-by: Michael J Gruber > --- > Rather than iterating over 2 or more hardcoded paths, one could use > "test -P time" or allow a make variable TIME_COMMAND_PATH whose test -P time won't work for me: test -P: unary operator expected I do have another one in /usr/local/bin, maybe that could get added too? > executability is checked by the prereq. I really don't know what's best. > > t/test-lib.sh | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/t/test-lib.sh b/t/test-lib.sh > index 489bc80..7977c15 100644 > --- a/t/test-lib.sh > +++ b/t/test-lib.sh > @@ -738,6 +738,13 @@ test_lazy_prereq UTF8_NFD_TO_NFC ' > esac > ' > > +test_lazy_prereq TIME_COMMAND ' > + for command in /usr/bin/time /bin/time > + do > + test -x "$command" && break > + done && TIME_COMMAND_PATH="$command" > +' > + > # When the tests are run as root, permission tests will report that > # things are writable when they shouldn't be. > test -w / || test_set_prereq SANITY > -- > 1.8.0.rc2.304.g9f3ac5c -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: make test
> From: Andreas Schwab [mailto:sch...@linux-m68k.org] > Sent: Monday, October 15, 2012 2:35 PM > To: Johannes Sixt > Cc: Joachim Schmitz; git@vger.kernel.org > Subject: Re: make test > > Johannes Sixt writes: > > > Am 10/15/2012 13:58, schrieb Joachim Schmitz: > >> ++ mkdir failing-cleanup > >> ++ cd failing-cleanup > >> ++ cat > >> ++ chmod +x failing-cleanup.sh > >> ++ test_must_fail ./failing-cleanup.sh > >> + eval_ret=1 > > > > I wonder why the log does not show the commands of function > > test_must_fail. > > That's because stderr is redirected. > cat err ++ ./failing-cleanup.sh ++ exit_code=0 ++ test 0 = 0 ++ echo 'test_must_fail: command succeeded: ./failing-cleanup.sh' test_must_fail: command succeeded: ./failing-cleanup.sh ++ return 1 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: make test
> From: Johannes Sixt [mailto:j.s...@viscovery.net] > Sent: Monday, October 15, 2012 2:10 PM > To: Joachim Schmitz > Cc: git@vger.kernel.org > Subject: Re: make test > > Am 10/15/2012 13:58, schrieb Joachim Schmitz: > > ++ mkdir failing-cleanup > > ++ cd failing-cleanup > > ++ cat > > ++ chmod +x failing-cleanup.sh > > ++ test_must_fail ./failing-cleanup.sh > > + eval_ret=1 > > I wonder why the log does not show the commands of function > test_must_fail. Is there a 'set +x' hidden somewhere? Run > ./failing-cleanup.sh manually. Check its exit code (it should be non-zero, > but not something strange like 127 and above; see test_must_fail()) and > dig further from there. I'll stop here. It returns 0. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: make test
> -Original Message- > From: Johannes Sixt [mailto:j.s...@viscovery.net] > Sent: Monday, October 15, 2012 1:53 PM > To: Joachim Schmitz > Cc: git@vger.kernel.org > Subject: Re: make test > > Am 10/15/2012 13:37, schrieb Joachim Schmitz: > > ... > > + eval ' > > find .git/objects -type f -print >should-be-empty && > > test_line_count = 0 should-be-empty > > ' > > ++ find .git/objects -type f -print > > ++ test_line_count = 0 should-be-empty > > ++ test 3 '!=' 3 > > +++ wc -l > > ++ test 0 = 0 > > + eval_ret=0 > > This is the key line. If it is 'eval_ret=1' (or other non-zero value), > then the test failed, and the lines above it usually indicate where in the > test snippet the failure occurred. ... ++ mkdir failing-cleanup ++ cd failing-cleanup ++ cat ++ chmod +x failing-cleanup.sh ++ test_must_fail ./failing-cleanup.sh + eval_ret=1 + test -z t + test 1 = 0 + test -n '' + test t = t + test -n '' + return 1 + test_failure_ 'tests clean up even on failures' ' ... This part? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: make test
> From: Johannes Sixt [mailto:j.s...@viscovery.net]
> Sent: Monday, October 15, 2012 1:18 PM
> To: Joachim Schmitz
> Cc: git@vger.kernel.org
> Subject: Re: make test
>
> Am 10/15/2012 13:00, schrieb Joachim Schmitz:
> >> From: Johannes Sixt [mailto:j.s...@viscovery.net]
> >> and if that does not give sufficient clues,
> >>
> >> $SHELL_PATH -x ./t-basic.sh -v -i
> >
> > not ok - 12 tests clean up even on failures
> > #...
> > + die
> >
> > Looks identical, except for the "die" at the end. And still leaves me
> > without a clue...
>
> When I do that it begins like this (I'm on Windows):
>
> D:\Src\mingw-git\t>bash -x t-basic.sh -v -i
> + test_description='Test the very basics part #1.
> ...
> '
> + . ./test-lib.sh
> ++ ORIGINAL_TERM=cygwin
> ++ test -z ''
> +++ pwd
> ++ TEST_DIRECTORY=/d/Src/mingw-git/t
> ++ test -z ''
> ++ TEST_OUTPUT_DIRECTORY=/d/Src/mingw-git/t
> ++ GIT_BUILD_DIR=/d/Src/mingw-git/t/..
> ++ /d/Src/mingw-git/t/../git
> ++ test 1 '!=' 1
> ++ . /d/Src/mingw-git/t/../GIT-BUILD-OPTIONS
> +++ SHELL_PATH=/bin/sh
> +++ PERL_PATH=/usr/bin/perl
> +++ DIFF=diff
> +++ PYTHON_PATH=/usr/bin/python
> +++ TAR=tar
> ...
>
> It seems you need a shell that is verbose under -x.
Erm, no, I left that part out...
+ . ./test-lib.sh
++ ORIGINAL_TERM=dumb
++ test -z ''
+++ pwd
++ TEST_DIRECTORY=/home/jojo/git/git/t
++ test -z ''
++ TEST_OUTPUT_DIRECTORY=/home/jojo/git/git/t
++ GIT_BUILD_DIR=/home/jojo/git/git/t/..
++ /home/jojo/git/git/t/../git
++ test 1 '!=' 1
++ . /home/jojo/git/git/t/../GIT-BUILD-OPTIONS
+++ SHELL_PATH=/bin/sh
+++ PERL_PATH=/usr/local/bin/perl
+++ DIFF=diff
+++ PYTHON_PATH=/usr/local/bin/python
+++ TAR=tar
+++ NO_CURL=
+++ USE_LIBPCRE=
+++ NO_PERL=
+++ NO_PYTHON=
+++ NO_UNIX_SOCKETS=
+++ GIT_TEST_CMP_USE_COPIED_CONTEXT=YesPlease
+++ NO_GETTEXT=
+++ GETTEXT_POISON=
++ export PERL_PATH SHELL_PATH
++ case "$GIT_TEST_TEE_STARTED, $* " in
++ LANG=C
++ LC_ALL=C
++ PAGER=cat
++ TZ=UTC
++ TERM=dumb
++ export LANG LC_ALL PAGER TERM TZ
++ EDITOR=:
+++ /usr/local/bin/perl -e '
my @env = keys %ENV;
my $ok = join("|", qw(
TRACE
DEBUG
USE_LOOKUP
TEST
.*_TEST
PROVE
VALGRIND
PERF_AGGREGATING_LATER
));
my @vars = grep(/^GIT_/ && !/^GIT_($ok)/o, @env);
print join("\n", @vars);
'
++ unset VISUAL EMAIL LANGUAGE COLUMNS GIT_AUTHOR_NAME GIT_MERGE_AUTOEDIT
GIT_EXEC_PATH GIT_ATTR_NOSYSTEM GIT_MERGE_VERBOSITY
GIT_TEMPLATE_DIR GIT_CONFIG_NOSYSTEM GIT_AUTHOR_EMAIL GIT_COMMITTER_NAME
GIT_COMMITTER_EMAIL
++ unset XDG_CONFIG_HOME
++ GIT_AUTHOR_EMAIL=aut...@example.com
++ GIT_AUTHOR_NAME='A U Thor'
++ GIT_COMMITTER_EMAIL=commit...@example.com
++ GIT_COMMITTER_NAME='C O Mitter'
++ GIT_MERGE_VERBOSITY=5
++ GIT_MERGE_AUTOEDIT=no
++ export GIT_MERGE_VERBOSITY GIT_MERGE_AUTOEDIT
++ export GIT_AUTHOR_EMAIL GIT_AUTHOR_NAME
++ export GIT_COMMITTER_EMAIL GIT_COMMITTER_NAME
++ export EDITOR
++ expr ' ' : '.* --valgrind '
++ test -n ''
++ unset CDPATH
++ unset GREP_OPTIONS
++ case $(echo $GIT_TRACE |tr "[A-Z]" "[a-z]") in
+++ echo
+++ tr '[A-Z]' '[a-z]'
++ _x05='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
++
_x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-
f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0
-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
++ _z40=
++ LF='
'
++ export _x05 _x40 _z40 LF
++ '[' xdumb '!=' xdumb ']'
++ test 2 -ne 0
++ case "$1" in
++ verbose=t
++ shift
++ test 1 -ne 0
++ case "$1" in
++ immediate=t
++ shift
++ test 0 -ne 0
++ test -n ''
++ test 'Test the very basics part #1.
The rest of the test suite does not check the basic operation of git
plumbing commands to work very carefully. Their job is to concentrate
on tricky features that caused bugs in the past to detect regression.
This test runs very basic features, like registering things in cache,
writing tree, etc.
Note that this test *deliberately* hard-codes many expected object
IDs. When object ID computation changes, like in the previous case of
swapping compression and hashing order, the person who is making the
modification *should* take notice and update the test vectors here.
' '!=' ''
++ test '' = t
++ exec
++ exec
+
RE: make test
> From: Johannes Sixt [mailto:j.s...@viscovery.net] > Sent: Monday, October 15, 2012 12:53 PM > To: Joachim Schmitz > Cc: git@vger.kernel.org > Subject: Re: make test > > Am 10/15/2012 12:36, schrieb Joachim Schmitz: > > not ok 4 - pretend we have a known breakage # TODO known breakage > > > >This is expected, right? > > Right. > > >the next is not though? Why might it be failing, where to check? > > > > not ok - 12 tests clean up even on failures > > # > > # mkdir failing-cleanup && > > #... > > # test_cmp expect out > > # ) > > # > > First thing: > > ./t-basic.sh -v -i OK, I should have mentioned that I did look with -v : not ok - 12 tests clean up even on failures # # mkdir failing-cleanup && # ( # cd failing-cleanup && # # cat >failing-cleanup.sh <<-EOF && # #!/bin/sh # # test_description='Failing tests with cleanup commands' # # # Point to the t/test-lib.sh, which isn't in ../ as usual # TEST_DIRECTORY="/home/jojo/git/git/t" # . "$TEST_DIRECTORY"/test-lib.sh # # test_expect_success 'tests clean up even after a failure' ' # touch clean-after-failure && # test_when_finished rm clean-after-failure && # (exit 1) # ' # test_expect_success 'failure to clean up causes the test to fail' ' # test_when_finished "(exit 2)" # ' # test_done # # EOF # # chmod +x failing-cleanup.sh && # test_must_fail ./failing-cleanup.sh >out 2>err && # ! test -s err && # ! test -f "trash directory.failing-cleanup/clean-after-failure" && # sed -e 's/Z$//' -e 's/^> //' >expect <<-\EOF && # > not ok - 1 tests clean up even after a failure # > # Z # > # touch clean-after-failure && # > # test_when_finished rm clean-after-failure && # > # (exit 1) # > # Z # > not ok - 2 failure to clean up causes the test to fail # > # Z # > # test_when_finished "(exit 2)" # > # Z # > # failed 2 among 2 test(s) # > 1..2 # EOF # test_cmp expect out # ) # > and if that does not give sufficient clues, > > $SHELL_PATH -x ./t-basic.sh -v -i not ok - 12 tests clean up even on failures # # mkdir failing-cleanup && # ( # cd failing-cleanup && # # cat >failing-cleanup.sh <<-EOF && # #!/bin/sh # # test_description='Failing tests with cleanup commands' # # # Point to the t/test-lib.sh, which isn't in ../ as usual # TEST_DIRECTORY="/home/jojo/git/git/t" # . "$TEST_DIRECTORY"/test-lib.sh # # test_expect_success 'tests clean up even after a failure' ' # touch clean-after-failure && # test_when_finished rm clean-after-failure && # (exit 1) # ' # test_expect_success 'failure to clean up causes the test to fail' ' # test_when_finished "(exit 2)" # ' # test_done # # EOF # # chmod +x failing-cleanup.sh && # test_must_fail ./failing-cleanup.sh >out 2>err && # ! test -s err && # ! test -f "trash directory.failing-cleanup/clean-after-failure" && # sed -e 's/Z$//' -e 's/^> //' >expect <<-\EOF && # > not ok - 1 tests clean up even after a failure # > # Z # > # touch clean-after-failure && # > # test_when_finished rm clean-after-failure && # > # (exit 1) # > # Z # > not ok - 2 failure to clean up causes the test to fail # > # Z # > # test_when_finished "(exit 2)" # > # Z # > #
t3302-notes-index-expensive.sh and t3419-rebase-patch-id.sh need time in /usr/bin
Hi folks t3302-notes-index-expensive.sh and t3419-rebase-patch-id.sh need "time " to be in "/usr/bin", however on my system it is in "/bin". Can't this be checked for? Bye, Jojo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
make test
Hi folks I'm trying to understand why certain tests in 'make test' fail. Here's the first one $ ../git --version git version 1.8.0.rc2.5.g6b89306 $ GIT_TEST_CMP_USE_COPIED_CONTEXT=true ./t-basic.sh # our diff doesn't understand -u ok 1 - .git/objects should be empty after git init in an empty repo ... ok 3 - success is reported like this not ok 4 - pretend we have a known breakage # TODO known breakage This is expected, right? ok 5 - pretend we have fixed a known breakage (run in sub test-lib) ... ok 11 - tests clean up after themselves the next is not though? Why might it be failing, where to check? not ok - 12 tests clean up even on failures # # mkdir failing-cleanup && # ( # cd failing-cleanup && # # cat >failing-cleanup.sh <<-EOF && # #!/bin/sh # # test_description='Failing tests with cleanup commands' # # # Point to the t/test-lib.sh, which isn't in ../ as usual # TEST_DIRECTORY="/home/jojo/git/git/t" # . "$TEST_DIRECTORY"/test-lib.sh # # test_expect_success 'tests clean up even after a failure' ' # touch clean-after-failure && # test_when_finished rm clean-after-failure && # (exit 1) # ' # test_expect_success 'failure to clean up causes the test to fail' ' # test_when_finished "(exit 2)" # ' # test_done # # EOF # # chmod +x failing-cleanup.sh && # test_must_fail ./failing-cleanup.sh >out 2>err && # ! test -s err && # ! test -f "trash directory.failing-cleanup/clean-after-failure" && # sed -e 's/Z$//' -e 's/^> //' >expect <<-\EOF && # > not ok - 1 tests clean up even after a failure # > # Z # > # touch clean-after-failure && # > # test_when_finished rm clean-after-failure && # > # (exit 1) # > # Z # > not ok - 2 failure to clean up causes the test to fail # > # Z # > # test_when_finished "(exit 2)" # > # Z # > # failed 2 among 2 test(s) # > 1..2 # EOF # test_cmp expect out # ) # ok 13 - git update-index without --add should fail adding ... ok 47 - very long name in the index handled sanely # still have 1 known breakage(s) # failed 1 among remaining 46 test(s) 1..47 Bye, Jojo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] t/t5400-send-pack: Use POSIX options to cp for portability
Junio C Hamano wrote: Junio C Hamano writes: Ben Walton writes: Avoid a GNU-ism in the cp options used by t5400-send-pack. Change -a to -pR. Signed-off-by: Ben Walton --- Thanks, but is "-p" essential for this test to pass, or can we get away with just "-R"? Besides, when you spot a potential problem, please ask "git grep" to catch them all. $ git grep "cp -a" t/ t/t5400-send-pack.sh: cp -a parent child && t/t5550-http-fetch.sh: cp -a .git"$HTTPD_DOCUMENT_ROOT_PATH/repo.git" && t/t5800-remote-helpers.sh: cp -a server server2 && There's 2 more places in Documentation/git-tutorial.txt. There it looks like we'd want to use 'cp -pR' instead Bye, Jojo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/10] Integrate wildmatch to git
Thiago Farina wrote:
On Fri, Oct 5, 2012 at 1:41 AM, Nguyễn Thái Ngọc Duy
wrote:
This makes wildmatch.c part of libgit.a and builds test-wildmatch;
the dependency on libpopt in the original has been replaced with the
use
of our parse-options. Global variables in test-wildmatch are marked
static to avoid sparse warnings.
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Ramsay Jones
Signed-off-by: Junio C Hamano
---
.gitignore | 1 +
Makefile | 3 ++
t/t3070-wildmatch.sh | 27
test-wildmatch.c | 88
++-- wildmatch.c
| 26 +--- 5 files changed, 75 insertions(+), 70
deletions(-) create mode 100755 t/t3070-wildmatch.sh
diff --git a/test-wildmatch.c b/test-wildmatch.c
index 88585c2..bb726c8 100644
--- a/test-wildmatch.c
+++ b/test-wildmatch.c
@@ -19,34 +19,38 @@
/*#define COMPARE_WITH_FNMATCH*/
-#define WILD_TEST_ITERATIONS
-#include "lib/wildmatch.c"
+#include "cache.h"
+#include "parse-options.h"
+#include "wildmatch.h"
-#include
+#ifndef MAXPATHLEN
+#define MAXPATHLEN 1024
+#endif
+#ifdef NO_STRLCPY
+#include "compat/strlcpy.c"
+#define strlcpy gitstrlcpy
+#endif
#ifdef COMPARE_WITH_FNMATCH
#include
-int fnmatch_errors = 0;
+static int fnmatch_errors = 0;
#endif
-int wildmatch_errors = 0;
-char number_separator = ',';
+static int wildmatch_errors = 0;
typedef char bool;
-int output_iterations = 0;
-int explode_mod = 0;
-int empties_mod = 0;
-int empty_at_start = 0;
-int empty_at_end = 0;
-
-static struct poptOption long_options[] = {
- /* longName, shortName, argInfo, argPtr, value, descrip, argDesc
*/
- {"iterations", 'i', POPT_ARG_NONE, &output_iterations, 0,
0, 0},
- {"empties",'e', POPT_ARG_STRING, 0, 'e', 0, 0},
- {"explode",'x', POPT_ARG_INT,&explode_mod, 0, 0, 0},
- {0,0,0,0, 0, 0, 0}
+static int explode_mod = 0;
Isn't static variables like this initialized to zero by default? There
is a high chance that I might be wrong though.
C99,
5.1.2.1: All objects with static storage duration shall be initialized (set
to their initial values) before program startup.
6.2.4.2: An object whose identifier is declared with external or internal
linkage, or with the storage-class specifier static has static storage
duration. Its lifetime is the entire execution of the program and its stored
value is initialized only once, prior to program startup.
6.7.8.10: If an object that has automatic storage duration is not
initialized explicitly, its value is indeterminate. If an object that has
static storage duration is not initialized explicitly, then:
— if it has pointer type, it is initialized to a null pointer;
— if it has arithmetic type, it is initialized to (positive or unsigned)
zero;
— if it is an aggregate, every member is initialized (recursively) according
to these rules;
— if it is a union, the first named member is initialized (recursively)
according to these rules.
So seems you're right ;-)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] more meaningful error message in gitk when git binary is not available
Josef Assad wrote:
Hi. I ran across what is a decidedly trivial little issue in gitk. The
TCL/Tk looked simple enough so I am giving you a patch anyhow in case
you want to fix it.
When for whatever reason the git binary is unavailable, gitk would
complain about missing git repository instead, so this patch adds a
check for git binary availability.
In case anyone is curious, I found this issue here:
http://stackoverflow.com/q/11967110/53936
Signed-off-by: Josef Assad
---
gitk-git/gitk |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index d93bd99..7e2e0a7 100755
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -11680,6 +11680,12 @@ setui $uicolor
setoptions
+# check that the git executables are available for use
+if [catch {set gitexists [exec which git]}] {
I believe 'which' is not portable, you could use 'type' instead.
+show_error {} . [mc "Cannot find a suitable git executable."]
+exit 1
+}
+
# check that we can find a .git directory somewhere...
if {[catch {set gitdir [exec git rev-parse --git-dir]}]} {
show_error {} . [mc "Cannot find a git repository here."]
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Test failure: Test #3 in t1304-default-acl
Ramkumar Ramachandra wrote: Hi Junio, Junio C Hamano wrote: Matthieu Moy writes: Junio C Hamano writes: I haven't been paying attention, but does that mean on that system, a total stranger kseygold can write, modify, and remove whatever Ram owns? I am hoping that is not the case. I can see two reasons for having the same UID for two login names: 1) the sysadmin really messed up, and as you say, a total stranger has complete ownership of your files. Ramkumar, you should check that this is not your case. 2) the sysadmin explicitely gave two login names to the same physical person, as kinds of aliases for the same UID (e.g. the person got married, changed her name and login, but expects ~oldlogin to continue working). I'm not sure how common this is, and to which extend we want to support this in our test scripts. I've only been assuming (1), but (2) feels like a legitimate (if confusing) way to configure your system. It is a separate issue if it is worth bending backwards to support it in the test, though. For what it's worth, `sudo` is "broken" on my system. sudo can't deal properly with multiple users sharing a UID, as it uses getpwuid(getuid()) in places. On my system I've replaced that with getgwnam(getlogin()). which seems to work fine here. Bye, Jojo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Can git pull from a mercurial repository?
> From: Max Horn [mailto:post...@quendi.de] > Sent: Tuesday, September 25, 2012 4:15 PM > To: Joachim Schmitz > Cc: 'Andreas Ericsson'; git@vger.kernel.org > Subject: Re: Can git pull from a mercurial repository? > > Hi there, > > > On 18.09.2012, at 14:40, Joachim Schmitz wrote: > > >> From: Andreas Ericsson [mailto:a...@op5.se] > >> Sent: Tuesday, September 18, 2012 1:46 PM > >> To: Joachim Schmitz > >> Cc: git@vger.kernel.org > >> Subject: Re: Can git pull from a mercurial repository? > >> > >> On 09/18/2012 01:22 PM, Joachim Schmitz wrote: > >>> Is there an easy way to get git to clone/pull from a Mercurial repository? > >>> > >> > >> Yes. Google "git remote helpers" and you'll most likely find it. > > > > Well, I found a few. No idea how to get them to work though (so far for the > > 'easy' part of my question) > > I think there is a lot of demand for a "git-hg" bridge, a way to seemlessly > access a Mercurial repository as if it was a git repository. A > converse to hg-git <http://hg-git.github.com/> > > As you discovered, there are several attempts to this. A recent overview over > some of them can be found here: > > https://github.com/dubiousjim/yagh/blob/master/README.md > > Another remark: > > > > > > It seems https://github.com/rfk/git-remote-hg requires Python 2.5 (and I > > only have 2.4), also I have no idea how to get it installed > > https://github.com/SRabbelier/git is 3 years old, apparently never made it > > into git, guess for a reason? > > Then I found https://github.com/fingolfin/git/commits/remote-hg, looks very > > confusing to me... > > This is mine, and I am sorry that it causes confusion -- but in fact, my goal > it is kind of a continuation of the > https://github.com/SRabbelier/git code. OR rather, it collects code others > wrote to improve that codebase, and I just added a few fixes > that made it work for me. > > In particular, I tried to figure out the reasons for why it never made it > into git, and in the process, created this Wiki page: > <https://github.com/msysgit/msysgit/wiki/Guide-to-git-remote-hg>. Which > attempts to document how to use this code, and what needs to > be done. My hope was that perhaps more people would be interested in this, > and in helping out with it, but so far no such luck. Ah, with that pages it gets much clearer! Only how should anyone know that https://github.com/fingolfin/git/commits/remote-hg is related in any form or shape with https://github.com/msysgit/msysgit/wiki/Guide-to-git-remote-hg? I'm afraid it still won't help me much though, as I guess it too requites Python 2.5 or later, as it uses the Mercuroal Python API (and that actually may be the reason why it never made it into git? I believe to have read somewhere that git tries to restrict itself to Python 2.4) > My goals were noble, but you are the second person who considers this work to > be confusing, so if that is what the majority thinks, I am > willing to remove that text again (or rather, hide it away in some private > repository). No, please don't. Rather make that clear on https://github.com/fingolfin/git/commits/remote-hg ... Bye, Jojo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can git pull from a mercurial repository?
Gelonida N wrote: On 09/18/2012 02:40 PM, Joachim Schmitz wrote: From: Andreas Ericsson [mailto:a...@op5.se] Sent: Tuesday, September 18, 2012 1:46 PM To: Joachim Schmitz Cc: git@vger.kernel.org Subject: Re: Can git pull from a mercurial repository? On 09/18/2012 01:22 PM, Joachim Schmitz wrote: Is there an easy way to get git to clone/pull from a Mercurial repository? Yes. Google "git remote helpers" and you'll most likely find it. Well, I found a few. No idea how to get them to work though (so far for the 'easy' part of my question) It seems https://github.com/rfk/git-remote-hg requires Python 2.5 (and I only have 2.4), also I have no idea how to get it installed https://github.com/SRabbelier/git is 3 years old, apparently never made it into git, guess for a reason? Then I found https://github.com/fingolfin/git/commits/remote-hg, looks very confusing to me... Install a newer python and hg Are you really sure, that python 2.5 doesn't exist for your machine? Yes, I am sure. Python 2.4 had been ported more than 5 years ago by a former workmate, otherwise we wouldn't even have that. Most non embedded devices should offer python 2.5 or newer (for some distros you just have to add 'alternative' repositories) For this platform (HP NonStop) basically nothing is available from any repository on the web but ITUGLIB (http://ituglib.connect-community.org) and that's the machine I'm working on/for ;-) We're currently trying to port Python-2.7, but it ain't easy... Bye, Jojo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] Port to HP NonStop
> From: Jan Engelhardt [mailto:jeng...@inai.de] > Sent: Wednesday, September 19, 2012 10:34 PM > To: Joachim Schmitz > Cc: 'Junio C Hamano'; git@vger.kernel.org > Subject: RE: [PATCH] Port to HP NonStop > > On Wednesday 2012-09-19 19:54, Joachim Schmitz wrote: > > >> From: Jan Engelhardt [mailto:jeng...@inai.de] > >> Sent: Wednesday, September 19, 2012 7:48 PM > >> To: Joachim Schmitz > >> Cc: 'Junio C Hamano'; git@vger.kernel.org > >> Subject: Re: [PATCH] Port to HP NonStop > >> > >> > >> On Wednesday 2012-09-19 12:03, Joachim Schmitz wrote: > >> >+#ifdef NO_INTPTR_T > >> >+/* > >> >+ * On I16LP32, ILP32 and LP64 "long" is the save bet, however > >> >+ * on LLP86, IL33LLP64 and P64 it needs to be "long long", > >> >+ * while on IP16 and IP16L32 it is "int" (resp. "short") > >> >+ * Size needs to match (or exceed) 'sizeof(void *)'. > >> >+ * We can't take "long long" here as not everybody has it. > >> > >> Are you trying to port git to DOS or why would you mention IP16? :-) > > > >Just for completness, nothing else ;-) > > The problem would be that some, if not most, C environments in DOS offer > a P16P32 model - thanks to (near void *) and (far void *). No problem. "long" would be big enough for these (wasting some space though) Only LLP86, IL33LLP64 and P64 would need it bigger, "long long". -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] Port to HP NonStop
> From: Jan Engelhardt [mailto:jeng...@inai.de] > Sent: Wednesday, September 19, 2012 7:48 PM > To: Joachim Schmitz > Cc: 'Junio C Hamano'; git@vger.kernel.org > Subject: Re: [PATCH] Port to HP NonStop > > > On Wednesday 2012-09-19 12:03, Joachim Schmitz wrote: > >+#ifdef NO_INTPTR_T > >+/* > >+ * On I16LP32, ILP32 and LP64 "long" is the save bet, however > >+ * on LLP86, IL33LLP64 and P64 it needs to be "long long", > >+ * while on IP16 and IP16L32 it is "int" (resp. "short") > >+ * Size needs to match (or exceed) 'sizeof(void *)'. > >+ * We can't take "long long" here as not everybody has it. > > Are you trying to port git to DOS or why would you mention IP16? :-) Just for completness, nothing else ;-) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Port to HP NonStop
Includes the addition of some new defines and their description for others to
use.
Signed-off-by: Joachim Schmitz
---
This needs my 4 compat-poll patches posted earlier, which are in pu currently
Makefile | 67 +++
git-compat-util.h | 17 +-
2 files changed, 83 insertions(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index e022fc4..3823968 100644
--- a/Makefile
+++ b/Makefile
@@ -145,6 +145,12 @@ all::
#
# Define NEEDS_LIBICONV if linking with libc is not enough (Darwin).
#
+# Define NEEDS_LIBINTL_BEFORE_LIBICONV if you need libintl before libiconv.
+#
+# Define NO_INTPTR_T if you don't have intptr_t nor uintptr_t.
+#
+# Define NO_UINTMAX_T if you don't have uintmax_t.
+#
# Define NEEDS_SOCKET if linking with libc is not enough (SunOS,
# Patrick Mauritz).
#
@@ -1327,6 +1333,61 @@ ifeq ($(uname_S),Minix)
NO_CURL =
NO_EXPAT =
endif
+ifeq ($(uname_S),NONSTOP_KERNEL)
+ # Needs some C99 features, "inline" is just one of them.
+ # INLINE='' would just replace one set of warnings with another and
+ # still not compile in c89 mode, due to non-const array initializations.
+ CC = cc -c99
+ # Disable all optimization, seems to result in bad code, with -O or -O2
+ # or even -O1 (default), /usr/local/libexec/git-core/git-pack-objects
+ # abends on "git push". Needs more investigation.
+ CFLAGS = -g -O0
+ # We'd want it to be here.
+ prefix = /usr/local
+ # Our's are in ${prefix}/bin (perl might also be in /usr/bin/perl).
+ PERL_PATH = ${prefix}/bin/perl
+ PYTHON_PATH = ${prefix}/bin/python
+
+ # As detected by './configure'.
+ # Missdetected, hence commented out, see below.
+ #NO_CURL = YesPlease
+ # Added manually, see above.
+ NEEDS_SSL_WITH_CURL = YesPlease
+ HAVE_LIBCHARSET_H = YesPlease
+ NEEDS_LIBICONV = YesPlease
+ NEEDS_LIBINTL_BEFORE_LIBICONV = YesPlease
+ NO_SYS_SELECT_H = UnfortunatelyYes
+ NO_D_TYPE_IN_DIRENT = YesPlease
+ NO_HSTRERROR = YesPlease
+ NO_STRCASESTR = YesPlease
+ NO_FNMATCH_CASEFOLD = YesPlease
+ NO_MEMMEM = YesPlease
+ NO_STRLCPY = YesPlease
+ NO_SETENV = YesPlease
+ NO_UNSETENV = YesPlease
+ NO_MKDTEMP = YesPlease
+ NO_MKSTEMPS = YesPlease
+ # Currently libiconv-1.9.1.
+ OLD_ICONV = UnfortunatelyYes
+ NO_REGEX = YesPlease
+ NO_PTHREADS = UnfortunatelyYes
+
+ # Not detected (nor checked for) by './configure'.
+ # We don't have SA_RESTART on NonStop, unfortunalety.
+ COMPAT_CFLAGS += -DSA_RESTART=0
+ # Apparently needed in compat/fnmatch/fnmatch.c.
+ COMPAT_CFLAGS += -DHAVE_STRING_H=1
+ NO_ST_BLOCKS_IN_STRUCT_STAT = YesPlease
+ NO_NSEC = YesPlease
+ NO_PREAD = YesPlease
+ NO_MMAP = YesPlease
+ NO_POLL = YesPlease
+ NO_INTPTR_T = UnfortunatelyYes
+ # Bug report 10-120822-4477 submitted to HP NonStop development.
+ MKDIR_WO_TRAILING_SLASH = YesPlease
+ # RFE 10-120912-4693 submitted to HP NonStop development.
+ NO_SETITIMER = UnfortunatelyYes
+endif
ifneq (,$(findstring MINGW,$(uname_S)))
pathsep = ;
NO_PREAD = YesPlease
@@ -1563,6 +1624,9 @@ ifdef NEEDS_LIBICONV
else
ICONV_LINK =
endif
+ ifdef NEEDS_LIBINTL_BEFORE_LIBICONV
+ ICONV_LINK += -lintl
+ endif
EXTLIBS += $(ICONV_LINK) -liconv
endif
ifdef NEEDS_LIBGEN
@@ -1723,6 +1787,9 @@ endif
ifdef NO_IPV6
BASIC_CFLAGS += -DNO_IPV6
endif
+ifdef NO_INTPTR_T
+ COMPAT_CFLAGS += -DNO_INTPTR_T
+endif
ifdef NO_UINTMAX_T
BASIC_CFLAGS += -Duintmax_t=uint32_t
endif
diff --git a/git-compat-util.h b/git-compat-util.h
index 24b5432..2fbf1fd 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -74,7 +74,8 @@
# define _XOPEN_SOURCE 500
# endif
#elif !defined(__APPLE__) && !defined(__FreeBSD__) && !defined(__USLC__) && \
- !defined(_M_UNIX) && !defined(__sgi) && !defined(__DragonFly__)
+ !defined(_M_UNIX) && !defined(__sgi) && !defined(__DragonFly__) && \
+ !defined(__TANDEM)
#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
@@ -98,6 +99,9 @@
#include
#include
#include
+#ifdef __TANDEM /* or HAVE_STRINGS_H or !NO_STRINGS_H? */
+#include /* for strcasecmp() */
+#endif
#include
#include
#include
@@ -141,6 +145,17 @@
#else
#include
#endif
+#ifdef NO_INTPTR_T
+/*
+ * On I16LP32, ILP32 and LP64 "long" is the save bet, however
+ * on LLP86, IL33LLP64 and P64 it needs to be "long long",
+ * while on IP16 and IP16L32 it is "int" (resp. "
RE: [RFC] Support for HP NonStop
> From: Jan Engelhardt [mailto:jeng...@inai.de] > Sent: Wednesday, September 19, 2012 9:24 AM > To: Joachim Schmitz > Cc: 'Junio C Hamano'; git@vger.kernel.org > Subject: RE: [RFC] Support for HP NonStop > > > On Friday 2012-08-24 22:43, Joachim Schmitz wrote: > > > >> By the way, is "int" wide enough [for intptr_t/uintptr_t], > >> or should they be "long"? > > > >int and long have the same size, 32-bit, here on NonStop. > >But we do have 64-bit types too. Not sure which to take though. > > intptr_t is supposed to hold a void * pointer, so should be > at least as big. OK, thanks. We are on IA64 but still use the ILP32 model (so 32bit pointers. Support for LP64 has been added recently, but isn't the default. However, long changes from 32bit to 64 bit when changing from ILP32 to LP64, so is the save bet here, right? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH/RFC] Port to HP NonStop
> From: Junio C Hamano [mailto:gits...@pobox.com] > Sent: Tuesday, September 18, 2012 7:03 PM > To: Joachim Schmitz > Cc: git@vger.kernel.org > Subject: Re: [PATCH/RFC] Port to HP NonStop > > "Joachim Schmitz" writes: > > >> From: Junio C Hamano [mailto:gits...@pobox.com] > >> Sent: Tuesday, September 18, 2012 9:57 AM > >> To: Joachim Schmitz > >> Cc: git@vger.kernel.org > >> Subject: Re: [PATCH/RFC] Port to HP NonStop > >> > >> "Joachim Schmitz" writes: > >> > >> > Needs a different link order in Makefile: libintl before libiconv. > >> > This may affect other platforms, so needs some checking. > >> > >> It will, and it needs customization, not checking. > > > > How? > > By not moving things around to affect other people, but having them > in the order you want only for your platform (and other future ports > that need similar treatment)? > > For example, if you need libintl before libiconv, a quick and dirty > way may be > > diff --git i/Makefile w/Makefile > index a49d1db..9b2cfd6 100644 > --- i/Makefile > +++ w/Makefile > @@ -1552,6 +1552,9 @@ ifdef NEEDS_LIBICONV > else > ICONV_LINK = > endif > + ifdef NEEDS_LIBINTL_BEFORE_LIBICONV > + ICONV_LINK += -lintl > + endif > EXTLIBS += $(ICONV_LINK) -liconv > endif > ifdef NEEDS_LIBGEN > > and your linker command line may have "-lintl -liconv -lintl" but > that wouldn't be an error, and you know you won't be affecting > other platforms that do not use NEEDS_LIBINTL_BEFORE_LIBICONV, no? OK, sounds good, I'll try that and submit an updated patch if it works that way (and I'm pretty sure it does). Anything else I should change in my patch? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Can git pull from a mercurial repository?
> From: Andreas Ericsson [mailto:a...@op5.se] > Sent: Tuesday, September 18, 2012 1:46 PM > To: Joachim Schmitz > Cc: git@vger.kernel.org > Subject: Re: Can git pull from a mercurial repository? > > On 09/18/2012 01:22 PM, Joachim Schmitz wrote: > > Is there an easy way to get git to clone/pull from a Mercurial repository? > > > > Yes. Google "git remote helpers" and you'll most likely find it. Well, I found a few. No idea how to get them to work though (so far for the 'easy' part of my question) It seems https://github.com/rfk/git-remote-hg requires Python 2.5 (and I only have 2.4), also I have no idea how to get it installed https://github.com/SRabbelier/git is 3 years old, apparently never made it into git, guess for a reason? Then I found https://github.com/fingolfin/git/commits/remote-hg, looks very confusing to me... -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Can git pull from a mercurial repository?
> From: Andreas Schwab [mailto:sch...@linux-m68k.org] > Sent: Tuesday, September 18, 2012 2:34 PM > To: Joachim Schmitz > Cc: 'Georgi Chorbadzhiyski'; git@vger.kernel.org > Subject: Re: Can git pull from a mercurial repository? > > "Joachim Schmitz" writes: > > > Thanks, but that requires Mercurial to be available, installed and in PATH. > > I want to use git exactly because I don't have Mercurial (yet?) > > That doesn't make sense. If one wants to access a mercurial repository > the best way to do that is to use the facilities provided by mercurial. Not if you don't have Mercurial to begin with. Git can access cvs and svn repos, right? And without having cvs/scv on the machine... -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Can git pull from a mercurial repository?
> From: Georgi Chorbadzhiyski [mailto:g...@unixsol.org] > Sent: Tuesday, September 18, 2012 2:06 PM > To: Joachim Schmitz > Cc: git@vger.kernel.org > Subject: Re: Can git pull from a mercurial repository? > > Around 09/18/2012 02:22 PM, Joachim Schmitz scribbled: > > Is there an easy way to get git to clone/pull from a Mercurial repository? > > I'm using http://offbytwo.com/git-hg/ > It works beautifully. Thanks, but that requires Mercurial to be available, installed and in PATH. I want to use git exactly because I don't have Mercurial (yet?) Bye, Jojo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Can git pull from a mercurial repository?
Is there an easy way to get git to clone/pull from a Mercurial repository? Bye, Jojo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH/RFC] Port to HP NonStop
> From: Junio C Hamano [mailto:gits...@pobox.com] > Sent: Tuesday, September 18, 2012 9:57 AM > To: Joachim Schmitz > Cc: git@vger.kernel.org > Subject: Re: [PATCH/RFC] Port to HP NonStop > > "Joachim Schmitz" writes: > > > Needs a different link order in Makefile: libintl before libiconv. > > This may affect other platforms, so needs some checking. > > It will, and it needs customization, not checking. How? > > Also I'm not really sure how to best #ifdef the #include > > and the typedef (u)intptr_t. > > For now, nobody needs these, so enclosing in TANDEM is fine. When > another platform is found to need the same change, which might be > unlikely, new symbols that NONSTOP_KERNEL and that other platform > share can be introduced to replace these #ifdefs. OK, I'm fine with that. So the git-compat-util.h part of my patch can go in as posted, right? With or without the comments? Bye, Jojo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v7 1/4] make poll available for other platforms lacking it
> From: Junio C Hamano [mailto:gits...@pobox.com] > Sent: Tuesday, September 18, 2012 8:55 AM > To: Joachim Schmitz > Cc: git@vger.kernel.org > Subject: Re: [PATCH v7 1/4] make poll available for other platforms lacking it > > "Joachim Schmitz" writes: > > >> > @@ -1605,6 +1610,11 @@ ifdef NO_GETTEXT > >> > BASIC_CFLAGS += -DNO_GETTEXT > >> > USE_GETTEXT_SCHEME ?= fallthrough > >> > endif > >> > +ifdef NO_POLL > >> > +NO_SYS_POLL_H = YesPlease > >> > +COMPAT_CFLAGS += -DNO_POLL -Icompat/poll > >> > +COMPAT_OBJS += compat/poll/poll.o > >> > +endif > >> > >> I think my guesses above are correct, so will queue with the trivial > >> and obvious fixup. > > > > Well I was unde the impression that is isn't > > available, there might be a and it that isn't available > > either we use compat/.../poll.[ch]. But rethinking your changed > > does makes perfect sense. > > Heh, my comment was not about names between NO_POLL_H vs NO_POLL. > With the way you wrote the code, the symbols defined for Windows and > MINGW must match what controls the hunk around ll.1610, so what > makes perfect sense to you is indeed your code ;-) Yeah, I do understand myself pretty good ;-) Now I see my typo... -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH/RFC] Port to HP NonStop
Signed-off-by: Joachim Schmitz
---
This needs the 4 compat-poll patches posted earlier.
Needs a different link order in Makefile: libintl before libiconv.
This may affect other platforms, so needs some checking.
Also I'm not really sure how to best #ifdef the #include
and the typedef (u)intptr_t.
Furthermore the -DHAVE_STRING_H=1, needed for
compat/fnmatch/fnmatch.c doesn't look quite right to me?
Makefile | 54 +-
git-compat-util.h | 10 +-
2 files changed, 58 insertions(+), 6 deletions(-)
diff --git a/Makefile b/Makefile
index 3d40860..b1d4ef5 100644
--- a/Makefile
+++ b/Makefile
@@ -1324,6 +1324,52 @@ ifeq ($(uname_S),Minix)
NO_CURL =
NO_EXPAT =
endif
+ifeq ($(uname_S),NONSTOP_KERNEL)
+ CC = cc -c99 # needs some C99 features, "inline" is just one of them
+ # INLINE='' would just replace one set of warnings with another and
+ # still not compile in c89 mode, for non-const array initializations
+ CFLAGS = -g -O0 # disable all optimization, seems to result in bad code,
+ # with -O1 or -O0 /usr/local/libexec/git-core/git-pack-objects
+ # abends on "git push"
+ prefix = /usr/local
+ # our's are in ${prefix}/bin
+ PERL_PATH = ${prefix}/bin/perl
+ PYTHON_PATH = ${prefix}/bin/python
+
+ # as detected by './configure'
+ #NO_CURL = YesPlease # missdetected, disabled, see below
+ NEEDS_SSL_WITH_CURL = YesPlease # added manually, see above
+ HAVE_LIBCHARSET_H=YesPlease
+ NEEDS_LIBICONV = YesPlease # needs libiconv first, changed further down
+ NO_SYS_SELECT_H=UnfortunatelyYes
+ NO_D_TYPE_IN_DIRENT = YesPlease
+ NO_HSTRERROR=YesPlease
+ NO_STRCASESTR=YesPlease
+ NO_FNMATCH_CASEFOLD = YesPlease
+ NO_MEMMEM = YesPlease
+ NO_STRLCPY = YesPlease
+ NO_SETENV = YesPlease
+ NO_UNSETENV = YesPlease
+ NO_MKDTEMP = YesPlease
+ NO_MKSTEMPS = YesPlease
+ OLD_ICONV=UnfortunatelyYes # currently libiconv-1.9.1
+ NO_REGEX=YesPlease # Why? ToDo?
+ NO_PTHREADS=UnfortunatelyYes # ToDo? Using PUT, maybe?
+ #CFLAGS += -put # not suffient? Seems the wrong fnmatch.h gets included?
+ #CFLAGS += -DFNM_CASEFOLD=16 # (1 << 4), to get dir.c compiled!?!
+ #CFLAGS += -Icompat/fnmatch # this doesn't help
+
+ # not detected (nor checked for) by './configure'
+ COMPAT_CFLAGS += -DSA_RESTART=0 # we don't have SA_RESTART on NonStop
+ COMPAT_CFLAGS += -DHAVE_STRING_H=1 # needed in compat/fnmatch/fnmatch.c
+ NO_ST_BLOCKS_IN_STRUCT_STAT = YesPlease
+ NO_NSEC = YesPlease
+ NO_PREAD = YesPlease
+ NO_MMAP = YesPlease
+ NO_POLL = YesPlease
+ MKDIR_WO_TRAILING_SLASH = YesPlease
+ NO_SETITIMER = UnfortunatelyYes
+endif
ifneq (,$(findstring MINGW,$(uname_S)))
pathsep = ;
NO_PREAD = YesPlease
@@ -1555,6 +1599,11 @@ else
LIB_4_CRYPTO = $(OPENSSL_LINK) -lcrypto
endif
endif
+ifndef NO_GETTEXT
+ifndef LIBC_CONTAINS_LIBINTL
+ EXTLIBS += -lintl
+endif
+endif
ifdef NEEDS_LIBICONV
ifdef ICONVDIR
BASIC_CFLAGS += -I$(ICONVDIR)/include
@@ -1567,11 +1616,6 @@ endif
ifdef NEEDS_LIBGEN
EXTLIBS += -lgen
endif
-ifndef NO_GETTEXT
-ifndef LIBC_CONTAINS_LIBINTL
- EXTLIBS += -lintl
-endif
-endif
ifdef NEEDS_SOCKET
EXTLIBS += -lsocket
endif
diff --git a/git-compat-util.h b/git-compat-util.h
index 24b5432..7e70361 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -74,7 +74,8 @@
# define _XOPEN_SOURCE 500
# endif
#elif !defined(__APPLE__) && !defined(__FreeBSD__) && !defined(__USLC__) && \
- !defined(_M_UNIX) && !defined(__sgi) && !defined(__DragonFly__)
+ !defined(_M_UNIX) && !defined(__sgi) && !defined(__DragonFly__) && \
+ !defined(__TANDEM)
#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
@@ -98,6 +99,9 @@
#include
#include
#include
+#ifdef __TANDEM /* or HAVE_STRINGS_H or !NO_STRINGS_H? */
+#include /* for strcasecmp() */
+#endif
#include
#include
#include
@@ -141,6 +145,10 @@
#else
#include
#endif
+#ifdef __TANDEM /* or NO_INTPTR_T resp. NO_UINTPTR_T? */
+typedef int intptr_t;
+typedef unsigned int uintptr_t;
+#endif
#if defined(__CYGWIN__)
#undef _XOPEN_SOURCE
#include
--
1.7.12
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v7 1/4] make poll available for other platforms lacking it
> From: Junio C Hamano [mailto:gits...@pobox.com]
> Sent: Tuesday, September 18, 2012 12:42 AM
> To: Joachim Schmitz
> Cc: git@vger.kernel.org
> Subject: Re: [PATCH v7 1/4] make poll available for other platforms lacking it
>
> "Joachim Schmitz" writes:
>
> > move poll.[ch] out of compat/win32/ into compat/poll/ and adjust
> > Makefile with the changed paths. Adding comments to Makefile about
> > how/when to enable it and add logic for this
> >
> > Signed-off-by: Joachim Schmitz
> > ---
> > Makefile | 20 +++-
> > compat/{win32 => poll}/poll.c | 0
> > compat/{win32 => poll}/poll.h | 0
> > 3 files changed, 15 insertions(+), 5 deletions(-)
> > rename compat/{win32 => poll}/poll.c (100%)
> > rename compat/{win32 => poll}/poll.h (100%)
> >
> > diff --git a/Makefile b/Makefile
> > index ac49320..7893297 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -152,6 +152,11 @@ all::
> > #
> > # Define NO_MMAP if you want to avoid mmap.
> > #
> > +# Define NO_SYS_POLL_H if you don't have sys/poll.h.
> > +#
> > +# Define NO_POLL if you do not have or don't want to use poll().
> > +# This also implies NO_SYS_POLL_H.
>
> Sensible.
>
> > @@ -1220,7 +1225,7 @@ ifeq ($(uname_S),Windows)
> > NO_PREAD = YesPlease
> > NEEDS_CRYPTO_WITH_SSL = YesPlease
> > NO_LIBGEN_H = YesPlease
> > - NO_SYS_POLL_H = YesPlease
> > + NO_POLL_H = YesPlease
>
> Should this be NO_POLL, not NO_POLL_H?
>
> > -DSTRIP_EXTENSION=\".exe\"
> > BASIC_LDFLAGS = -IGNORE:4217 -IGNORE:4049 -NOLOGO -SUBSYSTEM:CONSOLE
> > -NODEFAULTLIB:MSVCRT.lib
> > EXTLIBS = user32.lib advapi32.lib shell32.lib wininet.lib ws2_32.lib
> > @@ -1316,7 +1321,7 @@ ifneq (,$(findstring MINGW,$(uname_S)))
> > NO_PREAD = YesPlease
> > NEEDS_CRYPTO_WITH_SSL = YesPlease
> > NO_LIBGEN_H = YesPlease
> > - NO_SYS_POLL_H = YesPlease
> > + NO_POLL_H = YesPlease
>
> Likewise.
>
> > @@ -1605,6 +1610,11 @@ ifdef NO_GETTEXT
> > BASIC_CFLAGS += -DNO_GETTEXT
> > USE_GETTEXT_SCHEME ?= fallthrough
> > endif
> > +ifdef NO_POLL
> > + NO_SYS_POLL_H = YesPlease
> > + COMPAT_CFLAGS += -DNO_POLL -Icompat/poll
> > + COMPAT_OBJS += compat/poll/poll.o
> > +endif
>
> I think my guesses above are correct, so will queue with the trivial
> and obvious fixup.
Well I was unde the impression that is isn't available, there
might be a and it that isn't available either we
use compat/.../poll.[ch]. But rethinking your changed does makes perfect sense.
OK, so I guess I'm ready for the 'final touch', my NonStop specific changes,
will post them shortly...
Bye, Jojo
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v7 0/4] Support non-WIN32 systems lacking poll()
> From: Junio C Hamano [mailto:gits...@pobox.com] > Sent: Tuesday, September 18, 2012 12:39 AM > To: Joachim Schmitz > Cc: git@vger.kernel.org > Subject: Re: [PATCH v7 0/4] Support non-WIN32 systems lacking poll() > > "Joachim Schmitz" writes: > > > Posted but not properly chained... hope that doesn't matter? > > Something small like this it doesn't. I am not into bureaucracy ;-) Phew ;-) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 0/4] Support non-WIN32 systems lacking poll()
Joachim Schmitz wrote: Here's now my updated series of patches to make the win32 implementation of poll() available to other platforms: 1 - make poll available for other platforms lacking it by moving it into a separate directory and adjusting Makefile 2 - fix some win32 specific dependencies in poll.c by #ifdef the inclusion of two header files 3 - poll() exits too early with EFAULT if 1st arg is NULL, as fixed in gnulib recently 4 - make poll() work on platforms that can't recv() on a non-socket, namely HP NonStop, as fixed in gnulib recently Hopefully without whitespace issues... Bye, Jojo Posted but not properly chained... hope that doesn't matter? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 4/4] make poll() work on platforms that can't recv() on a non-socket
This way it just got added to gnulib too the other day. Signed-off-by: Joachim Schmitz --- compat/poll/poll.c | 5 + 1 file changed, 5 insertions(+) diff --git a/compat/poll/poll.c b/compat/poll/poll.c index e4b8319..10a204e 100644 --- a/compat/poll/poll.c +++ b/compat/poll/poll.c @@ -306,6 +306,10 @@ compute_revents (int fd, int sought, fd_set *rfds, fd_set *wfds, fd_set *efds) || socket_errno == ECONNABORTED || socket_errno == ENETRESET) happened |= POLLHUP; + /* some systems can't use recv() on non-socket, including HP NonStop */ + else if (/* (r == -1) && */ socket_errno == ENOTSOCK) + happened |= (POLLIN | POLLRDNORM) & sought; + else happened |= POLLERR; } -- 1.7.12 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 3/4] poll() exits too early with EFAULT if 1st arg is NULL
If poll() is used as a milli-second sleep, like in help.c, by passing a NULL
in the 1st and a 0 in the 2nd arg, it exits with EFAULT.
As per Paolo Bonzini, the original author, this is a bug and to be fixed
Like in this commit, which is not to exit if the 2nd arg is 0. It got fixed
In gnulib in the same manner the other day.
Signed-off-by: Joachim Schmitz
---
compat/poll/poll.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/compat/poll/poll.c b/compat/win32/poll.c
index 403eaa7..9e7a25c 100644
--- a/compat/poll/poll.c
+++ b/compat/poll/poll.c
@@ -357,7 +357,7 @@ poll (struct pollfd *pfd, nfds_t nfd, int timeout)
/* EFAULT is not necessary to implement, but let's do it in the
simplest case. */
- if (!pfd)
+ if (!pfd && nfd)
{
errno = EFAULT;
return -1;
--
1.7.12
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 2/4] fix some win32 specific dependencies in poll.c
In order for non-win32 platforms to be able to use poll.c, #ifdef the inclusion of two header files properly Signed-off-by: Joachim Schmitz --- compat/poll/poll.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/compat/poll/poll.c b/compat/poll/poll.c index 9e7a25c..e4b8319 100644 --- a/compat/poll/poll.c +++ b/compat/poll/poll.c @@ -24,7 +24,9 @@ # pragma GCC diagnostic ignored "-Wtype-limits" #endif -#include +#if defined(WIN32) +# include +#endif #include @@ -48,7 +50,9 @@ #else # include # include -# include +# ifndef NO_SYS_SELECT_H +# include +# endif # include #endif -- 1.7.12 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 1/4] make poll available for other platforms lacking it
move poll.[ch] out of compat/win32/ into compat/poll/ and adjust
Makefile with the changed paths. Adding comments to Makefile about
how/when to enable it and add logic for this
Signed-off-by: Joachim Schmitz
---
Makefile | 20 +++-
compat/{win32 => poll}/poll.c | 0
compat/{win32 => poll}/poll.h | 0
3 files changed, 15 insertions(+), 5 deletions(-)
rename compat/{win32 => poll}/poll.c (100%)
rename compat/{win32 => poll}/poll.h (100%)
diff --git a/Makefile b/Makefile
index ac49320..7893297 100644
--- a/Makefile
+++ b/Makefile
@@ -152,6 +152,11 @@ all::
#
# Define NO_MMAP if you want to avoid mmap.
#
+# Define NO_SYS_POLL_H if you don't have sys/poll.h.
+#
+# Define NO_POLL if you do not have or don't want to use poll().
+# This also implies NO_SYS_POLL_H.
+#
# Define NO_PTHREADS if you do not have or do not want to use Pthreads.
#
# Define NO_PREAD if you have a problem with pread() system call (e.g.
@@ -598,10 +603,10 @@ LIB_H += compat/bswap.h
LIB_H += compat/cygwin.h
LIB_H += compat/mingw.h
LIB_H += compat/obstack.h
+LIB_H += compat/poll/poll.h
LIB_H += compat/precompose_utf8.h
LIB_H += compat/terminal.h
LIB_H += compat/win32/dirent.h
-LIB_H += compat/win32/poll.h
LIB_H += compat/win32/pthread.h
LIB_H += compat/win32/syslog.h
LIB_H += connected.h
@@ -1220,7 +1225,7 @@ ifeq ($(uname_S),Windows)
NO_PREAD = YesPlease
NEEDS_CRYPTO_WITH_SSL = YesPlease
NO_LIBGEN_H = YesPlease
- NO_SYS_POLL_H = YesPlease
+ NO_POLL_H = YesPlease
NO_SYMLINK_HEAD = YesPlease
NO_IPV6 = YesPlease
NO_UNIX_SOCKETS = YesPlease
@@ -1261,7 +1266,7 @@ ifeq ($(uname_S),Windows)
BASIC_CFLAGS = -nologo -I. -I../zlib -Icompat/vcbuild
-Icompat/vcbuild/include -DWIN32 -D_CONSOLE -DHAVE_STRING_H
-D_CRT_SECURE_NO_WARNINGS -D_CRT_NONSTDC_NO_DEPRECATE
COMPAT_OBJS = compat/msvc.o compat/winansi.o \
compat/win32/pthread.o compat/win32/syslog.o \
- compat/win32/poll.o compat/win32/dirent.o
+ compat/win32/dirent.o
COMPAT_CFLAGS = -D__USE_MINGW_ACCESS -DNOGDI -DHAVE_STRING_H
-DHAVE_ALLOCA_H -Icompat -Icompat/regex -Icompat/win32
-DSTRIP_EXTENSION=\".exe\"
BASIC_LDFLAGS = -IGNORE:4217 -IGNORE:4049 -NOLOGO -SUBSYSTEM:CONSOLE
-NODEFAULTLIB:MSVCRT.lib
EXTLIBS = user32.lib advapi32.lib shell32.lib wininet.lib ws2_32.lib
@@ -1316,7 +1321,7 @@ ifneq (,$(findstring MINGW,$(uname_S)))
NO_PREAD = YesPlease
NEEDS_CRYPTO_WITH_SSL = YesPlease
NO_LIBGEN_H = YesPlease
- NO_SYS_POLL_H = YesPlease
+ NO_POLL_H = YesPlease
NO_SYMLINK_HEAD = YesPlease
NO_UNIX_SOCKETS = YesPlease
NO_SETENV = YesPlease
@@ -1351,7 +1356,7 @@ ifneq (,$(findstring MINGW,$(uname_S)))
COMPAT_CFLAGS += -DSTRIP_EXTENSION=\".exe\"
COMPAT_OBJS += compat/mingw.o compat/winansi.o \
compat/win32/pthread.o compat/win32/syslog.o \
- compat/win32/poll.o compat/win32/dirent.o
+ compat/win32/dirent.o
EXTLIBS += -lws2_32
PTHREAD_LIBS =
X = .exe
@@ -1605,6 +1610,11 @@ ifdef NO_GETTEXT
BASIC_CFLAGS += -DNO_GETTEXT
USE_GETTEXT_SCHEME ?= fallthrough
endif
+ifdef NO_POLL
+ NO_SYS_POLL_H = YesPlease
+ COMPAT_CFLAGS += -DNO_POLL -Icompat/poll
+ COMPAT_OBJS += compat/poll/poll.o
+endif
ifdef NO_STRCASESTR
COMPAT_CFLAGS += -DNO_STRCASESTR
COMPAT_OBJS += compat/strcasestr.o
diff --git a/compat/win32/poll.c b/compat/poll/poll.c
similarity index 100%
rename from compat/win32/poll.c
rename to compat/poll/poll.c
diff --git a/compat/win32/poll.h b/compat/poll/poll.h
similarity index 100%
rename from compat/win32/poll.h
rename to compat/poll/poll.h
--
1.7.12
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 0/4] Support non-WIN32 systems lacking poll()
Here's now my updated series of patches to make the win32 implementation of poll() available to other platforms: 1 - make poll available for other platforms lacking it by moving it into a separate directory and adjusting Makefile 2 - fix some win32 specific dependencies in poll.c by #ifdef the inclusion of two header files 3 - poll() exits too early with EFAULT if 1st arg is NULL, as fixed in gnulib recently 4 - make poll() work on platforms that can't recv() on a non-socket, namely HP NonStop, as fixed in gnulib recently Hopefully without whitespace issues... Bye, Jojo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Test failure: Test #3 in t1304-default-acl
Matthieu Moy wrote: Junio C Hamano writes: I haven't been paying attention, but does that mean on that system, a total stranger kseygold can write, modify, and remove whatever Ram owns? I am hoping that is not the case. I can see two reasons for having the same UID for two login names: 1) the sysadmin really messed up, and as you say, a total stranger has complete ownership of your files. Ramkumar, you should check that this is not your case. 2) the sysadmin explicitely gave two login names to the same physical person, as kinds of aliases for the same UID (e.g. the person got married, changed her name and login, but expects ~oldlogin to continue working). I'm not sure how common this is, and to which extend we want to support this in our test scripts. On HP NonStop it is very common to have a user (form: "GROUP.USER", case insensitiv) and one or more aliases to them (form: "user", case sensitiv) the latter are very commonly used in the POSIX part of HP NonStop (call OSS), the one git runs in, the other are more commonly used in the proprietary part of the OS (called Guardian), althoug this is not a strict requirement. The only thing they share is the UID. Bye, Jojo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: What's cooking in git.git (Sep 2012, #05; Fri, 14)
> From: Joachim Schmitz [mailto:j...@schmitz-digital.de] > Sent: Saturday, September 15, 2012 7:15 PM > To: 'Junio C Hamano' > Cc: 'git@vger.kernel.org' > Subject: RE: What's cooking in git.git (Sep 2012, #05; Fri, 14) > > > From: Junio C Hamano [mailto:gits...@pobox.com] > > Sent: Saturday, September 15, 2012 7:01 PM > > To: Joachim Schmitz > > Cc: git@vger.kernel.org > > Subject: Re: What's cooking in git.git (Sep 2012, #05; Fri, 14) > > > > "Joachim Schmitz" writes: > > > > > Junio C Hamano wrote: > > >> I think we can start thinking about feature freeze once the topics > > >> in 'next' that are scheduled to graduate to 'master' already are > > >> fully cooked. For any late-coming topic, there always is the next > > >> cycle ;-) > > > > > > I've not hear anything about my poll patches and I'd really like them > > > to into 1.8.x. > > > > I've seen some patches on "poll" posted, were discussed and had > > threads titled "Re: [PATCH] ...". But I didn't see a rerolled > > "[PATCH v2 n/m] ..." series that states that it is a rerolled > > "hopefully final version" that addresses all the points that were > > brought up during the discussion that need to be addressed. > > > > I do not necessarily follow all the minute details of all discussion > > threads. For this particular series, I not know which ones of your > > "poll patches" turned out to be unneeded, which ones turned out to > > be fine as posted originally and which ones needed updating. > > There were several iterations up to [PATCH v4 n/4] and only one foreign > comment to it (and to some commented code) and one self- > comment about the order of patches, but none about technical correctness, > none that I remember at least. > > I can post a v5 series which will Actually v6, seems I got myself confused in what I send already, one part of the series was on v5 already, aother on v4 and yet another still on v3. > - move compat/win32/poll.[ch] to compat/poll/ and adjust Makefile > - #ifdef some WIN32 specific #include (should this be done in one step with > the above?) Decided for 2 patches > - fix the 2 bugs in poll.c just like they got fixed in gnulib's version > (would you want this in one or two steps?) Likewise Bye, Jojo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 3/4] poll() exits too early with EFAULT if 1st arg is NULL
If poll() is used as a milli-second sleep, like in help.c, by passing a NULL
in the 1st and a 0 in the 2nd arg, it exits with EFAULT.
As per Paolo Bonzini, the original author, this is a bug and to be fixed
like
in this commit, which is not to exit if the 2nd arg is 0. It got fixed in
gnulib in the same manner the other day.
Signed-off-by: Joachim Schmitz
---
compat/poll/poll.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/compat/poll/poll.c b/compat/win32/poll.c
index 403eaa7..9e7a25c 100644
--- a/compat/poll/poll.c
+++ b/compat/poll/poll.c
@@ -349,7 +349,7 @@ poll (struct pollfd *pfd, nfds_t nfd, int timeout)
/* EFAULT is not necessary to implement, but let's do it in the
simplest case. */
- if (!pfd)
+ if (!pfd && nfd)
{
errno = EFAULT;
return -1;
--
1.7.12
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 4/4] make poll() work on platforms that can't recv() on a non-socket
This way it just got added to gnulib too the other day. Signed-off-by: Joachim Schmitz --- compat/poll/poll.c | 5 + 1 file changed, 4 insertions(+) diff --git a/compat/poll/poll.c b/compat/poll/poll.c index e4b8319..10a204e 100644 --- a/compat/poll/poll.c +++ b/compat/poll/poll.c @@ -306,6 +306,10 @@ compute_revents (int fd, int sought, fd_set *rfds, fd_set *wfds, fd_set *efds) || socket_errno == ECONNABORTED || socket_errno == ENETRESET) happened |= POLLHUP; + /* some systems can't use recv() on non-socket, including HP NonStop */ + else if (socket_errno == ENOTSOCK) + happened |= (POLLIN | POLLRDNORM) & sought; + else happened |= POLLERR; } -- 1.7.12 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 2/4] fix some win32 specific dependencies in poll.c
In order for non-win32 platforms to be able to use poll.c, #ifdef the inclusion of two header files in the same manner as it's done elsewhere in git. Signed-off-by: Joachim Schmitz --- compat/poll/poll.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/compat/poll/poll.c b/compat/poll/poll.c index 9e7a25c..e4b8319 100644 --- a/compat/poll/poll.c +++ b/compat/poll/poll.c @@ -24,7 +24,9 @@ # pragma GCC diagnostic ignored "-Wtype-limits" #endif -#include +#if defined(WIN32) +# include +#endif #include @@ -48,7 +50,9 @@ #else # include # include -# include +# ifndef NO_SYS_SELECT_H +# include +# endif # include #endif -- 1.7.12 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 1/4] make poll available for other platforms lacking it
move poll.[ch] out of compat/win32/ into compat/poll/ and adjust
Makefile with the changed paths. Adding comments to Makefile about how/when
to enable it and add logic for this
Signed-off-by: Joachim Schmitz
---
Makefile | 20 +++-
compat/{win32 => poll}/poll.c | 0
compat/{win32 => poll}/poll.h | 0
3 files changed, 15 insertions(+), 5 deletions(-)
rename compat/{win32 => poll}/poll.c (100%)
rename compat/{win32 => poll}/poll.h (100%)
diff --git a/Makefile b/Makefile
index ac49320..7893297 100644
--- a/Makefile
+++ b/Makefile
@@ -152,6 +152,11 @@ all::
#
# Define NO_MMAP if you want to avoid mmap.
#
+# Define NO_SYS_POLL_H if you don't have sys/poll.h.
+#
+# Define NO_POLL if you do not have or don't want to use poll().
+# This also implies NO_SYS_POLL_H.
+#
# Define NO_PTHREADS if you do not have or do not want to use Pthreads.
#
# Define NO_PREAD if you have a problem with pread() system call (e.g.
@@ -598,10 +603,10 @@ LIB_H += compat/bswap.h
LIB_H += compat/cygwin.h
LIB_H += compat/mingw.h
LIB_H += compat/obstack.h
+LIB_H += compat/poll/poll.h
LIB_H += compat/precompose_utf8.h
LIB_H += compat/terminal.h
LIB_H += compat/win32/dirent.h
-LIB_H += compat/win32/poll.h
LIB_H += compat/win32/pthread.h
LIB_H += compat/win32/syslog.h
LIB_H += connected.h
@@ -1220,7 +1225,7 @@ ifeq ($(uname_S),Windows)
NO_PREAD = YesPlease
NEEDS_CRYPTO_WITH_SSL = YesPlease
NO_LIBGEN_H = YesPlease
- NO_SYS_POLL_H = YesPlease
+ NO_POLL_H = YesPlease
NO_SYMLINK_HEAD = YesPlease
NO_IPV6 = YesPlease
NO_UNIX_SOCKETS = YesPlease
@@ -1261,7 +1266,7 @@ ifeq ($(uname_S),Windows)
BASIC_CFLAGS
= -nologo -I. -I../zlib -Icompat/vcbuild -Icompat/vcbuild/include -DWIN32 -D_CONSOLE
-DHAVE_STRING_H
-D_CRT_SECURE_NO_WARNINGS -D_CRT_NONSTDC_NO_DEPRECATE
COMPAT_OBJS = compat/msvc.o compat/winansi.o \
compat/win32/pthread.o compat/win32/syslog.o \
- compat/win32/poll.o compat/win32/dirent.o
+ compat/win32/dirent.o
COMPAT_CFLAGS
= -D__USE_MINGW_ACCESS -DNOGDI -DHAVE_STRING_H -DHAVE_ALLOCA_H -Icompat -Icompat/regex
-Icompat/win32
-DSTRIP_EXTENSION=\".exe\"
BASIC_LDFLAGS
= -IGNORE:4217 -IGNORE:4049 -NOLOGO -SUBSYSTEM:CONSOLE -NODEFAULTLIB:MSVCRT.lib
EXTLIBS = user32.lib advapi32.lib shell32.lib wininet.lib ws2_32.lib
@@ -1316,7 +1321,7 @@ ifneq (,$(findstring MINGW,$(uname_S)))
NO_PREAD = YesPlease
NEEDS_CRYPTO_WITH_SSL = YesPlease
NO_LIBGEN_H = YesPlease
- NO_SYS_POLL_H = YesPlease
+ NO_POLL_H = YesPlease
NO_SYMLINK_HEAD = YesPlease
NO_UNIX_SOCKETS = YesPlease
NO_SETENV = YesPlease
@@ -1351,7 +1356,7 @@ ifneq (,$(findstring MINGW,$(uname_S)))
COMPAT_CFLAGS += -DSTRIP_EXTENSION=\".exe\"
COMPAT_OBJS += compat/mingw.o compat/winansi.o \
compat/win32/pthread.o compat/win32/syslog.o \
- compat/win32/poll.o compat/win32/dirent.o
+ compat/win32/dirent.o
EXTLIBS += -lws2_32
PTHREAD_LIBS =
X = .exe
@@ -1605,6 +1610,11 @@ ifdef NO_GETTEXT
BASIC_CFLAGS += -DNO_GETTEXT
USE_GETTEXT_SCHEME ?= fallthrough
endif
+ifdef NO_POLL
+ NO_SYS_POLL_H = YesPlease
+ COMPAT_CFLAGS += -DNO_POLL -Icompat/poll
+ COMPAT_OBJS += compat/poll/poll.o
+endif
ifdef NO_STRCASESTR
COMPAT_CFLAGS += -DNO_STRCASESTR
COMPAT_OBJS += compat/strcasestr.o
diff --git a/compat/win32/poll.c b/compat/poll/poll.c
similarity index 100%
rename from compat/win32/poll.c
rename to compat/poll/poll.c
diff --git a/compat/win32/poll.h b/compat/poll/poll.h
similarity index 100%
rename from compat/win32/poll.h
rename to compat/poll/poll.h
--
1.7.12
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 0/4] Support non-WIN32 systems lacking poll()
Here's now my updated series of patches to make the win32 implementation of poll() available to other platforms: 1 - make poll available for other platforms lacking it by moving it into a separate directory and adjusting Makefile 2 - fix some win32 specific dependencies in poll.c by #ifdef the inclusion of two header files 3 - poll() exits too early with EFAULT if 1st arg is NULL, as fixed in gnulib recently 4 - make poll() work on platforms that can't recv() on a non-socket, namely HP NonStop, as fixed in gnulib recently Bye, Jojo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: What's cooking in git.git (Sep 2012, #05; Fri, 14)
> From: Junio C Hamano [mailto:gits...@pobox.com] > Sent: Saturday, September 15, 2012 7:01 PM > To: Joachim Schmitz > Cc: git@vger.kernel.org > Subject: Re: What's cooking in git.git (Sep 2012, #05; Fri, 14) > > "Joachim Schmitz" writes: > > > Junio C Hamano wrote: > >> I think we can start thinking about feature freeze once the topics > >> in 'next' that are scheduled to graduate to 'master' already are > >> fully cooked. For any late-coming topic, there always is the next > >> cycle ;-) > > > > I've not hear anything about my poll patches and I'd really like them > > to into 1.8.x. > > I've seen some patches on "poll" posted, were discussed and had > threads titled "Re: [PATCH] ...". But I didn't see a rerolled > "[PATCH v2 n/m] ..." series that states that it is a rerolled > "hopefully final version" that addresses all the points that were > brought up during the discussion that need to be addressed. > > I do not necessarily follow all the minute details of all discussion > threads. For this particular series, I not know which ones of your > "poll patches" turned out to be unneeded, which ones turned out to > be fine as posted originally and which ones needed updating. There were several iterations up to [PATCH v4 n/4] and only one foreign comment to it (and to some commented code) and one self-comment about the order of patches, but none about technical correctness, none that I remember at least. I can post a v5 series which will - move compat/win32/poll.[ch] to compat/poll/ and adjust Makefile - #ifdef some WIN32 specific #include (should this be done in one step with the above?) - fix the 2 bugs in poll.c just like they got fixed in gnulib's version (would you want this in one or two steps?) Bye, Jojo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Sep 2012, #05; Fri, 14)
Junio C Hamano wrote: I think we can start thinking about feature freeze once the topics in 'next' that are scheduled to graduate to 'master' already are fully cooked. For any late-coming topic, there always is the next cycle ;-) I've not hear anything about my poll patches and I'd really like them to into 1.8.x. If and when they did, there's another small patch to fully support HP NonStop (some adjustment to git-compat-util.h with #ifdef __TANDEM and a NonStop section in Makefile, so nothing that should have any bad impact on others), which I too would like to get in 1.8.x Bye, Jojo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/4] poll() exits too early with EFAULT if 1st arg is NULL
Joachim Schmitz wrote:
Joachim Schmitz wrote:
If poll() is used as a milli-second sleep, like in help.c, by passing
a NULL in the 1st and a 0 in the 2nd arg, it exits with EFAULT.
As per Paolo Bonzini, the original author, this is a bug and to be
fixed like in this commit, which is not to exit if the 2nd arg is 0.
Signed-off-by: Joachim Schmitz
---
compat/win32/poll.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/compat/win32/poll.c b/compat/win32/poll.c
index 403eaa7..9e7a25c 100644
--- a/compat/win32/poll.c
+++ b/compat/win32/poll.c
@@ -349,7 +349,7 @@ poll (struct pollfd *pfd, nfds_t nfd, int
timeout)
/* EFAULT is not necessary to implement, but let's do it in the
simplest case. */
- if (!pfd)
+ if (!pfd && nfd)
{
errno = EFAULT;
return -1;
Actually this one is not needed for win32 (nor does win32 suffer from
a similar bug), so should probably better get added after patch 2/2
(or as part of it), the move to compat/poll/.
It just got added that was to gnulib, with a commit message of:
don't exit early if NULL is the 1st arg to poll(),
but nfd is 0. In that case poll should behave like select.
Bye, Jojo
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v5 4/4] make poll() work on platforms that can't recv() on a non-socket
This way it just got added to gnulib too. Signed-off-by: Joachim Schmitz --- compat/poll/poll.c | 5 + 1 file changed, 4 insertions(+) diff --git a/compat/poll/poll.c b/compat/poll/poll.c index e4b8319..10a204e 100644 --- a/compat/poll/poll.c +++ b/compat/poll/poll.c @@ -306,6 +306,10 @@ compute_revents (int fd, int sought, fd_set *rfds, fd_set *wfds, fd_set *efds) || socket_errno == ECONNABORTED || socket_errno == ENETRESET) happened |= POLLHUP; + /* some systems can't use recv() on non-socket, including HP NonStop */ + else if (socket_errno == ENOTSOCK) + happened |= (POLLIN | POLLRDNORM) & sought; + else happened |= POLLERR; } -- 1.7.12 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
