* 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-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
* 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: [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
* 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] 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] 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] 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] 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] 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] 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] 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] 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] 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: 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] HP-UX does not have select.h
From: Johannes Sixt @ 2007-12-18 14:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, H.Merijn Brand, git
In-Reply-To: <Pine.LNX.4.64.0712181351270.23902@racer.site>
Johannes Schindelin schrieb:
> On Tue, 18 Dec 2007, Johannes Sixt wrote:
>> Johannes Schindelin schrieb:
>>> 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.
upload-pack is used for local fetches and, therefore, should be
well-tested on all systems.
>> 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?
No, we didn't.
-- Hannes
^ permalink raw reply
* Re: [PATCH] Don't cache DESTDIR in perl/perl.mak.
From: Gerrit Pape @ 2007-12-18 14:25 UTC (permalink / raw)
To: Pierre Habouzit, Eric Wong, Junio C Hamano, git
In-Reply-To: <20071212200211.GB1060@artemis.madism.org>
On Wed, Dec 12, 2007 at 09:02:11PM +0100, Pierre Habouzit wrote:
> On Wed, Dec 12, 2007 at 06:01:48PM +0000, Eric Wong wrote:
> > Junio C Hamano <gitster@pobox.com> wrote:
> > > Hmph. That's reverting this:
> > >
> > > commit 4c5cf8c44ce06a79da5bafd4a92e6d6f598cea2e
> > > Eric, care to comment?
> >
> > I used to make a statically linked binary package for working on an
> > ancient box that didn't have a lot of libraries I wanted, and I probably
> > just called `make install' into DESTDIR as a single step without calling
> > `make' alone without DESTDIR argument, or I had DESTDIR set in
> > config.mak
>
> Actually this fact generated a bug in debian packaging because git is
> built then installed twice in different DESTDIRS, then parts of the
> install is pruned (the two installs are arch-dependant and
> arch-independant files install so it's a very good reason in term of
> packaging).
>
> The fact that perl.mak caches the DESTDIR make it install things in
> the wrong place because it doesn't honour make DESTDIR=foo install and
> always use the cached value instead, which is wrong.
>
> I think Gerrit won't care if it's cached or not, he just cares that it
> still honours environment if present.
Yes, precisely. Thanks, Gerrit.
^ permalink raw reply
* Re: [PATCH] Explain what 'ginstall' is
From: H.Merijn Brand @ 2007-12-18 14:27 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Andy Dougherty, git
In-Reply-To: <200712181503.10614.jnareb@gmail.com>
On Tue, 18 Dec 2007 15:03:09 +0100, Jakub Narebski <jnareb@gmail.com> wrote:
> 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?
Yes. There is only ONE install program
(that is a small lie, there is also /usr/sbin/install, but that is not
accessible for mortal users)
> 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.
But I don't think it found install-sh.
/pro/3gl/LINUX/git-2007-12-17 103 > grep -w install config-log
checking for a BSD-compatible install... /opt/imake/bin/install -c
> > /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
http://www.xs4all.nl/~procura/configure
added a 'set -x' there:
configure: CHECKS for programs
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
+ echo configure:2219: checking for a BSD-compatible install
+ 1>& 5
+ echo checking for a BSD-compatible install... \c
+ 1>& 6
checking for a BSD-compatible install... + test -z
+ test = set
+ as_save_IFS=
+ IFS=:
+ IFS=
+ test -z .
+ IFS=
+ test -z /u/usr/merijn/bin/private
+ test -f /u/usr/merijn/bin/private/ginstall
+ test -f /u/usr/merijn/bin/private/scoinst
+ test -f /u/usr/merijn/bin/private/install
+ IFS=
etc etc for the rest of the $PATH ...
+ test -z /opt/imake/bin
+ test -f /opt/imake/bin/ginstall
+ test -f /opt/imake/bin/scoinst
+ test -f /opt/imake/bin/install
+ test install = install
+ grep dspmsg /opt/imake/bin/install
+ 1> /dev/null 2>& 1
+ test install = install
+ grep pwplus /opt/imake/bin/install
+ 1> /dev/null 2>& 1
+ ac_cv_path_install=/opt/imake/bin/install -c
+ break 3
+ test set = set
+ INSTALL=/opt/imake/bin/install -c
+ echo configure:2274: result: /opt/imake/bin/install -c
+ 1>& 5
+ echo /opt/imake/bin/install -c
+ 1>& 6
/opt/imake/bin/install -c
+ exit
+ exit_status=0
+ 1>& 5
+ echo
+ cat
+ 0< /var/tmp/sh8180.20
+ echo
+ 2>& 1
+ 2>& 1
+ sed -n s/'/'\\''/g;
s/^\([_abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789]*_cv_[_abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789]*\)=\(.*\)/\1='\2'/p
+ echo
+ cat
+ 0< /var/tmp/sh8180.21
+ echo
+ sort
+ echo SHELL
+ eval ac_val=$SHELL
:
:
+ ac_val=o
+ echo OBJEXT='o'
+ echo INSTALL_PROGRAM
+ eval ac_val=$INSTALL_PROGRAM
+ ac_val=
+ echo INSTALL_PROGRAM=''
+ echo INSTALL_SCRIPT
+ eval ac_val=$INSTALL_SCRIPT
+ ac_val=
+ echo INSTALL_SCRIPT=''
+ echo INSTALL_DATA
+ eval ac_val=$INSTALL_DATA
+ ac_val=
+ echo INSTALL_DATA=''
+ echo AR
+ eval ac_val=$AR
:
:
+ echo
+ test -n
+ test -s confdefs.h
+ cat
+ 0< /var/tmp/sh8180.23
+ echo
+ sed /^$/d confdefs.h
+ sort
+ echo
+ test 0 != 0
+ echo configure: exit 0
+ rm -f core *.core
+ rm -rf conftest* confdefs.h conf8180*
> -- >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
>
--
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] Fix segfault in diff-delta.c when FLEX_ARRAY is 1
From: Nicolas Pitre @ 2007-12-18 14:46 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>
On Tue, 18 Dec 2007, Junio C Hamano wrote:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
> > But there's a few that aren't obviously allocations (this is a list done
> > with grep and sparse, I didn't look at whether the values used are then
> > all allocation-related):
> >
> > - diff-delta.c:250 memsize = sizeof(*index)
>
> I haven't studied this codepath.
Harmless overallocation. Nothing to worry about.
Nicolas
^ permalink raw reply
* Re: git-stash: RFC: Adopt the default behavior to other commands
From: Johannes Schindelin @ 2007-12-18 14:47 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Sebastian Harl, Junio C Hamano, Benoit Sigoure, git
In-Reply-To: <4767D7A2.30703@op5.se>
Hi,
On Tue, 18 Dec 2007, Andreas Ericsson wrote:
> Johannes Schindelin wrote:
>
> > 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.
Really? Clueless-newbie-X certainly knows how to apply the stash,
otherwise she would not have used the command, right?
In the alternative, you could just scrap all those default actions,
showing synopses instead. For all commands, including "git commit", "git
log", "git fetch", etc.
See?
Ciao,
Dscho
^ permalink raw reply
* Re: git-stash: RFC: Adopt the default behavior to other commands
From: Andreas Ericsson @ 2007-12-18 15:00 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Sebastian Harl, Junio C Hamano, Benoit Sigoure, git
In-Reply-To: <Pine.LNX.4.64.0712181445420.23902@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Tue, 18 Dec 2007, Andreas Ericsson wrote:
>
>> Johannes Schindelin wrote:
>>
>>> 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.
>
> Really? Clueless-newbie-X certainly knows how to apply the stash,
> otherwise she would not have used the command, right?
>
Far too many times I've seen people expect help output if the command
they're running is even remotely dangerous, so they go ahead and run
it without arguments to see what it does.
> In the alternative, you could just scrap all those default actions,
> showing synopses instead. For all commands, including "git commit", "git
> log", "git fetch", etc.
>
Like we do for the git wrapper, you mean? Yes, that would be one solution,
although not a very good one for all commands.
It's probably not a bad idea for commands where the primary use is
something else than producing visual output though, such as tag or branch,
but those handle creation/deletion of stuff, so the default action for them
is to list stuff of the kind they operate on. I fail to see why stash should
be any different.
> See?
>
Not really, no. What was your point?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [PATCH] Fix test failure due to broken sed on Leopard
From: Wincent Colaiuta @ 2007-12-18 15:11 UTC (permalink / raw)
To: git; +Cc: gitster, Wincent Colaiuta
The newly-added common-tail-optimization test fails on Leopard because
the broken sed implementation bails with a spurious "unterminated
substitute pattern" error because of the length of one of the
arguments.
So halve the size of the argument (to 1024 - 1, down from the previous
2048 - 1) to get the test passing again.
Signed-off-by: Wincent Colaiuta <win@wincent.com>
---
t/t4024-diff-optimize-common.sh | 22 +++++++++++-----------
1 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/t/t4024-diff-optimize-common.sh b/t/t4024-diff-optimize-common.sh
index 20fe87b..bbda816 100755
--- a/t/t4024-diff-optimize-common.sh
+++ b/t/t4024-diff-optimize-common.sh
@@ -7,26 +7,26 @@ test_description='common tail optimization'
z=zzzzzzzz ;# 8
z="$z$z$z$z$z$z$z$z" ;# 64
z="$z$z$z$z$z$z$z$z" ;# 512
-z="$z$z$z$z" ;# 2048
-z2047=$(expr "$z" : '.\(.*\)') ; #2047
+z="$z$z" ;# 1024
+z1023=$(expr "$z" : '.\(.*\)') ; #1023
test_expect_success setup '
- echo "a$z2047" >file-a &&
+ echo "a$z1023" >file-a &&
echo "b" >file-b &&
- echo "$z2047" >>file-b &&
- echo "c$z2047" | tr -d "\012" >file-c &&
+ echo "$z1023" >>file-b &&
+ echo "c$z1023" | tr -d "\012" >file-c &&
echo "d" >file-d &&
- echo "$z2047" | tr -d "\012" >>file-d &&
+ echo "$z1023" | tr -d "\012" >>file-d &&
git add file-a file-b file-c file-d &&
- echo "A$z2047" >file-a &&
+ echo "A$z1023" >file-a &&
echo "B" >file-b &&
- echo "$z2047" >>file-b &&
- echo "C$z2047" | tr -d "\012" >file-c &&
+ echo "$z1023" >>file-b &&
+ echo "C$z1023" | tr -d "\012" >file-c &&
echo "D" >file-d &&
- echo "$z2047" | tr -d "\012" >>file-d
+ echo "$z1023" | tr -d "\012" >>file-d
'
@@ -61,7 +61,7 @@ EOF
test_expect_success 'diff -U0' '
- git diff -U0 | sed -e "/^index/d" -e "s/$z2047/Z/g" >actual &&
+ git diff -U0 | sed -e "/^index/d" -e "s/$z1023/Z/g" >actual &&
diff -u expect actual
'
--
1.5.4.rc0.1099.g76fa0-dirty
^ permalink raw reply related
* [PATCH] fix style of a few comments in diff-delta.c
From: Nicolas Pitre @ 2007-12-18 15:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
diff --git a/diff-delta.c b/diff-delta.c
index 601b49e..a4e28df 100644
--- a/diff-delta.c
+++ b/diff-delta.c
@@ -212,11 +212,24 @@ struct delta_index * create_delta_index(const void *buf, unsigned long bufsize)
if (hash_count[i] <= HASH_LIMIT)
continue;
- entries -= hash_count[i] - HASH_LIMIT;
/* We leave exactly HASH_LIMIT entries in the bucket */
+ entries -= hash_count[i] - HASH_LIMIT;
entry = hash[i];
acc = 0;
+
+ /*
+ * Assume that this loop is gone through exactly
+ * HASH_LIMIT times and is entered and left with
+ * acc==0. So the first statement in the loop
+ * contributes (hash_count[i]-HASH_LIMIT)*HASH_LIMIT
+ * to the accumulator, and the inner loop consequently
+ * is run (hash_count[i]-HASH_LIMIT) times, removing
+ * one element from the list each time. Since acc
+ * balances out to 0 at the final run, the inner loop
+ * body can't be left with entry==NULL. So we indeed
+ * encounter entry==NULL in the outer loop only.
+ */
do {
acc += hash_count[i] - HASH_LIMIT;
if (acc > 0) {
@@ -229,30 +242,17 @@ struct delta_index * create_delta_index(const void *buf, unsigned long bufsize)
}
entry = entry->next;
} while (entry);
-
- /* Assume that this loop is gone through exactly
- * HASH_LIMIT times and is entered and left with
- * acc==0. So the first statement in the loop
- * contributes (hash_count[i]-HASH_LIMIT)*HASH_LIMIT
- * to the accumulator, and the inner loop consequently
- * is run (hash_count[i]-HASH_LIMIT) times, removing
- * one element from the list each time. Since acc
- * balances out to 0 at the final run, the inner loop
- * body can't be left with entry==NULL. So we indeed
- * encounter entry==NULL in the outer loop only.
- */
}
free(hash_count);
- /* Now create the packed index in array form rather than
- * linked lists */
-
+ /*
+ * Now create the packed index in array form
+ * rather than linked lists.
+ */
memsize = sizeof(*index)
+ sizeof(*packed_hash) * (hsize+1)
+ sizeof(*packed_entry) * entries;
-
mem = malloc(memsize);
-
if (!mem) {
free(hash);
return NULL;
@@ -269,19 +269,19 @@ struct delta_index * create_delta_index(const void *buf, unsigned long bufsize)
mem = packed_hash + (hsize+1);
packed_entry = mem;
- /* Coalesce all entries belonging to one linked list into
- * consecutive array entries */
-
for (i = 0; i < hsize; i++) {
+ /*
+ * Coalesce all entries belonging to one linked list
+ * into consecutive array entries.
+ */
packed_hash[i] = packed_entry;
for (entry = hash[i]; entry; entry = entry->next)
*packed_entry++ = entry->entry;
}
- /* Sentinel value to indicate the length of the last hash
- * bucket */
-
+ /* Sentinel value to indicate the length of the last hash bucket */
packed_hash[hsize] = packed_entry;
+
assert(packed_entry - (struct index_entry *)mem == entries);
free(hash);
^ permalink raw reply related
* Re: git-stash: RFC: Adopt the default behavior to other commands
From: Johannes Schindelin @ 2007-12-18 15:15 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Sebastian Harl, Junio C Hamano, Benoit Sigoure, git
In-Reply-To: <4767E07A.2020100@op5.se>
Hi,
On Tue, 18 Dec 2007, Andreas Ericsson wrote:
> Johannes Schindelin wrote:
>
> > In the alternative, you could just scrap all those default actions,
> > showing synopses instead. For all commands, including "git commit",
> > "git log", "git fetch", etc.
>
> Like we do for the git wrapper, you mean? Yes, that would be one
> solution, although not a very good one for all commands.
Exactly. Not a good one.
> It's probably not a bad idea for commands where the primary use is
> something else than producing visual output though, such as tag or
> branch, but those handle creation/deletion of stuff, so the default
> action for them is to list stuff of the kind they operate on. I fail to
> see why stash should be any different.
I also fail to see why stash should be any different. And that's why I
expect it to have a default operation, which is -- you guessed it --
"stash the changes!"
If I am not sure what I am about to do, there is -- wonder of wonders --
the "-h" option! And indeed:
$ git stash -h
Usage: /home/gitte/bin/git-stash [ | save | list | show | apply |
clear | create ]
So what exactly was your point again?
Ciao,
Dscho
^ permalink raw reply
* Re: git-stash: RFC: Adopt the default behavior to other commands
From: Andreas Ericsson @ 2007-12-18 15:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Sebastian Harl, Junio C Hamano, Benoit Sigoure, git
In-Reply-To: <Pine.LNX.4.64.0712181513060.23902@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Tue, 18 Dec 2007, Andreas Ericsson wrote:
>
>> Johannes Schindelin wrote:
>>
>>> In the alternative, you could just scrap all those default actions,
>>> showing synopses instead. For all commands, including "git commit",
>>> "git log", "git fetch", etc.
>> Like we do for the git wrapper, you mean? Yes, that would be one
>> solution, although not a very good one for all commands.
>
> Exactly. Not a good one.
>
>> It's probably not a bad idea for commands where the primary use is
>> something else than producing visual output though, such as tag or
>> branch, but those handle creation/deletion of stuff, so the default
>> action for them is to list stuff of the kind they operate on. I fail to
>> see why stash should be any different.
>
> I also fail to see why stash should be any different. And that's why I
> expect it to have a default operation, which is -- you guessed it --
> "stash the changes!"
>
Actually, I guessed "list the stashes".
> If I am not sure what I am about to do, there is -- wonder of wonders --
> the "-h" option! And indeed:
>
> $ git stash -h
> Usage: /home/gitte/bin/git-stash [ | save | list | show | apply |
> clear | create ]
>
> So what exactly was your point again?
>
My point is that it would be nice if all git commands that actually
manipulate objects (create/delete/modify) had a safe default, and
that experienced users such as yourself could endure the insufferable
agony of retraining your fingers to type five more chars so that
people won't have to get bitten by surprises.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ 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