* Re: git-stash: RFC: Adopt the default behavior to other commands
From: Andreas Ericsson @ 2007-12-18 14:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Sebastian Harl, Junio C Hamano, Benoit Sigoure, git
In-Reply-To: <Pine.LNX.4.64.0712181231420.23902@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Tue, 18 Dec 2007, Sebastian Harl wrote:
>
>> 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.
>
> It's more about what you're used to. I had an alias named 'stash' long
> before it became a git command. And now guess how _annoying_ it would be
> to type "git stash<Return><Curse out loud at my mouse>git stash
> save<Return>".
>
Not nearly as annoying as losing work because of it, and you obviously
*know* what to do when you're done cursing, while clueless-newbie-X just
hops away and uses subversion.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] provide advance warning of some future pack default changes
From: Nicolas Pitre @ 2007-12-18 14:16 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, Martin Langhoff, Joel Becker, git
In-Reply-To: <200712181024.52495.jnareb@gmail.com>
On Tue, 18 Dec 2007, Jakub Narebski wrote:
> 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.
I think Git development is dynamic enough to justify 1.6.0 right after
1.5.4.
> By the way, I wonder if there would be packv4 in time for 1.6.0;
> perhaps not enabled by default.
I don't think so. First, if packv4 actually happens, it might justify
v2.0.0 and not v1.6.0.
But so far there were steady improvement made to the system even with
the current pack format, so the return on the investment for packv4 is
diminishing. The largest road block for packv4 at the moment is a
complete refactoring of the tree walking code.
Nicolas
^ permalink raw reply
* Re: [PATCH] Explain what 'ginstall' is
From: Jakub Narebski @ 2007-12-18 14:03 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: Andy Dougherty, git
In-Reply-To: <20071218143246.2437bfaf@pc09.procura.nl>
On Tue, 18 Dec 2007, H.Merijn Brand wrote:
> On Tue, 18 Dec 2007 13:32:59 +0100, Jakub Narebski <jnareb@gmail.com> wrote:
>> H.Merijn Brand wrote:
>>> On Tue, 18 Dec 2007 10:14:38 +0100, Jakub Narebski <jnareb@gmail.com> wrote:
>>>>
>>>> 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?
>
> No. I reported this before, but not to the list. This is why I created
> my own make-install shell:
I though that you were talking about _default_ 'install' program
(first in PATH). Is /opt/imake/bin/install used below?
I have forgot to tell that beside uncommenting AC_PROG_INSTALL line
in configure.ac (and doing "make configure") you have to also uncomment
the "INSTALL = @INSTALL@" in config.mak.in for "make install" to use
install program found by ./configure script.
> /pro/3gl/LINUX/git-2007-12-17 113> make install
> SUBDIR git-gui
> INDEX lib/
> SUBDIR gitk-git
> make[1]: Nothing to be done for `all'.
> SUBDIR perl
> SUBDIR templates
> install -d -m 755 '/pro/local/bin'
> rm: /pro/local/bin/ directory
> Usage: mv [-f] [-i] [-e warn|force|ignore] f1 f2
> mv [-f] [-i] [-e warn|force|ignore] f1 ... fn d1
> mv [-f] [-i] [-e warn|force|ignore] d1 d2
Strange...
By the way, I have took a look at hos ./configure script chooses which
'install' to use, and at least for GNU Autoconf 2.59 it does not talk
about HP-UX at all, and checks binaries to reject by grepping for
a string, instead of checking if it install files correctly using some
script (at least checking if it install files and creates directories,
and accepts install options used, without checking for correct permissions
and group, etc.).
Relevant fragment of generated ./configure script
-- >8 -- configure
# Find a good install program. We prefer a C program (faster),
# so one script is as good as another. But avoid the broken or
# incompatible versions:
# SysV /etc/install, /usr/sbin/install
# SunOS /usr/etc/install
# IRIX /sbin/install
# AIX /bin/install
# AmigaOS /C/install, which installs bootblocks on floppy discs
# AIX 4 /usr/bin/installbsd, which doesn't work without a -g flag
# AFS /usr/afsws/bin/install, which mishandles nonexistent args
# SVR4 /usr/ucb/install, which tries to use the nonexistent group "staff"
# OS/2's system install, which has a completely different semantic
# ./install, which can be erroneously created by make from ./install.sh.
echo "$as_me:$LINENO: checking for a BSD-compatible install" >&5
echo $ECHO_N "checking for a BSD-compatible install... $ECHO_C" >&6
if test -z "$INSTALL"; then
if test "${ac_cv_path_install+set}" = set; then
echo $ECHO_N "(cached) $ECHO_C" >&6
else
as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
for as_dir in $PATH
do
IFS=$as_save_IFS
test -z "$as_dir" && as_dir=.
# Account for people who put trailing slashes in PATH elements.
case $as_dir/ in
./ | .// | /cC/* | \
/etc/* | /usr/sbin/* | /usr/etc/* | /sbin/* | /usr/afsws/bin/* | \
?:\\/os2\\/install\\/* | ?:\\/OS2\\/INSTALL\\/* | \
/usr/ucb/* ) ;;
*)
# OSF1 and SCO ODT 3.0 have their own names for install.
# Don't use installbsd from OSF since it installs stuff as root
# by default.
for ac_prog in ginstall scoinst install; do
for ac_exec_ext in '' $ac_executable_extensions; do
if $as_executable_p "$as_dir/$ac_prog$ac_exec_ext"; then
if test $ac_prog = install &&
grep dspmsg "$as_dir/$ac_prog$ac_exec_ext" >/dev/null 2>&1; then
# AIX install. It has an incompatible calling convention.
:
elif test $ac_prog = install &&
grep pwplus "$as_dir/$ac_prog$ac_exec_ext" >/dev/null 2>&1; then
# program-specific install script used by HP pwplus--don't use.
:
else
ac_cv_path_install="$as_dir/$ac_prog$ac_exec_ext -c"
break 3
fi
fi
done
done
;;
esac
done
fi
if test "${ac_cv_path_install+set}" = set; then
INSTALL=$ac_cv_path_install
else
# As a last resort, use the slow shell script. We don't cache a
# path for INSTALL within a source directory, because that will
# break other packages using the cache if that directory is
# removed, or if the path is relative.
INSTALL=$ac_install_sh
fi
fi
echo "$as_me:$LINENO: result: $INSTALL" >&5
echo "${ECHO_T}$INSTALL" >&6
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Minor portability patch to git-submodule
From: Johannes Schindelin @ 2007-12-18 14:01 UTC (permalink / raw)
To: Andy Dougherty; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0712180734520.28219@fractal.phys.lafayette.edu>
Hi,
On Tue, 18 Dec 2007, Andy Dougherty wrote:
> On Mon, 17 Dec 2007, Johannes Schindelin wrote:
>
> > On Mon, 17 Dec 2007, Andy Dougherty wrote:
> >
> > > - git ls-files --stage -- "$@" | grep -e '^160000 ' |
> > > + git ls-files --stage -- "$@" | egrep -e '^160000 ' |
> >
> > Nack. egrep is not available on all platforms. But then I have to
> > wonder why not saying "grep '^160000 '" instead?
>
> Your last suggestion is easily and obviously better -- I'll assume you
> don't need an explicit patch and can just hand-edit mine. Still, I'd have
> thought egrep was fine. As far as I recall, it goes back to v7 Unix.
This is just another instance where we should look at existing systems
and not so much at standards documents.
> Or are there non-unix systems at issue (perhaps cygwin variants or
> something) that have grep but not egrep?
Well, I checked msysGit, and it has it.
That is, kind of: it is just a wrapper, calling "grep -E". Which means
yet another fork() on a fork() challenged platform, so I would appreciate
it if we could avoid it.
Thanks,
Dscho
^ permalink raw reply
* Re: [PATCH] HP-UX does not have select.h
From: Johannes Schindelin @ 2007-12-18 13:53 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, H.Merijn Brand, git
In-Reply-To: <4767C105.8080607@viscovery.net>
Hi,
On Tue, 18 Dec 2007, Johannes Sixt wrote:
> Johannes Schindelin schrieb:
> >
> > On Tue, 18 Dec 2007, Johannes Sixt wrote:
> >
> >> 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?
> >
> > I'd be cautious about using poll(). AFAIK MacOSX 10.2.8 does not have
> > poll(), and IIRC I had problems finding it in MinGW, too. I know, we
> > use it in daemon, upload-archive and upload-pack, but these are not
> > typically functions performed by a client, so I would not know if it
> > worked on my (now-dead) iBook, or on msysGit.
>
> So what? If we use poll() already in daemon, upload-archive and
> upload-pack, and no MacOSX 10.2.8 user has spoken up with a proposal for
> replacement, then yet another use won't raise a complaint, either.
daemon, upload-archive and upload-pack are server-side functions, so they
are substantially less well tested.
> And if it were a problem for msysGit, I wouldn't have suggested it ;)
> The particular use in pager.c would be inside #ifndef __MINGW32__ #endif
> anyway.
We still did not integrate the 'daemon' branch of 4msysgit, correct?
I'm just wary to replace a tried-and-tested select() with a poll() that I
had plenty of problems with.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] provide advance warning of some future pack default changes
From: Jakub Narebski @ 2007-12-18 13:47 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Jeff King, Junio C Hamano, Martin Langhoff, Nicolas Pitre,
Joel Becker, git
In-Reply-To: <Pine.LNX.4.64.0712181204500.23902@racer.site>
Johannes Schindelin wrote:
> On Tue, 18 Dec 2007, Jeff King wrote:
>
>> - 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.
We could do it IMVHO in two (or two an a half :-)) steps:
1. Decide where separate exec-path area should be, following FHS. Create
it during install. Install helper scripts there, moving it out of PATH.
Test those tools which use helper scripts (helper commands), which
should be _much_ easier than testing whole git for "moving dashed forms
out of path" breakage.
2. Move dashed forms out of PATH, perhaps leaving (or with option of
leaving) dashed forms of porcelain in PATH. Test all scripts and tests
;-)
I think that the first step can be done before 1.6.0, perhaps even
before 1.5.4
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Minor portability patch to git-submodule
From: Andy Dougherty @ 2007-12-18 13:35 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0712172253150.9446@racer.site>
On Mon, 17 Dec 2007, Johannes Schindelin wrote:
> On Mon, 17 Dec 2007, Andy Dougherty wrote:
>
> > - git ls-files --stage -- "$@" | grep -e '^160000 ' |
> > + git ls-files --stage -- "$@" | egrep -e '^160000 ' |
>
> Nack. egrep is not available on all platforms. But then I have to wonder
> why not saying "grep '^160000 '" instead?
Your last suggestion is easily and obviously better -- I'll assume you
don't need an explicit patch and can just hand-edit mine. Still, I'd have
thought egrep was fine. As far as I recall, it goes back to v7 Unix. Or
are there non-unix systems at issue (perhaps cygwin variants or something)
that have grep but not egrep?
Anyway, thanks.
--
Andy Dougherty doughera@lafayette.edu
^ permalink raw reply
* Re: [PATCH] Explain what 'ginstall' is
From: H.Merijn Brand @ 2007-12-18 13:32 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Andy Dougherty, git
In-Reply-To: <200712181333.01051.jnareb@gmail.com>
On Tue, 18 Dec 2007 13:32:59 +0100, Jakub Narebski <jnareb@gmail.com> wrote:
> 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?
No. I reported this before, but not to the list. This is why I created
my own make-install shell:
/pro/3gl/LINUX/git-2007-12-17 113 > make install
SUBDIR git-gui
INDEX lib/
SUBDIR gitk-git
make[1]: Nothing to be done for `all'.
SUBDIR perl
SUBDIR templates
install -d -m 755 '/pro/local/bin'
rm: /pro/local/bin/ directory
Usage: mv [-f] [-i] [-e warn|force|ignore] f1 f2
mv [-f] [-i] [-e warn|force|ignore] f1 ... fn d1
mv [-f] [-i] [-e warn|force|ignore] d1 d2
install -d -m 755 '/pro/local/bin'
rm: /pro/local/bin/ directory
Usage: mv [-f] [-i] [-e warn|force|ignore] f1 f2
mv [-f] [-i] [-e warn|force|ignore] f1 ... fn d1
mv [-f] [-i] [-e warn|force|ignore] d1 d2
install 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-help--browse 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 '/pro/local/bin'
install git '/pro/local/bin'
make -C templates DESTDIR='' install
make[1]: Entering directory `/pro/3gl/LINUX/git-2007-12-17/templates'
install -d -m 755 '/pro/local/share/git-core/templates/'
rm: /pro/local/share/git-core/templates// directory
Usage: mv [-f] [-i] [-e warn|force|ignore] f1 f2
mv [-f] [-i] [-e warn|force|ignore] f1 ... fn d1
mv [-f] [-i] [-e warn|force|ignore] d1 d2
(cd blt && tar cf - .) | \
(cd '/pro/local/share/git-core/templates/' && tar xf -)
make[1]: Leaving directory `/pro/3gl/LINUX/git-2007-12-17/templates'
make -C perl prefix='/pro/local' DESTDIR='' install
make[1]: Entering directory `/pro/3gl/LINUX/git-2007-12-17/perl'
make[2]: Entering directory `/pro/3gl/LINUX/git-2007-12-17/perl'
Writing /pro/local/lib/perl5/site_perl/5.8.8/PA-RISC2.0/auto/Git/.packlist
Appending installation info to /pro/local/lib/perl5/5.8.8/PA-RISC2.0/perllocal.pod
make[2]: Leaving directory `/pro/3gl/LINUX/git-2007-12-17/perl'
make[1]: Leaving directory `/pro/3gl/LINUX/git-2007-12-17/perl'
make -C gitk-git install
make[1]: Entering directory `/pro/3gl/LINUX/git-2007-12-17/gitk-git'
install gitk-wish '/pro/local/bin'/gitk
make[1]: Leaving directory `/pro/3gl/LINUX/git-2007-12-17/gitk-git'
make -C git-gui install
make[1]: Entering directory `/pro/3gl/LINUX/git-2007-12-17/git-gui'
INDEX lib/
DEST /pro/local/bin
rm: /pro/local/bin/ directory
Usage: mv [-f] [-i] [-e warn|force|ignore] f1 f2
mv [-f] [-i] [-e warn|force|ignore] f1 ... fn d1
mv [-f] [-i] [-e warn|force|ignore] d1 d2
INSTALL 755 git-gui
LINK git-citool -> git-gui
DEST /pro/local/share/git-gui/lib
rm: /pro/local/share/git-gui/lib/ directory
Usage: mv [-f] [-i] [-e warn|force|ignore] f1 f2
mv [-f] [-i] [-e warn|force|ignore] f1 ... fn d1
mv [-f] [-i] [-e warn|force|ignore] d1 d2
INSTALL 644 tclIndex
mv: lib/tclIndex: cannot access: No such file or directory
chmod: can't access /pro/local/share/git-gui/lib/tclIndex
INSTALL 644 git-gui.ico
mv: lib/git-gui.ico: cannot access: No such file or directory
chmod: can't access /pro/local/share/git-gui/lib/git-gui.ico
DEST /pro/local/share/git-gui/lib/msgs
rm: /pro/local/share/git-gui/lib/msgs/ directory
Usage: mv [-f] [-i] [-e warn|force|ignore] f1 f2
mv [-f] [-i] [-e warn|force|ignore] f1 ... fn d1
mv [-f] [-i] [-e warn|force|ignore] d1 d2
INSTALL 644 de.msg
INSTALL 644 hu.msg
INSTALL 644 it.msg
INSTALL 644 ja.msg
INSTALL 644 ru.msg
INSTALL 644 zh_cn.msg
make[1]: Leaving directory `/pro/3gl/LINUX/git-2007-12-17/git-gui'
if test 'z/pro/local/bin' != 'z/pro/local/bin'; \
then \
ln -f '/pro/local/bin/git' \
'/pro/local/bin/git' || \
cp '/pro/local/bin/git' \
'/pro/local/bin/git'; \
fi
rm -f '/pro/local/bin/git-format-patch' && ln '/pro/local/bin/git' '/pro/local/bin/git-format-patch' ; rm -f '/pro/local/bin/git-show' && ln '/pro/local/bin/git' '/pro/local/bin/git-show' ; rm -f '/pro/local/bin/git-whatchanged' && ln '/pro/local/bin/git' '/pro/local/bin/git-whatchanged' ; rm -f '/pro/local/bin/git-cherry' && ln '/pro/local/bin/git' '/pro/local/bin/git-cherry' ; rm -f '/pro/local/bin/git-get-tar-commit-id' && ln '/pro/local/bin/git' '/pro/local/bin/git-get-tar-commit-id' ; rm -f '/pro/local/bin/git-init' && ln '/pro/local/bin/git' '/pro/local/bin/git-init' ; rm -f '/pro/local/bin/git-repo-config' && ln '/pro/local/bin/git' '/pro/local/bin/git-repo-config' ; rm -f '/pro/local/bin/git-fsck-objects' && ln '/pro/local/bin/git' '/pro/local/bin/git-fsck-objects' ; rm -f
'/pro/local/bin/git-cherry-pick' && ln '/pro/local/bin/git' '/pro/local/bin/git-cherry-pick' ; rm -f '/pro/local/bin/git-peek-remote' && ln '/pro/local/bin/git' '/pro/local/bin/git-peek-re!
mote' ; rm -f '/pro/local/bin/git-status' && ln '/pro/local/bin/git' '/pro/local/bin/git-status' ; rm -f '/pro/local/bin/git-add' && ln '/pro/local/bin/git' '/pro/local/bin/git-add' ; rm -f '/pro/local/bin/git-annotate' && ln '/pro/local/bin/git' '/pro/local/bin/git-annotate' ; rm -f '/pro/local/bin/git-apply' && ln '/pro/local/bin/git' '/pro/local/bin/git-apply' ; rm -f '/pro/local/bin/git-archive' && ln '/pro/local/bin/git' '/pro/local/bin/git-archive' ; rm -f '/pro/local/bin/git-blame' && ln '/pro/local/bin/git' '/pro/local/bin/git-blame' ; rm -f '/pro/local/bin/git-branch' && ln '/pro/local/bin/git' '/pro/local/bin/git-branch' ; rm -f '/pro/local/bin/git-bundle' && ln '/pro/local/bin/git' '/pro/local/bin/git-bundle' ; rm -f '/pro/local/bin/git-cat-file' && ln '/pro/local/bin/
git' '/pro/local/bin/git-cat-file' ; rm -f '/pro/local/bin/git-check-attr' && ln '/pro/local/bin/git' '/pro/local/bin/git-check-attr' ; rm -f '/pro/local/bin/git-checkout-index' && ln '/p!
ro/local/bin/git' '/pro/local/bin/git-checkout-index' ; rm -f '/pro/l
ocal/bin/git-check-ref-format' && ln '/pro/local/bin/git' '/pro/local/bin/git-check-ref-format' ; rm -f '/pro/local/bin/git-clean' && ln '/pro/local/bin/git' '/pro/local/bin/git-clean' ; rm -f '/pro/local/bin/git-commit' && ln '/pro/local/bin/git' '/pro/local/bin/git-commit' ; rm -f '/pro/local/bin/git-commit-tree' && ln '/pro/local/bin/git' '/pro/local/bin/git-commit-tree' ; rm -f '/pro/local/bin/git-count-objects' && ln '/pro/local/bin/git' '/pro/local/bin/git-count-objects' ; rm -f '/pro/local/bin/git-describe' && ln '/pro/local/bin/git' '/pro/local/bin/git-describe' ; rm -f '/pro/local/bin/git-diff' && ln '/pro/local/bin/git' '/pro/local/bin/git-diff' ; rm -f '/pro/local/bin/git-diff-files' && ln '/pro/local/bin/git' '/pro/local/bin/git-diff-files' ; rm -f '/pro/local/bin/git-d
iff-index' && ln '/pro/local/bin/git' '/pro/local/bin/git-diff-index' ; rm -f '/pro/local/bin/git-diff-tree' && ln '/pro/local/bin/git' '/pro/local/bin/git-diff-tree' ; rm -f '/pro/local/!
bin/git-fast-export' && ln '/pro/local/bin/git' '/pro/local/bin/git-fast-export' ; rm -f '/pro/local/bin/git-fetch' && ln '/pro/local/bin/git' '/pro/local/bin/git-fetch' ; rm -f '/pro/local/bin/git-fetch-pack' && ln '/pro/local/bin/git' '/pro/local/bin/git-fetch-pack' ; rm -f '/pro/local/bin/git-fetch--tool' && ln '/pro/local/bin/git' '/pro/local/bin/git-fetch--tool' ; rm -f '/pro/local/bin/git-fmt-merge-msg' && ln '/pro/local/bin/git' '/pro/local/bin/git-fmt-merge-msg' ; rm -f '/pro/local/bin/git-for-each-ref' && ln '/pro/local/bin/git' '/pro/local/bin/git-for-each-ref' ; rm -f '/pro/local/bin/git-fsck' && ln '/pro/local/bin/git' '/pro/local/bin/git-fsck' ; rm -f '/pro/local/bin/git-gc' && ln '/pro/local/bin/git' '/pro/local/bin/git-gc' ; rm -f '/pro/local/bin/git-grep' && ln '/p
ro/local/bin/git' '/pro/local/bin/git-grep' ; rm -f '/pro/local/bin/git-init-db' && ln '/pro/local/bin/git' '/pro/local/bin/git-init-db' ; rm -f '/pro/local/bin/git-log' && ln '/pro/local!
/bin/git' '/pro/local/bin/git-log' ; rm -f '/pro/local/bin/git-ls-fil
es' && ln '/pro/local/bin/git' '/pro/local/bin/git-ls-files' ; rm -f '/pro/local/bin/git-ls-tree' && ln '/pro/local/bin/git' '/pro/local/bin/git-ls-tree' ; rm -f '/pro/local/bin/git-ls-remote' && ln '/pro/local/bin/git' '/pro/local/bin/git-ls-remote' ; rm -f '/pro/local/bin/git-mailinfo' && ln '/pro/local/bin/git' '/pro/local/bin/git-mailinfo' ; rm -f '/pro/local/bin/git-mailsplit' && ln '/pro/local/bin/git' '/pro/local/bin/git-mailsplit' ; rm -f '/pro/local/bin/git-merge-base' && ln '/pro/local/bin/git' '/pro/local/bin/git-merge-base' ; rm -f '/pro/local/bin/git-merge-file' && ln '/pro/local/bin/git' '/pro/local/bin/git-merge-file' ; rm -f '/pro/local/bin/git-merge-ours' && ln '/pro/local/bin/git' '/pro/local/bin/git-merge-ours' ; rm -f '/pro/local/bin/git-mv' && ln '/pro/local/bi
n/git' '/pro/local/bin/git-mv' ; rm -f '/pro/local/bin/git-name-rev' && ln '/pro/local/bin/git' '/pro/local/bin/git-name-rev' ; rm -f '/pro/local/bin/git-pack-objects' && ln '/pro/local/b!
in/git' '/pro/local/bin/git-pack-objects' ; rm -f '/pro/local/bin/git-prune' && ln '/pro/local/bin/git' '/pro/local/bin/git-prune' ; rm -f '/pro/local/bin/git-prune-packed' && ln '/pro/local/bin/git' '/pro/local/bin/git-prune-packed' ; rm -f '/pro/local/bin/git-push' && ln '/pro/local/bin/git' '/pro/local/bin/git-push' ; rm -f '/pro/local/bin/git-read-tree' && ln '/pro/local/bin/git' '/pro/local/bin/git-read-tree' ; rm -f '/pro/local/bin/git-reflog' && ln '/pro/local/bin/git' '/pro/local/bin/git-reflog' ; rm -f '/pro/local/bin/git-send-pack' && ln '/pro/local/bin/git' '/pro/local/bin/git-send-pack' ; rm -f '/pro/local/bin/git-config' && ln '/pro/local/bin/git' '/pro/local/bin/git-config' ; rm -f '/pro/local/bin/git-rerere' && ln '/pro/local/bin/git' '/pro/local/bin/git-rerere' ;
rm -f '/pro/local/bin/git-reset' && ln '/pro/local/bin/git' '/pro/local/bin/git-reset' ; rm -f '/pro/local/bin/git-rev-list' && ln '/pro/local/bin/git' '/pro/local/bin/git-rev-list' ; rm !
-f '/pro/local/bin/git-rev-parse' && ln '/pro/local/bin/git' '/pro/loc
al/bin/git-rev-parse' ; rm -f '/pro/local/bin/git-revert' && ln '/pro/local/bin/git' '/pro/local/bin/git-revert' ; rm -f '/pro/local/bin/git-rm' && ln '/pro/local/bin/git' '/pro/local/bin/git-rm' ; rm -f '/pro/local/bin/git-shortlog' && ln '/pro/local/bin/git' '/pro/local/bin/git-shortlog' ; rm -f '/pro/local/bin/git-show-branch' && ln '/pro/local/bin/git' '/pro/local/bin/git-show-branch' ; rm -f '/pro/local/bin/git-stripspace' && ln '/pro/local/bin/git' '/pro/local/bin/git-stripspace' ; rm -f '/pro/local/bin/git-symbolic-ref' && ln '/pro/local/bin/git' '/pro/local/bin/git-symbolic-ref' ; rm -f '/pro/local/bin/git-tag' && ln '/pro/local/bin/git' '/pro/local/bin/git-tag' ; rm -f '/pro/local/bin/git-tar-tree' && ln '/pro/local/bin/git' '/pro/local/bin/git-tar-tree' ; rm -f '/pro/loc
al/bin/git-unpack-objects' && ln '/pro/local/bin/git' '/pro/local/bin/git-unpack-objects' ; rm -f '/pro/local/bin/git-update-index' && ln '/pro/local/bin/git' '/pro/local/bin/git-update-in!
dex' ; rm -f '/pro/local/bin/git-update-ref' && ln '/pro/local/bin/git' '/pro/local/bin/git-update-ref' ; rm -f '/pro/local/bin/git-upload-archive' && ln '/pro/local/bin/git' '/pro/local/bin/git-upload-archive' ; rm -f '/pro/local/bin/git-verify-pack' && ln '/pro/local/bin/git' '/pro/local/bin/git-verify-pack' ; rm -f '/pro/local/bin/git-verify-tag' && ln '/pro/local/bin/git' '/pro/local/bin/git-verify-tag' ; rm -f '/pro/local/bin/git-write-tree' && ln '/pro/local/bin/git' '/pro/local/bin/git-write-tree' ; rm -f '/pro/local/bin/git-show-ref' && ln '/pro/local/bin/git' '/pro/local/bin/git-show-ref' ; rm -f '/pro/local/bin/git-pack-refs' && ln '/pro/local/bin/git' '/pro/local/bin/git-pack-refs' ;
--
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: Johannes Schindelin @ 2007-12-18 13:30 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Martin Langhoff, Nicolas Pitre, Joel Becker,
Jakub Narebski, git
In-Reply-To: <20071218124808.GA3728@sigill.intra.peff.net>
Hi,
On Tue, 18 Dec 2007, Jeff King wrote:
> On Tue, Dec 18, 2007 at 12:06:23PM +0000, Johannes Schindelin wrote:
>
> > > - 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.
>
> Yes, it should be, but I think there will be a few user-visible fallouts
> (like "--abbrev $foo" in scripts should now be "--abbrev-default $foo"
> for safety).
But we are on our way to fix this, no? IOW this warrants not a version
bump, but an extended feature freeze/bug fix period (like Junio suggested,
until January).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] provide advance warning of some future pack default changes
From: Jeff King @ 2007-12-18 12:48 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Martin Langhoff, Nicolas Pitre, Joel Becker,
Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0712181204500.23902@racer.site>
On Tue, Dec 18, 2007 at 12:06:23PM +0000, Johannes Schindelin wrote:
> > - 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.
Yes, it should be, but I think there will be a few user-visible fallouts
(like "--abbrev $foo" in scripts should now be "--abbrev-default $foo"
for safety).
-Peff
^ permalink raw reply
* Re: [PATCH] HP-UX does not have select.h
From: Johannes Sixt @ 2007-12-18 12:45 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, H.Merijn Brand, git
In-Reply-To: <Pine.LNX.4.64.0712181234520.23902@racer.site>
Johannes Schindelin schrieb:
> Hi,
>
> On Tue, 18 Dec 2007, Johannes Sixt wrote:
>
>> 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?
>
> I'd be cautious about using poll(). AFAIK MacOSX 10.2.8 does not have
> poll(), and IIRC I had problems finding it in MinGW, too. I know, we use
> it in daemon, upload-archive and upload-pack, but these are not typically
> functions performed by a client, so I would not know if it worked on my
> (now-dead) iBook, or on msysGit.
So what? If we use poll() already in daemon, upload-archive and
upload-pack, and no MacOSX 10.2.8 user has spoken up with a proposal for
replacement, then yet another use won't raise a complaint, either.
And if it were a problem for msysGit, I wouldn't have suggested it ;) The
particular use in pager.c would be inside #ifndef __MINGW32__ #endif anyway.
-- Hannes
^ permalink raw reply
* Re: [PATCH] HP-UX does not have select.h
From: Johannes Schindelin @ 2007-12-18 12:38 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, H.Merijn Brand, git
In-Reply-To: <476781C6.6050507@viscovery.net>
Hi,
On Tue, 18 Dec 2007, Johannes Sixt wrote:
> 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?
I'd be cautious about using poll(). AFAIK MacOSX 10.2.8 does not have
poll(), and IIRC I had problems finding it in MinGW, too. I know, we use
it in daemon, upload-archive and upload-pack, but these are not typically
functions performed by a client, so I would not know if it worked on my
(now-dead) iBook, or on msysGit.
Ciao,
Dscho
^ permalink raw reply
* preventing a push
From: Christoph Duelli @ 2007-12-18 12:32 UTC (permalink / raw)
To: git
Is there a (recommended?) way to prevent accidental pushing (or pulling)
from one repository into another (like the level command from bk days)?
Best regards
Christoph
^ permalink raw reply
* Re: git-stash: RFC: Adopt the default behavior to other commands
From: Johannes Schindelin @ 2007-12-18 12:33 UTC (permalink / raw)
To: Sebastian Harl; +Cc: Junio C Hamano, Benoit Sigoure, git
In-Reply-To: <20071218105941.GA17251@albany.tokkee.org>
Hi,
On Tue, 18 Dec 2007, Sebastian Harl wrote:
> 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.
It's more about what you're used to. I had an alias named 'stash' long
before it became a git command. And now guess how _annoying_ it would be
to type "git stash<Return><Curse out loud at my mouse>git stash
save<Return>".
As you see, it is more than five characters more.
Ciao,
Dscho
^ 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
* 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] 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: [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] 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] 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] 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] 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] 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: 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] 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
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