* 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: 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: [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: [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: 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] 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: [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
* [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] 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
* 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
* [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
* [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
* 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
* 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] 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: git-stash: RFC: Adopt the default behavior to other commands
From: Sebastian Harl @ 2007-12-18 10:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Benoit Sigoure, git
In-Reply-To: <7vfxy04ze7.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1248 bytes --]
Hi,
On Mon, Dec 17, 2007 at 04:31:12PM -0800, Junio C Hamano wrote:
> But the original point by Sebastian hasn't been answered. He wanted to
> make the command list the stash without arguments.
>
> This was discussed already in the early days of stash and there indeed
> was a suggestion to do so (I think I sided with that), but the users did
> not want it. IIRC, the argument went like: "when I say 'stash', that is
> because I want a quick and immediate way to stash, and I do not want a
> list. If I do not have to have a quick way, I would create a temporary
> commit on the current branch, or switch to a temporary branch and commit
> there."
Well, "git stash save" is just five characters more - I really don't see why
this would be less comfortable (and for the really lazy people there are still
aliases...). On the other hand (if "list" is the default), we'd get a more
consistent interface which imho is imho more important than typing five
characters less.
Cheers,
Sebastian
--
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/
Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Explain what 'ginstall' is
From: H.Merijn Brand @ 2007-12-18 11:11 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Andy Dougherty, git
In-Reply-To: <200712181014.38986.jnareb@gmail.com>
On Tue, 18 Dec 2007 10:14:38 +0100, Jakub Narebski <jnareb@gmail.com> wrote:
> 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?
/pro/3gl/LINUX/git-2007-12-17 112 > rm config.{log,status}
/pro/3gl/LINUX/git-2007-12-17 113 > configure --prefix=/pro/local --disable-nls --without-iconv --with-perl=/pro/bin/perl >& config-log
/pro/3gl/LINUX/git-2007-12-17 114 > grep -w install !$
grep -w install config-log
Exit 1
/pro/3gl/LINUX/git-2007-12-17 115 >
The system could have used either one of these:
/pro/3gl/LINUX/git-2007-12-17 116 > ll /pro/local/share/automa*/install-sh
258090 -rwxr-xr-x 1 merijn softwr 9212 Sep 2 2004 /pro/local/share/automake-1.9/install-sh
77938 -rwxr-xr-x 1 merijn softwr 5598 Oct 4 2001 /pro/local/share/automake/install-sh
/pro/3gl/LINUX/git-2007-12-17 119 > cp /pro/3gl/GNU/gcc/r3/gcc-4.2.2/install-sh install-sh
/pro/3gl/LINUX/git-2007-12-17 120 > rm config.{log,status}
/pro/3gl/LINUX/git-2007-12-17 121 > configure --prefix=/pro/local --disable-nls --without-iconv --with-perl=/pro/bin/perl > & config-log
/pro/3gl/LINUX/git-2007-12-17 122 > grep -w install config-log
Exit 1
/pro/3gl/LINUX/git-2007-12-17 123 > ll install-sh
121737 -rwxrwxr-x 1 merijn softwr 9233 Dec 18 12:06 install-sh
/pro/3gl/LINUX/git-2007-12-17 124 >
-- uncommented the AC_PROG_INSTALL line ...
a5:/pro/3gl/LINUX/git-2007-12-17 125 > rm config.{log,status}
a5:/pro/3gl/LINUX/git-2007-12-17 126 > configure --prefix=/pro/local --disable-nls --without-iconv --with-perl=/pro/bin/perl > & config-log
a5:/pro/3gl/LINUX/git-2007-12-17 127 > grep -w install config-log
Exit 1
a5:/pro/3gl/LINUX/git-2007-12-17 128 > grep -w install config.log config.status
Exit 1
a5:/pro/3gl/LINUX/git-2007-12-17 129 >
OK, rebuild configure ...
a5:/pro/3gl/LINUX/git-2007-12-17 129 > make configure
GEN configure
a5:/pro/3gl/LINUX/git-2007-12-17 130 > rm config.{log,status}
a5:/pro/3gl/LINUX/git-2007-12-17 131 > configure --prefix=/pro/local --disable-nls --without-iconv --with-perl=/pro/bin/perl > & config-log
a5:/pro/3gl/LINUX/git-2007-12-17 132 > grep -w install config-log config.log config.status
config-log:checking for a BSD-compatible install... /opt/imake/bin/install -c
config.log:configure:2218: checking for a BSD-compatible install
config.log:configure:2273: result: /opt/imake/bin/install -c
config.log:ac_cv_path_install='/opt/imake/bin/install -c'
config.status:INSTALL="/opt/imake/bin/install -c"
a5:/pro/3gl/LINUX/git-2007-12-17 133 >
> 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)).
--
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] provide advance warning of some future pack default changes
From: Jeff King @ 2007-12-18 11:11 UTC (permalink / raw)
To: Junio C Hamano
Cc: Martin Langhoff, Nicolas Pitre, Joel Becker, Jakub Narebski, git
In-Reply-To: <7vlk7s38aq.fsf@gitster.siamese.dyndns.org>
On Mon, Dec 17, 2007 at 09:01:49PM -0800, Junio C Hamano wrote:
> 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.
I can think of two other user-visible changes which have been discussed
that might warrant such a version bump:
- option parsing tweaks (hopefully these should be minor, but it is
clear that we cannot be 100% consistent while retaining the
identical previous behavior)
- moving dashed forms out of paths
-Peff
^ permalink raw reply
* Re: [PATCH] Fix segfault in diff-delta.c when FLEX_ARRAY is 1
From: David Kastrup @ 2007-12-18 11:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Pierre Habouzit, spearce, Git Mailing List
In-Reply-To: <7vwsrc1idm.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
>> - diff-delta.c:250 memsize = sizeof(*index)
>
> I haven't studied this codepath.
My proposed patch should have addressed this as well.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [PATCH] filter-branch: Remove broken and unnecessary summary of rewritten refs.
From: Johannes Sixt @ 2007-12-18 11:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vejdk1g3h.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> Sounds sensible. Applied.
It seems lately I can't get a thing right on the first try. Would you please
squash this in as long as you haven't pushed out the commit? $count is
now unused.
Thank you!
--- >8 ---
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index e730897..f8bdc14 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -342,7 +342,6 @@ done < "$tempdir"/heads
_x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
_x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40"
-count=0
echo
while read ref
do
@@ -380,7 +379,6 @@ do
;;
esac
git update-ref -m "filter-branch: backup" "$orig_namespace$ref" $sha1
- count=$(($count+1))
done < "$tempdir"/heads
# TODO: This should possibly go, with the semantics that all positive given
^ permalink raw reply related
* Re: [PATCH] provide advance warning of some future pack default changes
From: Johannes Schindelin @ 2007-12-18 12:03 UTC (permalink / raw)
To: Jakub Narebski
Cc: Junio C Hamano, Martin Langhoff, Nicolas Pitre, Joel Becker, git
In-Reply-To: <200712181024.52495.jnareb@gmail.com>
Hi,
On Tue, 18 Dec 2007, Jakub Narebski wrote:
> By the way, I wonder if there would be packv4 in time for 1.6.0; perhaps
> not enabled by default.
Sure! If someone undertakes the massive amount of work it takes to bring
packv4 off!
But if that is done, I do not see why it should be off by default.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] provide advance warning of some future pack default changes
From: Johannes Schindelin @ 2007-12-18 12:06 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Martin Langhoff, Nicolas Pitre, Joel Becker,
Jakub Narebski, git
In-Reply-To: <20071218111136.GA6266@coredump.intra.peff.net>
Hi,
On Tue, 18 Dec 2007, Jeff King wrote:
> On Mon, Dec 17, 2007 at 09:01:49PM -0800, Junio C Hamano wrote:
>
> > 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.
>
> I can think of two other user-visible changes which have been discussed
> that might warrant such a version bump:
>
> - option parsing tweaks (hopefully these should be minor, but it is
> clear that we cannot be 100% consistent while retaining the
> identical previous behavior)
IMHO this does not warrant a version bump. It should be mostly
behind-the-scenes, after all.
> - moving dashed forms out of paths
Playing it safe, and waiting with this after announcing it more obviously,
is something that I appreciate. Too many scripts can break, and I am sure
quite a few of mine will; I simply do not have the time right now to audit
them.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Fix some documentation typos.
From: Ralf Wildenhues @ 2007-12-18 12:12 UTC (permalink / raw)
To: git
In-Reply-To: <20071218060736.GA24024@ins.uni-bonn.de>
Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
---
Found some more. If you haven't pushed yet, please squash this in with
the other patch, thanks.
Cheers,
Ralf
Documentation/git-help.txt | 2 +-
Documentation/git-init.txt | 2 +-
Documentation/git.txt | 4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-help.txt b/Documentation/git-help.txt
index c370ee9..a8ffcbe 100644
--- a/Documentation/git-help.txt
+++ b/Documentation/git-help.txt
@@ -72,7 +72,7 @@ line option:
* "web" or "html" correspond to '-w|--web',
The 'help.browser', 'web.browser' and 'browser.<tool>.path' will also
-be checked if the 'web' format is choosen (either by command line
+be checked if the 'web' format is chosen (either by command line
option or configuration variable). See '-w|--web' in the OPTIONS
section above.
diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt
index 07484a4..e51351d 100644
--- a/Documentation/git-init.txt
+++ b/Documentation/git-init.txt
@@ -52,7 +52,7 @@ is given:
- 'all' (or 'world' or 'everybody'): Same as 'group', but make the repository
readable by all users.
-By default, the configuration flag receive.denyNonFastforward is enabled
+By default, the configuration flag receive.denyNonFastForwards is enabled
in shared repositories, so that you cannot force a non fast-forwarding push
into it.
diff --git a/Documentation/git.txt b/Documentation/git.txt
index e0f9a44..37235b9 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -502,7 +502,7 @@ as tags and branch heads.
The object database contains objects of three main types: blobs, which
hold file data; trees, which point to blobs and other trees to build up
-directory heirarchies; and commits, which each reference a single tree
+directory hierarchies; and commits, which each reference a single tree
and some number of parent commits.
The commit, equivalent to what other systems call a "changeset" or
@@ -522,7 +522,7 @@ efficiency may later be compressed together into "pack files".
Named pointers called refs mark interesting points in history. A ref
may contain the SHA1 name of an object or the name of another ref. Refs
with names beginning `ref/head/` contain the SHA1 name of the most
-recent commit (or "head") of a branch under developement. SHA1 names of
+recent commit (or "head") of a branch under development. SHA1 names of
tags of interest are stored under `ref/tags/`. A special ref named
`HEAD` contains the name of the currently checked-out branch.
--
1.5.4.rc0.56.g6fbe
^ permalink raw reply related
* Re: git-clone: Unobvious error messages when update-server-info has not been run
From: Gerrit Pape @ 2007-12-18 12:23 UTC (permalink / raw)
To: Jeff King; +Cc: Sebastian Harl, Junio C Hamano, git
In-Reply-To: <20071217124359.GA20800@coredump.intra.peff.net>
On Mon, Dec 17, 2007 at 07:43:59AM -0500, Jeff King wrote:
> git-clone is supposed to detect this condition, but there was a bug in
> the error checking code. Can you confirm that this patch fixes it?
>
> Gerrit, I think was caused by your f28dd477 (it is a funny shell
> interaction that the non-followed case branch resets $?, but it behaves
> the same with bash and dash).
Yes, I didn't expect that, but can confirm the problem and the fix.
Thanks, Gerrit.
^ permalink raw reply
* Re: [PATCH] Explain what 'ginstall' is
From: Jakub Narebski @ 2007-12-18 12:32 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: Andy Dougherty, git
In-Reply-To: <20071218121115.1c893dc4@pc09.procura.nl>
H.Merijn Brand wrote:
> On Tue, 18 Dec 2007 10:14:38 +0100, Jakub Narebski <jnareb@gmail.com> wrote:
>> 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?
> /pro/3gl/LINUX/git-2007-12-17 119> cp /pro/3gl/GNU/gcc/r3/gcc-4.2.2/install-sh install-sh
> -- uncommented the AC_PROG_INSTALL line ...
> OK, rebuild configure ...
>
> a5:/pro/3gl/LINUX/git-2007-12-17 129> make configure
> GEN configure
> a5:/pro/3gl/LINUX/git-2007-12-17 130> rm config.{log,status}
> a5:/pro/3gl/LINUX/git-2007-12-17 131> configure --prefix=/pro/local --disable-nls --without-iconv --with-perl=/pro/bin/perl> & config-log
> a5:/pro/3gl/LINUX/git-2007-12-17 132> grep -w install config-log config.log config.status
> config-log:checking for a BSD-compatible install... /opt/imake/bin/install -c
> config.log:configure:2218: checking for a BSD-compatible install
> config.log:configure:2273: result: /opt/imake/bin/install -c
> config.log:ac_cv_path_install='/opt/imake/bin/install -c'
> config.status:INSTALL="/opt/imake/bin/install -c"
Does chosen by ./configure script 'install' binary, namely
/opt/imake/bin/install works correctly, meaning does it install
git correctly?
--
Jakub Narebski
Poland
^ 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