* Re: [PATCH] HP-UX does not have select.h
From: H.Merijn Brand @ 2007-12-18 10:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Ericsson, git
In-Reply-To: <7vir2w1ghi.fsf@gitster.siamese.dyndns.org>
On Tue, 18 Dec 2007 01:47:53 -0800, Junio C Hamano <gitster@pobox.com> wrote:
> Andreas Ericsson <ae@op5.se> writes:
>
> > Junio C Hamano wrote:
> >>
> >> Besides, isn't _HPUX_SOURCE a feature-test macro? Feature test macros
> >> are for the application to define, and for the implementation (iow, the
> >> header files) to find out what set of names the application wants to
> >> see. You are making the application examine the symbol to see what
> >> implementation it is on, which feels backwards to me.
> >
> >
> > #if defined(hpux) || defined(_hpux) || defined(__hpux)
> >
> > should work ok, although as you say, trying
> >
> > #if _POSIX_VERSION < 200112
> > # include <non-POSIX.1-2001 headers>
> > #else
> > # include <sys/select.h>
> > #endif
> >
> > would probably be more suitable.
>
> I cannot take credit for having said that (I didn't), but it sounds like
> a sensible thing to compare _POSIX_VERSION with 200112L. For previous
> SUS, <sys/time.h> would have defined select(2), but that header file is
> already included anyway.
>
> Merijn, discarding the earlier patch I did to configure it out for
> HP-UX, does the following patch based on Andreas's idea work for you?
Probably not:
HP-UX 10.20, 11.00, 11.11, 11.23/PA, and 11.23/IPF all have:
/usr/include 103 > grep -r POSIX_VERSION *
sys/unistd.h:# define _POSIX_VERSION _POSIX1_VERSION_88
sys/unistd.h:# define _POSIX_VERSION _POSIX1_VERSION_90
sys/unistd.h:# define _POSIX_VERSION _POSIX1_VERSION_93
sys/unistd.h:# define _SC_1_VERSION_88 7 /* _POSIX_VERSION: Date of POSIX.1-1988 */
sys/unistd.h:# define _SC_1_VERSION_90 102 /* _POSIX_VERSION: Date of POSIX.1-1990 */
sys/unistd.h:# define _SC_1_VERSION_93 103 /* _POSIX_VERSION: Date of POSIX.1b-1993 */
sys/unistd.h:# if (_POSIX_VERSION == _POSIX1_VERSION_88)
sys/unistd.h:# if (_POSIX_VERSION == _POSIX1_VERSION_90)
and the two 11.23 do have select.h
> ---
>
> git-compat-util.h | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/git-compat-util.h b/git-compat-util.h
> index 79eb10e..68a580f 100644
> --- a/git-compat-util.h
> +++ b/git-compat-util.h
> @@ -68,7 +68,9 @@
> #include <sys/poll.h>
> #include <sys/socket.h>
> #include <sys/ioctl.h>
> +#if _POSIX_VERSION >= 200112L
> #include <sys/select.h>
> +#endif
> #include <assert.h>
> #include <regex.h>
> #include <netinet/in.h>
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using & porting perl 5.6.2, 5.8.x, 5.10.x on HP-UX 10.20, 11.00, 11.11,
& 11.23, SuSE 10.1 & 10.2, AIX 5.2, and Cygwin. http://qa.perl.org
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org
http://www.goldmark.org/jeff/stupid-disclaimers/
^ permalink raw reply
* Re: [PATCH] allow a single form feed in pre commit hook
From: Jakub Narebski @ 2007-12-18 10:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Hannes Eder, git
In-Reply-To: <7v4peg1f33.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> "Hannes Eder" <hannes.eder@gmail.com> writes:
>
> > It's not uncommon to have a lines with a single form feed in it, e.g.
> > the default GPL COPYING and also in .c files and others. Attached
> > patch allows this in the pre-commit hook.
>
> Hmm. The current trend is to get rid of the whitespace checks from this
> hook and enrich git-diff --check and git-apply --whitespace=error.
>
> I've been planning to add a new whitespace error rule that allows ^M at
> the end of line, post 1.5.4. Another rule that allows a lone ^L would
> match what you are doing here, and it would be a good addition as well.
There probably should also be 'trailing-empty-lines' rule; also
'eol-at-eof' could be useful as well (ensuring that final line ends
with newline character).
By the way, the check in pre-commit hook also checks for merge
conflict markers. Those are not whitespace errors, but are quite
similar. It would be nice to have this also .gitattributes
controlled, to avoid false positoves for changes in
Documentation/*.txt; althought perhaps more strict checking would be
enough...
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] allow a single form feed in pre commit hook
From: Junio C Hamano @ 2007-12-18 10:18 UTC (permalink / raw)
To: Hannes Eder; +Cc: git
In-Reply-To: <5d2716640712180147x36aa3178ja8658e30842c4e52@mail.gmail.com>
"Hannes Eder" <hannes.eder@gmail.com> writes:
> It's not uncommon to have a lines with a single form feed in it, e.g.
> the default GPL COPYING and also in .c files and others. Attached
> patch allows this in the pre-commit hook.
Hmm. The current trend is to get rid of the whitespace checks from this
hook and enrich git-diff --check and git-apply --whitespace=error.
I've been planning to add a new whitespace error rule that allows ^M at
the end of line, post 1.5.4. Another rule that allows a lone ^L would
match what you are doing here, and it would be a good addition as well.
^ permalink raw reply
* [PATCH] allow a single form feed in pre commit hook
From: Hannes Eder @ 2007-12-18 10:09 UTC (permalink / raw)
To: git
It's not uncommon to have a line with a single form feed in it, e.g.
the default GPL COPYING and also in .c files and others. Attached
patch allows this in the pre-commit hook.
-Hannes
diff --git a/templates/hooks--pre-commit b/templates/hooks--pre-commit
index 7092bae..a759f92 100644
--- a/templates/hooks--pre-commit
+++ b/templates/hooks--pre-commit
@@ -55,7 +55,7 @@ perl -e '
if (s/^\+//) {
$lineno++;
chomp;
- if (/\s$/) {
+ if (!/^\f$/ && /\s$/) {
bad_line("trailing whitespace", $_);
}
if (/^\s* \t/) {
^ permalink raw reply related
* [PATCH] git-filter-branch.sh: more portable tr usage: use \012, not \n.
From: Jim Meyering @ 2007-12-18 10:03 UTC (permalink / raw)
To: git list
I hesitate to suggest this, since GNU tr has accepted \n for 15 years,
but there are supposedly a few crufty vendor-supplied versions of tr still
in use. Also, all of the other uses of tr-with-newline in git use \012.
Signed-off-by: Jim Meyering <meyering@redhat.com>
---
git-filter-branch.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 3bb2f67..ee9e1b3 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -290,7 +290,7 @@ while read commit parents; do
eval "$filter_tree" < /dev/null ||
die "tree filter failed: $filter_tree"
- git diff-index -r $commit | cut -f 2- | tr '\n' '\000' | \
+ git diff-index -r $commit | cut -f 2- | tr '\012' '\000' | \
xargs -0 git update-index --add --replace --remove
git ls-files -z --others | \
xargs -0 git update-index --add --replace --remove
--
1.5.4.rc0.53.gdfcd
^ permalink raw reply related
* Re: [PATCH] filter-branch: Remove broken and unnecessary summary of rewritten refs.
From: Junio C Hamano @ 2007-12-18 9:56 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Johannes Schindelin, git
In-Reply-To: <1197963047-15930-1-git-send-email-johannes.sixt@telecom.at>
Sounds sensible. Applied.
^ permalink raw reply
* Re: [PATCH] HP-UX does not have select.h
From: Junio C Hamano @ 2007-12-18 9:47 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: H.Merijn Brand, git
In-Reply-To: <4767934F.7070706@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Junio C Hamano wrote:
>>
>> Besides, isn't _HPUX_SOURCE a feature-test macro? Feature test macros
>> are for the application to define, and for the implementation (iow, the
>> header files) to find out what set of names the application wants to
>> see. You are making the application examine the symbol to see what
>> implementation it is on, which feels backwards to me.
>
>
> #if defined(hpux) || defined(_hpux) || defined(__hpux)
>
> should work ok, although as you say, trying
>
> #if _POSIX_VERSION < 200112
> # include <non-POSIX.1-2001 headers>
> #else
> # include <sys/select.h>
> #endif
>
> would probably be more suitable.
I cannot take credit for having said that (I didn't), but it sounds like
a sensible thing to compare _POSIX_VERSION with 200112L. For previous
SUS, <sys/time.h> would have defined select(2), but that header file is
already included anyway.
Merijn, discarding the earlier patch I did to configure it out for
HP-UX, does the following patch based on Andreas's idea work for you?
---
git-compat-util.h | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index 79eb10e..68a580f 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -68,7 +68,9 @@
#include <sys/poll.h>
#include <sys/socket.h>
#include <sys/ioctl.h>
+#if _POSIX_VERSION >= 200112L
#include <sys/select.h>
+#endif
#include <assert.h>
#include <regex.h>
#include <netinet/in.h>
^ permalink raw reply related
* [PATCH] allow a single form feed in pre commit hook
From: Hannes Eder @ 2007-12-18 9:47 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 187 bytes --]
It's not uncommon to have a lines with a single form feed in it, e.g.
the default GPL COPYING and also in .c files and others. Attached
patch allows this in the pre-commit hook.
-Hannes
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: pre-commit-hook-allow-form-feed-200712181.patch --]
[-- Type: text/x-diff; name=pre-commit-hook-allow-form-feed-200712181.patch, Size: 591 bytes --]
From 454ede83f7a45741d825f0b6cbdb0be2ac235fdb Mon Sep 17 00:00:00 2001
From: Hannes Eder <Hannes@HannesEder.net>
Date: Tue, 18 Dec 2007 10:21:11 +0100
Subject: [PATCH] allow a lines with just one form feed in pre-commit hook
diff --git a/templates/hooks--pre-commit b/templates/hooks--pre-commit
index 7092bae..a759f92 100644
--- a/templates/hooks--pre-commit
+++ b/templates/hooks--pre-commit
@@ -55,7 +55,7 @@ perl -e '
if (s/^\+//) {
$lineno++;
chomp;
- if (/\s$/) {
+ if (!/^\f$/ && /\s$/) {
bad_line("trailing whitespace", $_);
}
if (/^\s* \t/) {
^ permalink raw reply related
* Re: [PATCH] Authentication support for pserver
From: Martin Langhoff @ 2007-12-18 9:41 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: Junio C Hamano, git, martyn, martin
In-Reply-To: <877ijhm1b5.fsf@cpan.org>
On Dec 15, 2007 10:08 AM, Ævar Arnfjörð Bjarmason <avar@cpan.org> wrote:
> > Looks good. I'll queue only so that I won't lose it and wait for Acks
> > from Mart[iy]ns. Please sign off your patch.
I have been mulling a bit about this change. Seems correct from a code
flow POV. But anon pserver support was added with a lot of
trepidation. Authenticated, write-enabled pserver support fills me
with dread ;-)
A few things that come to mind
- git/config is very likely to be readable if the site is served via
other means, like dumb http protocol, or git+ssh. So even if the
password scrambling is mickey-mouse. it might make sense to force the
password data to live elsewhere.
- umasks/file permissions will probably be handled by the underlying
git tools and core.sharedrepository, since we no longer update refs
"manually". So after a bit of thinking, this should not be an issue.
- I still worry about running cvsserver with an acct that has write
privileges. With anon, all we need write access is the sqlite db, and
that's not even based on user input. And it can be relocated elsewhere
via git/config.
So, wondering about input validation and related matters re-read most
of cvsserver. The only suspicious bit I find is a caller to
transmitfile @ lines 1117, where the 2nd parameter doesn't come from
tempfile() - if a nasty filename sneaked in, we could (perhaps) be in
for a surprise. We do that for diff header prettyness - we could use
--label / -L instead. Will try and prep a patch for that tomorrow if
noone beats me to it (bedtime in nz!).
Hmmm. Does "worried ACK" count as an ACK? Can we add big fat warnings
along the lines of "run this in a locked down environment, pretty
please"?
cheers,
m
^ permalink raw reply
* Re: [PATCH] HP-UX does not have select.h
From: Andreas Ericsson @ 2007-12-18 9:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: H.Merijn Brand, git
In-Reply-To: <7v8x3t6nq1.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
>
> Besides, isn't _HPUX_SOURCE a feature-test macro? Feature test macros
> are for the application to define, and for the implementation (iow, the
> header files) to find out what set of names the application wants to
> see. You are making the application examine the symbol to see what
> implementation it is on, which feels backwards to me.
#if defined(hpux) || defined(_hpux) || defined(__hpux)
should work ok, although as you say, trying
#if _POSIX_VERSION < 200112
# include <non-POSIX.1-2001 headers>
#else
# include <sys/select.h>
#endif
would probably be more suitable.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git with custom diff for commits
From: Junio C Hamano @ 2007-12-18 9:25 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Johannes Schindelin, Gerald Gutierrez, git
In-Reply-To: <vpqk5ncz8fn.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> Junio C Hamano <gitster@pobox.com> writes:
> ...
>> I wouldn't do filters for something like that. Can you guarantee that
>> the output from corresopnding smudge filter will load cleanly back to
>> the mysql database?
>
> The original poster said the date was an SQL comment, so, it should be
> safe to strip it. That said, precommit hook is probably a good or
> better solution. At least, if you're not sure you didn't make a
> mistake writting it, you'll notice either a good commit or no commit
> at all. With filters, you might well notice you corrupted the commit
> too late :-(.
Yeah. After writing the message you are responding to, I realized that
I already do something like that to manage html/man branches that are
autogenerated, and it is exactly the same situation as Gerald is in.
The autogeneration of documentation and updating of html/man branches is
controlled by dodoc.sh script in 'todo' branch, installed as post-update
hook in my public repository. It builds the documentation in a checkout
of 'master' branch, installs the result into another checkout of 'html'
and 'man' branches, and commits.
The twist is in the "install" step (this is different from my suggestion
of preventing the commit in pre-commit hook). When the newly generated
documentation files are different from the previously generated ones
only by datestamp, they are not installed into 'html'/'man' checkouts,
and such a change is not included in the commits.
So my updated suggestion would be:
- Keep a checkout of that mysql dump;
- Make the dump procedure to dump to that checkout area;
- Run "git diff HEAD", perhaps with the external diff that filters out
the cruft as suggested in the thread, and run "git checkout $path"
for paths that had only meaningless changes;
- Run "git commit" if the above step did not nuke all changes.
^ permalink raw reply
* Re: [PATCH] provide advance warning of some future pack default changes
From: Jakub Narebski @ 2007-12-18 9:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Martin Langhoff, Nicolas Pitre, Joel Becker, git
In-Reply-To: <7vlk7s38aq.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> "Martin Langhoff" <martin.langhoff@gmail.com> writes:
>
>> If cvs 1.11 doesn't talk with 1.12 I'll say there are nuts - minor
>> revisions should interoperate with end users not even thinking about
>> it. But 1.5.5 has in its changelog lots of deprecations and interop
>> changes.
>>
>> It's not good communication to label it 1.5.5.
>
> There indeed are handful scheduled removals. I do not mind declaring
> that 1.6.0 comes after 1.5.4, or just relabel the removal schedule for
> 1.6.0 and keep the scheduled change on hold a bit longer.
By the way, I wonder if there would be packv4 in time for 1.6.0;
perhaps not enabled by default.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [StGit PATCH 00/17] Series short description
From: Karl Hasselström @ 2007-12-18 9:24 UTC (permalink / raw)
To: Catalin Marinas; +Cc: David Kågedal, git
In-Reply-To: <b0943d9e0712180111l3294e1adj60b5271b9820c60c@mail.gmail.com>
On 2007-12-18 09:11:00 +0000, Catalin Marinas wrote:
> On 17/12/2007, Karl Hasselström <kha@treskal.com> wrote:
>
> > Be careful about merging past the "goto" patch -- I'm pretty sure
> > it breaks when called from a subdirectory, and I don't have time
> > to fix that right now. (It should be a clean fix, though -- just
> > adjust the cwd for precisely those git subprocesses that need it,
> > which is very few. I think.)
>
> Why not just change the cwd when the command starts and it should be
> safe for all the git subprocesses.
It doesn't feel very clean to require the caller of some unspecified
subset of git calls to remember to set the correct piece of global
state.
And the correct solution should really be very simple, since it's
precisely the worktree operations (specifically, the subset thereof
that have to operate on the whole tree) that require setting cwd. And
those are very clearly separated out from the rest in the new
infrastructure.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [StGit PATCH 00/17] Series short description
From: David Kågedal @ 2007-12-18 9:20 UTC (permalink / raw)
To: Karl Hasselström, Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0712180111l3294e1adj60b5271b9820c60c@mail.gmail.com>
"Catalin Marinas" <catalin.marinas@gmail.com> writes:
> On 17/12/2007, Karl Hasselström <kha@treskal.com> wrote:
>> On 2007-12-17 11:09:06 +0000, Catalin Marinas wrote:
>>
>> > On 14/12/2007, David Kågedal <davidk@lysator.liu.se> wrote:
>> >
>> > > The following series an emacs interface to stgit patch stacks. It
>> > > shows a buffer with the the output of "stg series" and allows you
>> > > to do some common operations on it, such as push/pop,
>> > > commit/uncommit, edit, rename, repair, and coalesce.
>> >
>> > That's really cool stuff! Thanks.
>>
>> Yes, incredibly useful.
>
> Other useful commands would be support for 'patches' and a local
> diff/status (and maybe a menu).
I have some ideas for some way of showing the current status, but
nothing is implemented yet. For some of the more complex cases, I'd
like to refer to git.el, although I think that needs some
improvements.
I don't think I ever used the 'patches' command, so I'm not sure what
the best way to implement it would be.
And my emacs has no menu, so I'm probably not the best person to adda
menu, either :-)
--
David Kågedal
^ permalink raw reply
* Re: [PATCH] Explain what 'ginstall' is
From: Jakub Narebski @ 2007-12-18 9:14 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: Andy Dougherty, git
In-Reply-To: <20071218093819.0b1caf16@pc09.procura.nl>
On Tue, 18 Dec 2007, H.Merijn Brand wrote:
> On Tue, 18 Dec 2007 09:20:38 +0100, Jakub Narebski <jnareb@gmail.com> wrote:
>> On Tue, 18 Dec 2007, H.Merijn Brand wrote:
>>> On Mon, 17 Dec 2007 17:21:08 -0800 (PST), Jakub Narebski wrote:
>>>>
>>>> Second, the default autoconf macro AC_PROG_INSTALL *requires* that
>>>> there is BSD-compatible `install' program (as 'install-sh' or
>>>> 'install.sh') in the sources. Adding such script is (I think) not a
>>>> problem; finding minimal portable[*1*] script is.
>>>> So if you know one...
>>
>> [...]. There is need for BSD-compatibile
>> `install` program as 'install-sh', not 'make-install' script. The idea
>> is to use system-provided 'install' if it exists and is compatibile,
>
> There lies the problem. HP-UX does have an 'install', but it is not
> compatible, and chances are (very) small that people have installed
> the GNU or any other BSD compliant install.
>
>> because it should be faster than script version, and fallback to
>> provided install-sh only if system install is not found.
>
> The problem again. It *does* find install, but it turns out to be
> unusable.
Could you check if ./configure correctly uses install-sh in your case?
Copy install-sh from for example autotools[*1*] (e.g. libtool has one)
to the git sources, uncomment line with AC_PROG_INSTALL in configure.ac,
generate configure script using "make configure" and check what
./configure chooses.
In my case it is:
$ cp /usr/share/libtool/install-sh .
$ make configure
GIT_VERSION = 1.5.4.rc0.56.g6fbe-dirty
GEN configure
$ ./configure
configure: CHECKS for programs
[...]
checking for a BSD-compatible install... /usr/bin/install -c
What is ./configure output in your case?
Footnotes:
----------
[*1*] Or for example http://svn.scheffers.net/zlib/tclconfig/install-sh
which is smaller (2189 bytes vs. 9233 autotools one, or 10970 from
kapptemplate (kdesdk 3.5.3)).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [StGit PATCH 00/17] Series short description
From: Catalin Marinas @ 2007-12-18 9:11 UTC (permalink / raw)
To: Karl Hasselström; +Cc: David Kågedal, git
In-Reply-To: <20071217224812.GA6342@diana.vm.bytemark.co.uk>
On 17/12/2007, Karl Hasselström <kha@treskal.com> wrote:
> On 2007-12-17 11:09:06 +0000, Catalin Marinas wrote:
>
> > On 14/12/2007, David Kågedal <davidk@lysator.liu.se> wrote:
> >
> > > The following series an emacs interface to stgit patch stacks. It
> > > shows a buffer with the the output of "stg series" and allows you
> > > to do some common operations on it, such as push/pop,
> > > commit/uncommit, edit, rename, repair, and coalesce.
> >
> > That's really cool stuff! Thanks.
>
> Yes, incredibly useful.
Other useful commands would be support for 'patches' and a local
diff/status (and maybe a menu).
> Be careful about merging past the "goto" patch -- I'm pretty sure it
> breaks when called from a subdirectory, and I don't have time to fix
> that right now. (It should be a clean fix, though -- just adjust the
> cwd for precisely those git subprocesses that need it, which is very
> few. I think.)
Why not just change the cwd when the command starts and it should be
safe for all the git subprocesses.
> If you like, I can advance "safe" to include as many patches as I
> think you should merge right now.
OK, thanks.
--
Catalin
^ permalink raw reply
* Re: [PATCH] Fix segfault in diff-delta.c when FLEX_ARRAY is 1
From: Junio C Hamano @ 2007-12-18 9:07 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Pierre Habouzit, spearce, Git Mailing List
In-Reply-To: <alpine.LFD.0.9999.0712172146070.21557@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> But there's a few that aren't obviously allocations (this is a list done
> with grep and sparse, I didn't look at whether the values used are then
> all allocation-related):
>
> - builtin-blame.c:128 memset(o, 0, sizeof(*o));
This is harmless and in fact unnecessary clearing, immediately before
calling free(3).
> - diff-delta.c:250 memsize = sizeof(*index)
I haven't studied this codepath.
> - object-refs.c:23 size_t size = sizeof(*refs) + count*sizeof(struct object *);
Overallocation to have at least "count" pointers to "struct object".
> - object-refs.c:61 size_t size = sizeof(*refs) + j*sizeof(struct object *);
Ditto for "j" pointers.
> - attr.c:220 sizeof(*res) +
Overallocation to have at least "num_attr" instances of "struct
attr_state" (plus name string if needed, which is stored using location
past state[num_attr]).
> - remote.c:467 memset(ret, 0, sizeof(struct ref) + namelen);
Clearing an arena that was overallocated to have at least namelen
elements of char[] on the line immediately before this, with matching
size. All callers pass namelen = strlen(name) + 1 so we are Ok even
when FLEX_ARRAY gives no extra space.
> - remote.c:474 memcpy(ret, ref, sizeof(struct ref) + strlen(ref->name) + 1);
Ditto.
> - transport.c:491 memset(ref, 0, sizeof(struct ref));
A line above overallocates to have enough room for strlen(ref_name) plus
terminating NUL, and after this lines clears the non-flex part, name is
copied. So this overclears a bit, but is harmless.
> diff --git a/unpack-trees.c b/unpack-trees.c
> index e9eb795..aa2513e 100644
> --- a/unpack-trees.c
> +++ b/unpack-trees.c
> @@ -590,7 +590,7 @@ static int merged_entry(struct cache_entry *merge, struct cache_entry *old,
> * a match.
> */
> if (same(old, merge)) {
> - *merge = *old;
> + memcpy(merge, old, offsetof(struct cache_entry, name));
> } else {
> verify_uptodate(old, o);
> invalidate_ce_path(old);
Portability of offsetof() is slightly worrisome, but giving a
compatibility macro is trivial if this turns out to be problematic for
some people.
^ permalink raw reply
* Re: git with custom diff for commits
From: Matthieu Moy @ 2007-12-18 8:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Gerald Gutierrez, git
In-Reply-To: <7vbq8o6gxw.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>>> It will show an empty output for "git diff", but I doubt thit will
>>> change anything at commit time. Probably the "filter" thing on the same
>>> file (also "man gitattributes") can help though.
>>
>> Ah, right. I completely missed that you were talking about git-commit,
>> not git-log on git commits.
>>
>> Yes, setting up a "clean" filter that removes the timestamps is probably
>> the reasonable thing to do here.
>
> I wouldn't do filters for something like that. Can you guarantee that
> the output from corresopnding smudge filter will load cleanly back to
> the mysql database?
The original poster said the date was an SQL comment, so, it should be
safe to strip it. That said, precommit hook is probably a good or
better solution. At least, if you're not sure you didn't make a
mistake writting it, you'll notice either a good commit or no commit
at all. With filters, you might well notice you corrupted the commit
too late :-(.
--
Matthieu
^ permalink raw reply
* Re: [PATCH] Explain what 'ginstall' is
From: H.Merijn Brand @ 2007-12-18 8:38 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Andy Dougherty, git
In-Reply-To: <200712180920.39633.jnareb@gmail.com>
On Tue, 18 Dec 2007 09:20:38 +0100, Jakub Narebski <jnareb@gmail.com> wrote:
> On Tue, 18 Dec 2007, H.Merijn Brand wrote:
> > On Mon, 17 Dec 2007 17:21:08 -0800 (PST), Jakub Narebski wrote:
> >
> >> Andy Dougherty <doughera@lafayette.edu> writes:
> >>
> >>> [...]. Perhaps configure
> >>> should just go looking for a suitable install program instead of
> >>> assuming everyone has one.
> >>
> >> First, configure is, and (I think) consensus is that it should remain
> >> optional. This means that Makefile "guess" section should have good
> >> defaults for your operating system.
> >
> > And what if you OS *does* have an install, but one that is completely
> > useless^Wdifferent from the GNU install? Like the utterly useless
> > install on HP-UX.
>
> Then "guess" section should have INSTALL=ginstall, or something.
> Or just install with
>
> INSTALL=/opt/bin/ginstall make install
Chances are close to zero that HP-UX systems have installed any working
or compliant version of install
> or something like that.
>
> >> Second, the default autoconf macro AC_PROG_INSTALL *requires* that
> >> there is BSD-compatible `install' program (as 'install-sh' or
> >> 'install.sh') in the sources. Adding such script is (I think) not a
> >> problem;
> >
> > Yeah!
> >
> >> finding minimal portable[*1*] script is. So if you know one...
> >>
> >> Footnotes:
> >> ----------
> >> [*1*] By "portable" I mean here 'git portable', i.e. requiring only
> >> those shell constructs/features that git require, not necessary
> >> insanelt portable the way ./configure script is.
> >
> > Something like this? (gui part still missing). This is what I now
> > use
> >
> > --8<--- make-install
>
> Errr... please read more carefully. There is need for BSD-compatibile
> `install` program as 'install-sh', not 'make-install' script. The idea
> is to use system-provided 'install' if it exists and is compatibile,
There lies the problem. HP-UX does have an 'install', but it is not
compatible, and chances are (very) small that people have installed
the GNU or any other BSD compliant install.
> because it should be faster than script version, and fallback to
> provided install-sh only if system install is not found.
The problem again. It *does* find install, but it turns out to be
unusable.
> install-sh has to understand '-d' and '-m <mode>' switches for git
> install purposes, and probably implement all three (src dest, src dir,
> dir) formats.
BTW the same, but worse exists for the 'patch' program. On HP-UX there
is a program called 'patch' which is used for system upgrades, but it
has nothing to do with the patch util the rest of the world so happily
uses.
So far that is used in a few places in the test suite, but I heared it
would not be too hard to eliminate the use of the hard-coded patch util
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using & porting perl 5.6.2, 5.8.x, 5.10.x on HP-UX 10.20, 11.00, 11.11,
& 11.23, SuSE 10.1 & 10.2, AIX 5.2, and Cygwin. http://qa.perl.org
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org
http://www.goldmark.org/jeff/stupid-disclaimers/
^ permalink raw reply
* Re: [PATCH] Explain what 'ginstall' is
From: Jakub Narebski @ 2007-12-18 8:20 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: Andy Dougherty, git
In-Reply-To: <20071218083843.42d7a15e@pc09.procura.nl>
On Tue, 18 Dec 2007, H.Merijn Brand wrote:
> On Mon, 17 Dec 2007 17:21:08 -0800 (PST), Jakub Narebski wrote:
>
>> Andy Dougherty <doughera@lafayette.edu> writes:
>>
>>> [...]. Perhaps configure
>>> should just go looking for a suitable install program instead of
>>> assuming everyone has one.
>>
>> First, configure is, and (I think) consensus is that it should remain
>> optional. This means that Makefile "guess" section should have good
>> defaults for your operating system.
>
> And what if you OS *does* have an install, but one that is completely
> useless^Wdifferent from the GNU install? Like the utterly useless
> install on HP-UX.
Then "guess" section should have INSTALL=ginstall, or something.
Or just install with
INSTALL=/opt/bin/ginstall make install
or something like that.
>> Second, the default autoconf macro AC_PROG_INSTALL *requires* that
>> there is BSD-compatible `install' program (as 'install-sh' or
>> 'install.sh') in the sources. Adding such script is (I think) not a
>> problem;
>
> Yeah!
>
>> finding minimal portable[*1*] script is. So if you know one...
>>
>> Footnotes:
>> ----------
>> [*1*] By "portable" I mean here 'git portable', i.e. requiring only
>> those shell constructs/features that git require, not necessary
>> insanelt portable the way ./configure script is.
>
> Something like this? (gui part still missing). This is what I now
> use
>
> --8<--- make-install
Errr... please read more carefully. There is need for BSD-compatibile
`install` program as 'install-sh', not 'make-install' script. The idea
is to use system-provided 'install' if it exists and is compatibile,
because it should be faster than script version, and fallback to
provided install-sh only if system install is not found.
install-sh has to understand '-d' and '-m <mode>' switches for git
install purposes, and probably implement all three (src dest, src dir,
dir) formats.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] HP-UX does not have select.h
From: Johannes Sixt @ 2007-12-18 8:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: H.Merijn Brand, git
In-Reply-To: <7vbq8o370k.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> "H.Merijn Brand" <h.m.brand@xs4all.nl> writes:
>
>> On Mon, 17 Dec 2007 13:00:22 -0800, Junio C Hamano <gitster@pobox.com> wrote:
>>
>>> "H.Merijn Brand" <h.m.brand@xs4all.nl> writes:
>>>
>>>> HP-UX does not have select.h, but it offers all select () functionality.
>>>> The defines are in <sys/types.h> and <X11/fd.h>
>>> Will apply the patch as-is for now, only because I do not want major
>>> surgery during rc period, but I think is can be improved.
>> ...
>>> Besides, isn't _HPUX_SOURCE a feature-test macro? Feature test macros
>> That is defined in GNU gcc. I did not pass it with -D...
>
> Actually I changed my mind. I won't be applying this as is.
>
> For the selective inclusion of <sys/select.h>, I would prefer it see it
> done like the attached.
Is select() actually needed? The one instance in pager.c can easily be
replaced by poll(), which I've already done in my own tree. The other one in
http.c is only used as a timer, but I don't know how to get rid of that.
Maybe a setitimer()/pause() combo?
-- Hannes
^ permalink raw reply
* Re: [PATCH] Explain what 'ginstall' is
From: H.Merijn Brand @ 2007-12-18 7:38 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Andy Dougherty, git
In-Reply-To: <m3tzmgpzlu.fsf@roke.D-201>
On Mon, 17 Dec 2007 17:21:08 -0800 (PST), Jakub Narebski <jnareb@gmail.com>
wrote:
> Andy Dougherty <doughera@lafayette.edu> writes:
>
> > [...]. Perhaps configure
> > should just go looking for a suitable install program instead of
> > assuming everyone has one.
>
> First, configure is, and (I think) consensus is that it should remain
> optional. This means that Makefile "guess" section should have good
> defaults for your operating system.
And what if you OS *does* have an install, but one that is completely
useless^Wdifferent from the GNU install? Like the utterly useless
install on HP-UX.
> Second, the default autoconf macro AC_PROG_INSTALL *requires* that
> there is BSD-compatible `install' program (as 'install-sh' or
> 'install.sh') in the sources. Adding such script is (I think) not a
> problem;
Yeah!
> finding minimal portable[*1*] script is. So if you know one...
>
> Footnotes:
> ----------
> [*1*] By "portable" I mean here 'git portable', i.e. requiring only
> those shell constructs/features that git require, not necessary
> insanelt portable the way ./configure script is.
Something like this? (gui part still missing). This is what I now
use
--8<--- make-install
#!/bin/sh
PREFIX=/pro/local
BINDIR=$PREFIX/bin
SHARED=$PREFIX/share
for p in git-fetch-pack git-hash-object git-index-pack git-fast-import \
git-daemon git-merge-index git-mktag git-mktree git-patch-id \
git-receive-pack git-send-pack git-shell git-show-index \
git-unpack-file git-update-server-info git-upload-pack \
git-pack-redundant git-var git-merge-tree git-imap-send \
git-merge-recursive git-bisect git-checkout git-clone \
git-merge-one-file git-mergetool git-parse-remote git-pull \
git-rebase git-rebase--interactive git-repack git-request-pull \
git-sh-setup git-am git-merge git-merge-stupid git-merge-octopus \
git-merge-resolve git-lost-found git-quiltimport git-submodule \
git-filter-branch git-stash git-add--interactive git-archimport \
git-cvsimport git-relink git-cvsserver git-remote git-cvsexportcommit \
git-send-email git-svn git-instaweb git-merge-subtree ; do
rm -f $BINDIR/$p
cp $p $BINDIR
chmod 755 $BINDIR/$p
done
cp git $BINDIR
cd templates
rm -rf $SHARED/git-core
mkdir $SHARED/git-core
mkdir $SHARED/git-core/templates
(cd blt && tar cf - .) | (cd $SHARED/git-core/templates/ && tar xf -)
cd ..
cd perl
make
make install UNINST=1
cd ..
for p in git-format-patch git-show git-whatchanged git-cherry \
git-get-tar-commit-id git-init git-repo-config git-fsck-objects \
git-cherry-pick git-peek-remote git-status git-add git-annotate \
git-apply git-archive git-blame git-branch git-bundle git-cat-file \
git-check-attr git-checkout-index git-check-ref-format git-clean \
git-commit git-commit-tree git-count-objects git-describe git-diff \
git-diff-files git-diff-index git-diff-tree git-fast-export \
git-fetch git-fetch-pack git-fetch--tool git-fmt-merge-msg \
git-for-each-ref git-fsck git-gc git-grep git-init-db git-log \
git-ls-files git-ls-tree git-ls-remote git-mailinfo git-mailsplit \
git-merge-base git-merge-file git-merge-ours git-mv git-name-rev \
git-pack-objects git-prune git-prune-packed git-push git-read-tree \
git-reflog git-send-pack git-config git-rerere git-reset \
git-rev-list git-rev-parse git-revert git-rm git-shortlog \
git-show-branch git-stripspace git-symbolic-ref git-tag git-tar-tree \
git-unpack-objects git-update-index git-update-ref \
git-upload-archive git-verify-pack git-verify-tag git-write-tree \
git-show-ref git-pack-refs ; do
rm -f $BINDIR/$p
ln $BINDIR/git $BINDIR/$p
done
-->8---
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using & porting perl 5.6.2, 5.8.x, 5.10.x on HP-UX 10.20, 11.00, 11.11,
& 11.23, SuSE 10.1 & 10.2, AIX 5.2, and Cygwin. http://qa.perl.org
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org
http://www.goldmark.org/jeff/stupid-disclaimers/
^ permalink raw reply
* [PATCH] filter-branch: Remove broken and unnecessary summary of rewritten refs.
From: Johannes Sixt @ 2007-12-18 7:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git, Johannes Sixt
There was an attempt to list the refs that were rewritten by filtering
the output of 'git show-ref' for 'refs/original'. But it got the
grep argument wrong, which did not account for the SHA1 that is listed
before the ref.
Moreover, right before this summary is the loop that actually does the
rewriting, and the rewritten refs are listed there anyway. So this extra
summary is plainly too verbose.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
git-filter-branch.sh | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 29d35fd..e730897 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -423,9 +423,6 @@ fi
cd ../..
rm -rf "$tempdir"
-echo
-test $count -gt 0 && echo "These refs were rewritten:"
-git show-ref | grep ^"$orig_namespace"
unset GIT_DIR GIT_WORK_TREE GIT_INDEX_FILE
test -z "$ORIG_GIT_DIR" || GIT_DIR="$ORIG_GIT_DIR" && export GIT_DIR
--
1.5.4.rc0.73.gcaffa
^ permalink raw reply related
* Re: [PATCH] HP-UX does not have select.h
From: H.Merijn Brand @ 2007-12-18 7:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbq8o370k.fsf@gitster.siamese.dyndns.org>
On Mon, 17 Dec 2007 21:29:31 -0800, Junio C Hamano <gitster@pobox.com> wrote:
> "H.Merijn Brand" <h.m.brand@xs4all.nl> writes:
>
> > On Mon, 17 Dec 2007 13:00:22 -0800, Junio C Hamano <gitster@pobox.com> wrote:
> >
> >> "H.Merijn Brand" <h.m.brand@xs4all.nl> writes:
> >>
> >> > HP-UX does not have select.h, but it offers all select () functionality.
> >> > The defines are in <sys/types.h> and <X11/fd.h>
> >>
> >> Will apply the patch as-is for now, only because I do not want major
> >> surgery during rc period, but I think is can be improved.
> > ...
> >> Besides, isn't _HPUX_SOURCE a feature-test macro? Feature test macros
> >
> > That is defined in GNU gcc. I did not pass it with -D...
>
> Actually I changed my mind. I won't be applying this as is.
>
> For the selective inclusion of <sys/select.h>, I would prefer it see it
> done like the attached.
So do I
> The main point is to limit the "platform" dependency to configure and
> Makefile, and keep #ifdef in the actual header files expressed in more
> generic terms (e.g. "do we need to (and can we) include sys/select.h
> here?").
>
> I am fuzzy about the uname_S part, so I won't be applying the attached
> patch either; the attached is for demonstration purposes only.
>
> diff --git a/Makefile b/Makefile
> index 617e5f5..f9f724a 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -100,6 +100,9 @@ all::
> #
> # Define NO_DEFLATE_BOUND if your zlib does not have deflateBound.
> #
> +# Define NO_SYS_SELECT_H if your C library header files do not have <sys/select.h>
> +# but you do have select(2) (pre POSIX.1-2001 systems, e.g. HP-UX before 11.23).
> +#
> # Define NO_R_TO_GCC_LINKER if your gcc does not like "-R/path/lib"
> # that tells runtime paths to dynamic libraries;
> # "-Wl,-rpath=/path/lib" is used instead.
> @@ -504,6 +507,9 @@ endif
> ifneq (,$(findstring arm,$(uname_M)))
> ARM_SHA1 = YesPlease
> endif
> +ifeq ($(uname_S),HP-UX)
> + NO_SYS_SELECT_H = YesPlease
> +endif
# uname -s
HP-UX
# uname -r
B.11.00
#
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using & porting perl 5.6.2, 5.8.x, 5.10.x on HP-UX 10.20, 11.00, 11.11,
& 11.23, SuSE 10.1 & 10.2, AIX 5.2, and Cygwin. http://qa.perl.org
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org
http://www.goldmark.org/jeff/stupid-disclaimers/
^ permalink raw reply
* Re: Question about git-svn import
From: Pascal Obry @ 2007-12-18 7:10 UTC (permalink / raw)
To: Steven Walter; +Cc: git list
In-Reply-To: <20071218034836.GA27080@dervierte>
Steven Walter a écrit :
> Not sure if this is the best way, but I would recommend cloning into two
> repositories, then combining them.
I feared that :)
> So you already have the newer
> changes with the standard layout. You would now:
>
> $ git svn init <repo>
>
> And only fetch the revisions before the layout change. You could then
> combine the two repositories using .git/info/grafts and
> git-rewrite-branch.
Hum, looks like something not easy to do (at least for a Git beginner
like me) ! Any documentation on this ? Would you mind showing this on
the example script I sent ?
Thanks,
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox