* Re: git help error
From: Luciano Rocha @ 2007-12-04 19:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sergei Organov, Aneesh Kumar, Git Mailing List
In-Reply-To: <7vr6i245b4.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2112 bytes --]
On Tue, Dec 04, 2007 at 11:40:15AM -0800, Junio C Hamano wrote:
> Sergei Organov <osv@javad.com> writes:
>
> > Junio C Hamano <gitster@pobox.com> writes:
> >> "Aneesh Kumar" <aneesh.kumar@gmail.com> writes:
> >>
> >>> git help gives me the below error.
> >>>
> >>> [master@git]$ git help add
> >>> No manual entry for git-add
> >>> See 'man 7 undocumented' for help when manual pages are not available.
> >>> [master@git]$
> >>>
> >>> I have the git binaries installed via --prefix
> >>>
> >>> ./configure --prefix=/home/kvaneesh/bin-local/git/
> >>> and to see the man page i have to say
> >>>
> >>> man -M /home/kvaneesh/bin-local/git/share/man/
> >> ...
> >> When you run "man" from the command line, can you say
> >>
> >> $ man git-add
> >>
> >> and make it work? If it fails the same way, then what you are missing
> >> is MANPATH environment variable, isn't it?
> >
> > I think what the OP asked for makes sense. git-help should better find
> > corresponding version of manual pages automatically. This way, if one
> > invokes different versions of git-help, he will get corresponding
> > version of help text.
>
> I do not necessarily agree. Read what Aneesh wrote originally again,
> and read what he _didn't_ write.
>
> Not only he needs to run his "man" with -M (and my point was that it is
> not the only way, by the way), he needs to futz with his $PATH to
> include $HOME/bin-local/git for _his_ installation to work.
>
> I think my suggestion to use $MANPATH is in line with what he is already
> doing. If you install things in non-standard places, you can use
> environments to adjust to what you did, and that's the reason PATH and
> MANPATH environments are supported by your tools.
>
> Having said that, I do not mind accepting a patch that prepends the
> nonlocal path to MANPATH in help.c::show_man_page().
Actually, current man utilities locate the manual page by looking where
the executable is, if MANPATH isn't defined (tested in Linux and
Darwin).
So, "unset MANPATH; man git-add" should be sufficient.
--
lfr
0/0
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git help error
From: Junio C Hamano @ 2007-12-04 19:40 UTC (permalink / raw)
To: Sergei Organov; +Cc: Aneesh Kumar, Git Mailing List
In-Reply-To: <874pey9uow.fsf@osv.gnss.ru>
Sergei Organov <osv@javad.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>> "Aneesh Kumar" <aneesh.kumar@gmail.com> writes:
>>
>>> git help gives me the below error.
>>>
>>> [master@git]$ git help add
>>> No manual entry for git-add
>>> See 'man 7 undocumented' for help when manual pages are not available.
>>> [master@git]$
>>>
>>> I have the git binaries installed via --prefix
>>>
>>> ./configure --prefix=/home/kvaneesh/bin-local/git/
>>> and to see the man page i have to say
>>>
>>> man -M /home/kvaneesh/bin-local/git/share/man/
>> ...
>> When you run "man" from the command line, can you say
>>
>> $ man git-add
>>
>> and make it work? If it fails the same way, then what you are missing
>> is MANPATH environment variable, isn't it?
>
> I think what the OP asked for makes sense. git-help should better find
> corresponding version of manual pages automatically. This way, if one
> invokes different versions of git-help, he will get corresponding
> version of help text.
I do not necessarily agree. Read what Aneesh wrote originally again,
and read what he _didn't_ write.
Not only he needs to run his "man" with -M (and my point was that it is
not the only way, by the way), he needs to futz with his $PATH to
include $HOME/bin-local/git for _his_ installation to work.
I think my suggestion to use $MANPATH is in line with what he is already
doing. If you install things in non-standard places, you can use
environments to adjust to what you did, and that's the reason PATH and
MANPATH environments are supported by your tools.
Having said that, I do not mind accepting a patch that prepends the
nonlocal path to MANPATH in help.c::show_man_page().
^ permalink raw reply
* Cosmetic git-am interactive bug
From: Jeff Garzik @ 2007-12-04 19:19 UTC (permalink / raw)
To: Git Mailing List
[-- Attachment #1: Type: text/plain, Size: 999 bytes --]
Just now, I was exploring git-am's interactive mode, so as to comply
with Linus's urgings of a cleaner changelog <grin>. I had a raw email
changelog with the subject
Re: 2.6.24-rc3-git6: Reported regressions from 2.6.23
I used the [e]dit feature of interactive mode to change this
first-line/one-line summary to
pata_amd/pata_via: de-couple programming of PIO/MWDMA and UDMA
timings
When I hit [y]es to apply the patch, git reported
Applying 2.6.24-rc3-git6: Reported regressions from 2.6.23
Wrote tree 34cebd48e3b4e90fe3e6a6c6c03154ae1ed0c827
Committed: 943547abdfe9b4e27e36a25987909619908dffbf
The use of the older one-line summary led me to believe that it had not
committed my changelog edits. Looking at the result, however, proved
that the commit changelog was my new, corrected version.
Thus, I concluded that the printing of the old-and-no-longer-valid
changelog during the commit-to-tree phase was a bug.
Please see attached file for full example.
Thanks,
Jeff
[-- Attachment #2: git-am.txt --]
[-- Type: text/plain, Size: 3166 bytes --]
[jgarzik@pretzel libata-dev]$ git-am --utf8 --signoff -i /g/tmp/mbox
Commit Body is:
--------------------------
2.6.24-rc3-git6: Reported regressions from 2.6.23
On Saturday 01 December 2007, Rafael J. Wysocki wrote:
> Subject : 2.6.24-rc1: pata_amd fails to detect 80-pin wire
> Submitter : "Thomas Lindroth" <thomas.lindroth@gmail.com>
> References : http://lkml.org/lkml/2007/11/7/152
> http://bugzilla.kernel.org/show_bug.cgi?id=9322
> Handled-By : Tejun Heo <htejun@gmail.com>
> Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> Patch : http://lkml.org/lkml/2007/11/11/115
Tejun's rework of cable detection code which fixes the problem has
been just applied into "upstream" (not "upstream-fixes") so it is
destined for 2.6.25 (I wasn't on cc: BTW) and since I got no feedback
on my patch (below) which also happens to fix the regression, was
acked by Alan, tested by Thomas and has been in -mm for 3 weeks now
I assume that everybody is happy with it (Jeff/Tejun: you were also
on cc: when the patch was merged into -mm)...
Linus, please apply.
[PATCH] pata_amd/pata_via: de-couple programming of PIO/MWDMA and UDMA timings
* Don't program UDMA timings when programming PIO or MWDMA modes.
This has also a nice side-effect of fixing regression added by commit
681c80b5d96076f447e8101ac4325c82d8dce508 ("libata: correct handling of
SRST reset sequences") (->set_piomode method for PIO0 is called before
->cable_detect method which checks UDMA timings to get the cable type).
* Bump driver version.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Tested-by: "Thomas Lindroth" <thomas.lindroth@gmail.com>
Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Jeff Garzik <jeff@garzik.org>
Cc: Tejun Heo <htejun@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
--------------------------
Apply? [y]es/[n]o/[e]dit/[v]iew patch/[a]ccept all e
Commit Body is:
--------------------------
pata_amd/pata_via: de-couple programming of PIO/MWDMA and UDMA timings
* Don't program UDMA timings when programming PIO or MWDMA modes.
This has also a nice side-effect of fixing regression added by commit
681c80b5d96076f447e8101ac4325c82d8dce508 ("libata: correct handling of
SRST reset sequences") (->set_piomode method for PIO0 is called before
->cable_detect method which checks UDMA timings to get the cable type).
* Bump driver version.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Tested-by: "Thomas Lindroth" <thomas.lindroth@gmail.com>
Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Tejun Heo <htejun@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
--------------------------
Apply? [y]es/[n]o/[e]dit/[v]iew patch/[a]ccept all y
Applying 2.6.24-rc3-git6: Reported regressions from 2.6.23
Wrote tree 34cebd48e3b4e90fe3e6a6c6c03154ae1ed0c827
Committed: 943547abdfe9b4e27e36a25987909619908dffbf
^ permalink raw reply
* Re: git help error
From: Sergei Organov @ 2007-12-04 18:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Aneesh Kumar, Git Mailing List
In-Reply-To: <7v1wa25oqc.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> "Aneesh Kumar" <aneesh.kumar@gmail.com> writes:
>
>> git help gives me the below error.
>>
>> [master@git]$ git help add
>> No manual entry for git-add
>> See 'man 7 undocumented' for help when manual pages are not available.
>> [master@git]$
>>
>> I have the git binaries installed via --prefix
>>
>> ./configure --prefix=/home/kvaneesh/bin-local/git/
>> and to see the man page i have to say
>>
>> man -M /home/kvaneesh/bin-local/git/share/man/
>>
>> I guess git-help need to take care of the prefix.
>
> When you run "man" from the command line, can you say
>
> $ man git-add
>
> and make it work? If it fails the same way, then what you are missing
> is MANPATH environment variable, isn't it?
I think what the OP asked for makes sense. git-help should better find
corresponding version of manual pages automatically. This way, if one
invokes different versions of git-help, he will get corresponding
version of help text.
--
Sergei.
^ permalink raw reply
* Re: Not a valid object name refs/heads/t20050127-arm during git-cvsimport
From: Jakub Narebski @ 2007-12-04 18:06 UTC (permalink / raw)
To: Baurzhan Ismagulov; +Cc: git
In-Reply-To: <20071204171833.GD29315@radix50.net>
Baurzhan Ismagulov <ibr@radix50.net> writes:
> I want to import a CVS repo myrepo into git. I copied CVSHEAD and myrepo
> dirs from the cvs server to /home/ibr/tmp and issued the following
> command:
>
> git-cvsimport -p x -k -o cvshead -d/home/ibr/tmp -C zzz myrepo/drv
>
> It fails [...]
You can try to use other CVS importers, for example parsecvs from
Freedesktop project; see InterfaceFrontendsAndTools page on git wiki:
http://git.or.cz/gitwiki/InterfacesFrontendsAndTools
--
Jakub Narebski
^ permalink raw reply
* Re: Building git-1.5.3.7 on HP-UX 11.00
From: Junio C Hamano @ 2007-12-04 18:05 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: Johannes Schindelin, Andreas Ericsson, git, Sam Vilain
In-Reply-To: <20071204155655.053f4fb4@pc09.procura.nl>
"H.Merijn Brand" <h.m.brand@xs4all.nl> writes:
> On Tue, 4 Dec 2007 15:39:47 +0000 (GMT), Johannes Schindelin
> ...
> I found it! unset returns false
> ...
> I must leave now.
Thanks, you two.
I do not see "unset VAR... &&" outside t0001 test, but there are
instances of "unset VAR... &&" in git-submodule implementations as well.
In short, not too many places to fix.
^ permalink raw reply
* Re: [PATCH] Include diff options in the git-log manpage
From: Junio C Hamano @ 2007-12-04 17:57 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20071204122859.GQ31750@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> On Thu, Nov 01, 2007 at 03:57:40PM +0100, Miklos Vajna <vmiklos@frugalware.org> wrote:
>> Recently I wanted to see what git log -M does but actually I was not able to
>> find it in the manpage, finally figured out that all the diff options are
>> missing from here.
>>
>> Removing -p as it's already in diff-options.txt.
>
> could you please have a look at this patch? this also fixes the "-C is
> missing from man git-log" issue which was reported on IRC today.
There was a patch around diff options documentation from Sergei
last month, and somehow I thought it covered this issue as well.
Will format the docs before and after your fix, compare them, and then
decide either to drop or accept, which will take some time but will be
done before -rc0.
Thanks.
^ permalink raw reply
* Re: git help error
From: Junio C Hamano @ 2007-12-04 17:55 UTC (permalink / raw)
To: Aneesh Kumar; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <cc723f590712040826o7ca36bfg35b8cb4d64ee8d2d@mail.gmail.com>
"Aneesh Kumar" <aneesh.kumar@gmail.com> writes:
> git help gives me the below error.
>
> [master@git]$ git help add
> No manual entry for git-add
> See 'man 7 undocumented' for help when manual pages are not available.
> [master@git]$
>
> I have the git binaries installed via --prefix
>
> ./configure --prefix=/home/kvaneesh/bin-local/git/
> and to see the man page i have to say
>
> man -M /home/kvaneesh/bin-local/git/share/man/
>
> I guess git-help need to take care of the prefix.
When you run "man" from the command line, can you say
$ man git-add
and make it work? If it fails the same way, then what you are missing
is MANPATH environment variable, isn't it?
^ permalink raw reply
* Re: [PATCH] Set OLD_ICONV on Cygwin.
From: Junio C Hamano @ 2007-12-04 17:54 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Pascal Obry, Pascal Obry, Pascal Obry, git
In-Reply-To: <4755597B.9050709@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Nice. If my suspicions are correct and he missed your patch the first time
> around, you should probably resend it though.
I still have it in my mailbox.
I saw the patch but saw nobody else said about the patch being helpful
to his installation, nor more importantly, "Good, this won't hurt for me
who run a different vintage of Cygwin", and I was waiting for such
confirmations.
Then nobody responded, so I forgot.
That was what happened the first time Pascal's patch was posted.
^ permalink raw reply
* Re: git-add--interactive works only in top level
From: Junio C Hamano @ 2007-12-04 17:45 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Wincent Colaiuta, Reid Barton, git
In-Reply-To: <Pine.LNX.4.64.0712041148310.27959@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> Here he have two options: blame the user for his/her stupidity, or look
>> at this a UI problem and try to make the UI "idiot proof".
>>
>> In this particular case I see no impediment to favouring the second
>> option, because we're not talking about making changes that would make
>> Git less powerful or useful for "non-idiots", "power users" or "real
>> men" (whatever you want to call them). In other words, we are not
>> talking about "dumbing down" Git for the sake of the ignorant. This is
>> an opportunity to polish the UI in the same way that we polish the
>> internal pack format.
>
> You know, without patches you will not convince me ;-)
Honestly, I do not want a patch for that to git-add--interactive.
Once WIncent's and Dan's UI enhancements to it becomes stable (not
implementation-wise but more interface- and user-experience-wise),
rewriting it in C should not be too much of a hassle. When that
happens, it won't be a standalone program but will be a function
builtin-add.c::interactive_add() will call into and we won't have this
problem at that point. If somebody does do a patch, the time is better
spent there instead.
^ permalink raw reply
* Re: [PATCH] t9600: require cvsps 2.1 to perform tests
From: Junio C Hamano @ 2007-12-04 17:39 UTC (permalink / raw)
To: Jeff King; +Cc: gitzilla, Johannes Schindelin, git
In-Reply-To: <20071204154454.GA2994@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Mon, Dec 03, 2007 at 09:37:54PM -0800, Junio C Hamano wrote:
>
>> I wonder if it is better to grep for ' [-A] ' instead, like:
>>
>> cvsps_supports_A=$(cvsps -h 2>&1 | sed -ne '/\[-A\]/p')
>> case "$cvsps_supports_A" in
>> '')
>> say 'skipping cvsimport tests, lacking cvsps that supports -A option'
>> test_done
>> exit
>> esac
>
> I am not too opposed to that, but I felt that checking the version was a
> little bit more future proof. I.e., I have no idea if it is only -A that
> we need, but I know that 2.1 works and prior to 2.1 doesn't.
You are right about "we may be depending on what 2.1 has other than
-A". Will apply as-is.
Thanks, both.
The primary reason I asked about '\[-A\]' was what will happen if
somebody uses 2.2.
^ permalink raw reply
* Not a valid object name refs/heads/t20050127-arm during git-cvsimport
From: Baurzhan Ismagulov @ 2007-12-04 17:18 UTC (permalink / raw)
To: git
Hello,
I want to import a CVS repo myrepo into git. I copied CVSHEAD and myrepo
dirs from the cvs server to /home/ibr/tmp and issued the following
command:
git-cvsimport -p x -k -o cvshead -d/home/ibr/tmp -C zzz myrepo/drv
It fails with the following messages:
Initialized empty Git repository in /home/ibr/tmp/zzz/.git/
fatal: Not a valid object name refs/heads/t20050127-arm
read-tree failed: 32768
t20050127-arm is a branch that exists not for all files under
myrepo/drv.
How can I import this repo?
I use git 1.5.3.6-1.1 from Debian unstable and cvsps 2.1-2 from Debian
stable on a Debian testing/unstable system.
Thanks in advance,
--
Baurzhan Ismagulov
http://www.kz-easy.com/
^ permalink raw reply
* Re: Building git-1.5.3.7 on HP-UX 11.00
From: Johannes Schindelin @ 2007-12-04 16:28 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: Andreas Ericsson, git, Sam Vilain
In-Reply-To: <20071204155655.053f4fb4@pc09.procura.nl>
Hi,
On Tue, 4 Dec 2007, H.Merijn Brand wrote:
> I found it! unset returns false
Oh, wow! The question is now: how to deal with it (there are quite a few
unsets in the test scripts).
Is there a way to override "unset" with something like this:
unset_real () {
unset "$@"
}
unset () {
unset_real "$@"
true
}
?
Ciao,
Dscho
^ permalink raw reply
* git help error
From: Aneesh Kumar @ 2007-12-04 16:26 UTC (permalink / raw)
To: Git Mailing List, Junio C Hamano
git help gives me the below error.
[master@git]$ git help add
No manual entry for git-add
See 'man 7 undocumented' for help when manual pages are not available.
[master@git]$
I have the git binaries installed via --prefix
./configure --prefix=/home/kvaneesh/bin-local/git/
and to see the man page i have to say
man -M /home/kvaneesh/bin-local/git/share/man/
I guess git-help need to take care of the prefix.
-aneesh
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Brian Downing @ 2007-12-04 16:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzlwv6sxr.fsf@gitster.siamese.dyndns.org>
On Fri, Nov 30, 2007 at 06:37:52PM -0800, Junio C Hamano wrote:
> * jc/api-doc (Sat Nov 24 23:48:04 2007 -0800) 1 commit
> - Start preparing the API documents.
>
> The primary reason of this series is because I think we made the system
> a lot less approachable by losing hackability. Although we still have
> sample scripts in contrib/example for use of plumbing in scripts, they
> will not help aspiring git-hacker-wannabees when our primary attention
> has already shifted to moving things to C.
>
> This currently consists of mostly stubs, although I wrote about a few
> topics as examples.
One comment on this:
+sometype *ary;
+int nr;
+int alloc
+
+for (i = 0; i < nr; i++)
+ if (you like ary[i])
+ return;
+/* you did not like any existing one, so add one */
+ALLOC_GROW(ary, nr+1, alloc);
+ary[nr++] = value you like;
Shouldn't we be encouraging the use of size_t here? I don't know of a
64-bit platform off hand that has an 'int' that's actually 64 bits, so
encouraging this just seems like asking for 64-bit platform limitations
when arrays get over 2GB.
(Looking through the code it looks like there's a fair bit of using
'int' for array indices already, but I think it's probably best not to
perpetuate that.)
-bcd
^ permalink raw reply
* Re: [PATCH] Make Git accept absolute path names for files within the work tree
From: Linus Torvalds @ 2007-12-04 15:59 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Robin Rosenberg, Jeff King, Junio C Hamano, Anatol Pomozov, git
In-Reply-To: <Pine.LNX.4.64.0712041149440.27959@racer.site>
On Tue, 4 Dec 2007, Johannes Schindelin wrote:
>
> I do remember the hassles I went through with get_relative_cwd() until I
> broke down and used chdir() two times (ugly).
It really is a pretty heavy and complex operation in UNIX in general (and
open to various races too), which is why I'd generally suggest avoiding it
if you at all can.
The sad(?) part is, it's fairly trivial to do inside the Linux kernel (but
probably not in other operating systems - it's only because of our
superior dcache that we could do it). So a special system call would be no
problem at all. But obviously very unportable indeed.
Linus
^ permalink raw reply
* Re: Building git-1.5.3.7 on HP-UX 11.00
From: H.Merijn Brand @ 2007-12-04 15:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Andreas Ericsson, git, Sam Vilain
In-Reply-To: <Pine.LNX.4.64.0712041536180.27959@racer.site>
On Tue, 4 Dec 2007 15:39:47 +0000 (GMT), Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Tue, 4 Dec 2007, H.Merijn Brand wrote:
>
> > + + pwd
> > GIT_EXEC_PATH=/pro/3gl/LINUX/git-1.5.3.7/t/..
> > + + pwd
> > GIT_TEMPLATE_DIR=/pro/3gl/LINUX/git-1.5.3.7/t/../templates/blt
> > + GIT_CONFIG=.git/config
> > + export PATH GIT_EXEC_PATH GIT_TEMPLATE_DIR GIT_CONFIG
> > + + pwd
> > + pwd
> > GITPERLLIB=/pro/3gl/LINUX/git-1.5.3.7/t/../perl/blib/lib:/pro/3gl/LINUX/git-1.5.3.7/t/../perl/blib/arch/auto/Git
> > + export GITPERLLIB
> > + test -d ../templates/blt
> > + test -x ../test-chmtime
> > + test=trash
> > + rm -fr trash
> > + test_create_repo trash
> > + cd trash
> > + + expr ./t0001-init.sh : .*/\(t[0-9]*\)-[^/]*$
> > this_test=t0001
> > + test_expect_success plain
> > (
> > unset GIT_DIR GIT_WORK_TREE &&
> > mkdir plain &&
> > cd plain &&
> > git init
> > ) &&
> > check_config plain/.git false unset
> >
> > * expecting success:
> > (
> > unset GIT_DIR GIT_WORK_TREE &&
> > mkdir plain &&
> > cd plain &&
> > git init
> > ) &&
> > check_config plain/.git false unset
> >
> > * FAIL 1: plain
> >
> > (
> > unset GIT_DIR GIT_WORK_TREE &&
> > mkdir plain &&
> > cd plain &&
> > git init
> > ) &&
> > check_config plain/.git false unset
>
> That's not good. The relevant part here reads:
I found it! unset returns false
/pro/3gl/LINUX/git-1.5.3.7/t 152 > sh t0001*.sh
* ok 1: plain
* ok 2: plain with GIT_WORK_TREE
* ok 3: plain bare
* ok 4: plain bare with GIT_WORK_TREE
* ok 5: GIT_DIR bare
* ok 6: GIT_DIR non-bare
* ok 7: GIT_DIR & GIT_WORK_TREE (1)
* ok 8: GIT_DIR & GIT_WORK_TREE (2)
* passed all 8 test(s)
--8<---
--- t0001-init.sh.org 2007-12-04 16:55:25 +0100
+++ t0001-init.sh 2007-12-04 16:52:37 +0100
@@ -25,7 +25,7 @@ check_config () {
test_expect_success 'plain' '
(
- unset GIT_DIR GIT_WORK_TREE &&
+ unset GIT_DIR GIT_WORK_TREE ;
mkdir plain &&
cd plain &&
git init
@@ -35,7 +35,7 @@ test_expect_success 'plain' '
test_expect_success 'plain with GIT_WORK_TREE' '
if (
- unset GIT_DIR &&
+ unset GIT_DIR ;
mkdir plain-wt &&
cd plain-wt &&
GIT_WORK_TREE=$(pwd) git init
@@ -48,7 +48,7 @@ test_expect_success 'plain with GIT_WORK
test_expect_success 'plain bare' '
(
- unset GIT_DIR GIT_WORK_TREE GIT_CONFIG &&
+ unset GIT_DIR GIT_WORK_TREE GIT_CONFIG ;
mkdir plain-bare-1 &&
cd plain-bare-1 &&
git --bare init
@@ -58,7 +58,7 @@ test_expect_success 'plain bare' '
test_expect_success 'plain bare with GIT_WORK_TREE' '
if (
- unset GIT_DIR GIT_CONFIG &&
+ unset GIT_DIR GIT_CONFIG ;
mkdir plain-bare-2 &&
cd plain-bare-2 &&
GIT_WORK_TREE=$(pwd) git --bare init
@@ -72,7 +72,7 @@ test_expect_success 'plain bare with GIT
test_expect_success 'GIT_DIR bare' '
(
- unset GIT_CONFIG &&
+ unset GIT_CONFIG ;
mkdir git-dir-bare.git &&
GIT_DIR=git-dir-bare.git git init
) &&
@@ -82,7 +82,7 @@ test_expect_success 'GIT_DIR bare' '
test_expect_success 'GIT_DIR non-bare' '
(
- unset GIT_CONFIG &&
+ unset GIT_CONFIG ;
mkdir non-bare &&
cd non-bare &&
GIT_DIR=.git git init
@@ -93,7 +93,7 @@ test_expect_success 'GIT_DIR non-bare' '
test_expect_success 'GIT_DIR & GIT_WORK_TREE (1)' '
(
- unset GIT_CONFIG &&
+ unset GIT_CONFIG ;
mkdir git-dir-wt-1.git &&
GIT_WORK_TREE=$(pwd) GIT_DIR=git-dir-wt-1.git git init
) &&
@@ -103,7 +103,7 @@ test_expect_success 'GIT_DIR & GIT_WORK_
test_expect_success 'GIT_DIR & GIT_WORK_TREE (2)' '
if (
- unset GIT_CONFIG &&
+ unset GIT_CONFIG ;
mkdir git-dir-wt-2.git &&
GIT_WORK_TREE=$(pwd) GIT_DIR=git-dir-wt-2.git git --bare init
)
-->8---
I must leave now.
--
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] Use a strbuf for copying the command line for the reflog.
From: Kristian Høgsberg @ 2007-12-04 15:46 UTC (permalink / raw)
To: gitster; +Cc: git
In-Reply-To: <1196753147-20073-1-git-send-email-krh@redhat.com>
Doh, I forgot -n to git-format-patch again for this two patch series.
Maybe git-format-patch should default to -n when there's more than one
patch? Anyway, it should have been:
[PATCH 1/2] Use a strbuf for copying the command line for the reflog.
[PATCH 2/2] Rewrite builtin-fetch option parsing to use parse_options().
cheers,
Kristian
^ permalink raw reply
* Re: [PATCH] t9600: require cvsps 2.1 to perform tests
From: Jeff King @ 2007-12-04 15:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: gitzilla, Johannes Schindelin, git
In-Reply-To: <7v1wa3aukt.fsf@gitster.siamese.dyndns.org>
On Mon, Dec 03, 2007 at 09:37:54PM -0800, Junio C Hamano wrote:
> I wonder if it is better to grep for ' [-A] ' instead, like:
>
> cvsps_supports_A=$(cvsps -h 2>&1 | sed -ne '/\[-A\]/p')
> case "$cvsps_supports_A" in
> '')
> say 'skipping cvsimport tests, lacking cvsps that supports -A option'
> test_done
> exit
> esac
I am not too opposed to that, but I felt that checking the version was a
little bit more future proof. I.e., I have no idea if it is only -A that
we need, but I know that 2.1 works and prior to 2.1 doesn't.
-Jeff
^ permalink raw reply
* Re: Building git-1.5.3.7 on HP-UX 11.00
From: Johannes Schindelin @ 2007-12-04 15:39 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: Andreas Ericsson, git, Sam Vilain
In-Reply-To: <20071204152240.6cb6018e@pc09.procura.nl>
Hi,
On Tue, 4 Dec 2007, H.Merijn Brand wrote:
> + + pwd
> GIT_EXEC_PATH=/pro/3gl/LINUX/git-1.5.3.7/t/..
> + + pwd
> GIT_TEMPLATE_DIR=/pro/3gl/LINUX/git-1.5.3.7/t/../templates/blt
> + GIT_CONFIG=.git/config
> + export PATH GIT_EXEC_PATH GIT_TEMPLATE_DIR GIT_CONFIG
> + + pwd
> + pwd
> GITPERLLIB=/pro/3gl/LINUX/git-1.5.3.7/t/../perl/blib/lib:/pro/3gl/LINUX/git-1.5.3.7/t/../perl/blib/arch/auto/Git
> + export GITPERLLIB
> + test -d ../templates/blt
> + test -x ../test-chmtime
> + test=trash
> + rm -fr trash
> + test_create_repo trash
> + cd trash
> + + expr ./t0001-init.sh : .*/\(t[0-9]*\)-[^/]*$
> this_test=t0001
> + test_expect_success plain
> (
> unset GIT_DIR GIT_WORK_TREE &&
> mkdir plain &&
> cd plain &&
> git init
> ) &&
> check_config plain/.git false unset
>
> * expecting success:
> (
> unset GIT_DIR GIT_WORK_TREE &&
> mkdir plain &&
> cd plain &&
> git init
> ) &&
> check_config plain/.git false unset
>
> * FAIL 1: plain
>
> (
> unset GIT_DIR GIT_WORK_TREE &&
> mkdir plain &&
> cd plain &&
> git init
> ) &&
> check_config plain/.git false unset
That's not good. The relevant part here reads:
-- snip --
+ test_description='git init'
+ . ./test-lib.sh
++ LANG=C
++ LC_ALL=C
++ PAGER=cat
++ TZ=UTC
++ export LANG LC_ALL PAGER TZ
++ EDITOR=:
++ VISUAL=:
++ unset GIT_EDITOR
++ unset AUTHOR_DATE
++ unset AUTHOR_EMAIL
++ unset AUTHOR_NAME
++ unset COMMIT_AUTHOR_EMAIL
++ unset COMMIT_AUTHOR_NAME
++ unset EMAIL
++ unset GIT_ALTERNATE_OBJECT_DIRECTORIES
++ unset GIT_AUTHOR_DATE
++ GIT_AUTHOR_EMAIL=author@example.com
++ GIT_AUTHOR_NAME='A U Thor'
++ unset GIT_COMMITTER_DATE
++ GIT_COMMITTER_EMAIL=committer@example.com
++ GIT_COMMITTER_NAME='C O Mitter'
++ unset GIT_DIFF_OPTS
++ unset GIT_DIR
++ unset GIT_WORK_TREE
++ unset GIT_EXTERNAL_DIFF
++ unset GIT_INDEX_FILE
++ unset GIT_OBJECT_DIRECTORY
++ unset SHA1_FILE_DIRECTORIES
++ unset SHA1_FILE_DIRECTORY
++ GIT_MERGE_VERBOSITY=5
++ export GIT_MERGE_VERBOSITY
++ export GIT_AUTHOR_EMAIL GIT_AUTHOR_NAME
++ export GIT_COMMITTER_EMAIL GIT_COMMITTER_NAME
++ export EDITOR VISUAL
++ unset CDPATH
++ case $(echo $GIT_TRACE |tr "[A-Z]" "[a-z]") in
+++ echo
+++ tr '[A-Z]' '[a-z]'
++ '[' xxterm '!=' xdumb ']'
++ '[' -t 1 ']'
++ test 2 -ne 0
++ case "$1" in
++ immediate=t
++ shift
++ test 1 -ne 0
++ case "$1" in
++ verbose=t
++ shift
++ test 0 -ne 0
++ test -n ''
++ test 'git init' '!=' ''
++ test '' = t
++ exec
++ test t = t
++ exec
++ test_failure=0
++ test_count=0
++ trap 'echo >&5 "FATAL: Unexpected exit with code $?"; exit 1' exit
+++ pwd
++ PATH=/home/gitte/my/git/t/..:/home/gene099/bin:/usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin:/usr/games:/opt/gnome/bin:/opt/kde3/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin:/usr/lib/qt3/bin
+++ pwd
++ GIT_EXEC_PATH=/home/gitte/my/git/t/..
+++ pwd
++ GIT_TEMPLATE_DIR=/home/gitte/my/git/t/../templates/blt
++ GIT_CONFIG=.git/config
++ export PATH GIT_EXEC_PATH GIT_TEMPLATE_DIR GIT_CONFIG
+++ pwd
+++ pwd
++ GITPERLLIB=/home/gitte/my/git/t/../perl/blib/lib:/home/gene099/my/git/t/../perl/blib/arch/auto/Git
++ export GITPERLLIB
++ test -d ../templates/blt
++ test -x ../test-chmtime
++ test=trash
++ rm -fr trash
++ test_create_repo trash
++ test 1 = 1
+++ pwd
++ owd=/home/gitte/my/git/t
++ repo=trash
++ mkdir trash
++ cd trash
++ /home/gitte/my/git/t/../git init --template=/home/gene099/my/git/t/../templates/blt/
++ mv .git/hooks .git/hooks-disabled
++ cd /home/gitte/my/git/t
++ cd trash
+++ expr ./t0001-init.sh : '.*/\(t[0-9]*\)-[^/]*$'
++ this_test=t0001
+ test_expect_success plain '
(
unset GIT_DIR GIT_WORK_TREE &&
mkdir plain &&
cd plain &&
git init
) &&
check_config plain/.git false unset
'
+ test 2 = 2
+ test_skip plain '
(
unset GIT_DIR GIT_WORK_TREE &&
mkdir plain &&
cd plain &&
git init
) &&
check_config plain/.git false unset
'
-- snap --
So I get way more information. Which let's me suspect that your shell
might be the culprit? Can you try with bash?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Set OLD_ICONV on Cygwin.
From: Pascal Obry @ 2007-12-04 13:39 UTC (permalink / raw)
To: Andreas Ericsson, Pascal Obry; +Cc: Pascal Obry, git, Junio C Hamano
Andreas Ericsson wrote:
> Only one, insofar as I can see; You didn't CC Junio. He probably missed it.
Hum, I don't think this is a requirement. At least nothing is said about
CCing Junio on the Git Web site.
Anyway, now Junio is CCed :)
Pascal.
^ permalink raw reply
* Re: [PATCH] git-stash: Display help message if git-stash is run with wrong sub-commands
From: Wayne Davison @ 2007-12-04 15:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Kevin Leung, Git ML
In-Reply-To: <Pine.LNX.4.64.0712031023480.27959@racer.site>
On Mon, Dec 03, 2007 at 10:25:17AM +0000, Johannes Schindelin wrote:
> But those are not really options, are they? They are commands, which
> exclude each other.
Option syntax is often used to represent exclusive commands, especially
when those commands need to be distinguished from free-form arg words.
The "git checkout" command is another example of this in git, and there
are plenty of non-git examples of such a use of option syntax around.
Such a syntax makes it easier to have a default action while still
taking a free-form arg. I personally think that using option syntax
for its behavior choices would be preferable with git stash.
..wayne..
^ permalink raw reply
* Re: Building git-1.5.3.7 on HP-UX 11.00
From: H.Merijn Brand @ 2007-12-04 15:22 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Johannes Schindelin, git, Sam Vilain
In-Reply-To: <47556EE2.6040105@op5.se>
On Tue, 04 Dec 2007 16:14:42 +0100, Andreas Ericsson <ae@op5.se> wrote:
> H.Merijn Brand wrote:
> >
> > I also meanwhile forced copied the git binaries to my bin dir
> >
>
> That's no good. "make test" will test binaries residing in ..
> relative to where the tests are executed.
OK, I removed those again :)
I also removed the -ldce in the HP-UX piece, which was there to
support unsetenv, but using NO_UNSETENV seems to be safer
ifeq ($(uname_S),HP-UX)
# HP-UX
BASIC_LDFLAGS += -L/usr/local/ssl/lib -L/usr/local/lib
#EXTLIBS += -ldce
NO_HSTRERROR = YesPlease
NO_ICONV = YesPlease
NO_INET_NTOP = YesPlease
NO_INET_PTON = YesPlease
NO_UNSETENV = YesPlease
endif
causes a clean build
+ + pwd
GIT_EXEC_PATH=/pro/3gl/LINUX/git-1.5.3.7/t/..
+ + pwd
GIT_TEMPLATE_DIR=/pro/3gl/LINUX/git-1.5.3.7/t/../templates/blt
+ GIT_CONFIG=.git/config
+ export PATH GIT_EXEC_PATH GIT_TEMPLATE_DIR GIT_CONFIG
+ + pwd
+ pwd
GITPERLLIB=/pro/3gl/LINUX/git-1.5.3.7/t/../perl/blib/lib:/pro/3gl/LINUX/git-1.5.3.7/t/../perl/blib/arch/auto/Git
+ export GITPERLLIB
+ test -d ../templates/blt
+ test -x ../test-chmtime
+ test=trash
+ rm -fr trash
+ test_create_repo trash
+ cd trash
+ + expr ./t0001-init.sh : .*/\(t[0-9]*\)-[^/]*$
this_test=t0001
+ test_expect_success plain
(
unset GIT_DIR GIT_WORK_TREE &&
mkdir plain &&
cd plain &&
git init
) &&
check_config plain/.git false unset
* expecting success:
(
unset GIT_DIR GIT_WORK_TREE &&
mkdir plain &&
cd plain &&
git init
) &&
check_config plain/.git false unset
* FAIL 1: plain
(
unset GIT_DIR GIT_WORK_TREE &&
mkdir plain &&
cd plain &&
git init
) &&
check_config plain/.git false unset
/pro/3gl/LINUX/git-1.5.3.7/t 130 > ldd ../git
/usr/lib/libc.2 => /usr/lib/libc.2
/usr/lib/libdld.2 => /usr/lib/libdld.2
/usr/lib/libc.2 => /usr/lib/libc.2
/usr/local/ssl/lib/libcrypto.sl => /usr/local/ssl/lib/libcrypto.sl
/usr/local/lib/libz.sl => /usr/local/lib/libz.sl
I will leave for a meeting in 30 minutes, so don't think I don't want
to communicate any further :)
Sam is pretty enthusiastic on IRC, he's to blame!
--
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: Building git-1.5.3.7 on HP-UX 11.00
From: Andreas Ericsson @ 2007-12-04 15:14 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: Johannes Schindelin, git, Sam Vilain
In-Reply-To: <20071204150102.7f3ec3e9@pc09.procura.nl>
H.Merijn Brand wrote:
>
> I also meanwhile forced copied the git binaries to my bin dir
>
That's no good. "make test" will test binaries residing in ..
relative to where the tests are executed.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Building git-1.5.3.7 on HP-UX 11.00
From: H.Merijn Brand @ 2007-12-04 15:11 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Sam Vilain
In-Reply-To: <Pine.LNX.4.64.0712041439590.27959@racer.site>
On Tue, 4 Dec 2007 14:40:47 +0000 (GMT), Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Tue, 4 Dec 2007, H.Merijn Brand wrote:
>
> > On Tue, 4 Dec 2007 13:44:02 +0000 (GMT), Johannes Schindelin
> > <Johannes.Schindelin@gmx.de> wrote:
> >
> > > Hi,
> > >
> > > On Tue, 4 Dec 2007, H.Merijn Brand wrote:
> > >
> > > > make test then fails:
> > >
> > > Could you run the failing test manually with -i -v, like so:
> > >
> > > $ cd t/
> > > $ sh t0001*.sh -i -v
> >
> > /pro/3gl/LINUX/git-1.5.3.7 183 > cd t
> > /pro/3gl/LINUX/git-1.5.3.7/t 184 > sh t0001*.sh -i -v
> > * error: cannot run git init -- have you built things yet?
> > Exit 1
> > /pro/3gl/LINUX/git-1.5.3.7/t 185 >
>
> Next step: add the sh option -x:
>
> $ sh -x t0001*.sh -i -v
After I did # make git
and # make test
# cd t
# h -x t0001*.sh -i -v
:
:
+ + pwd
GIT_EXEC_PATH=/pro/3gl/LINUX/git-1.5.3.7/t/..
+ + pwd
GIT_TEMPLATE_DIR=/pro/3gl/LINUX/git-1.5.3.7/t/../templates/blt
+ GIT_CONFIG=.git/config
+ export PATH GIT_EXEC_PATH GIT_TEMPLATE_DIR GIT_CONFIG
+ + pwd
+ pwd
GITPERLLIB=/pro/3gl/LINUX/git-1.5.3.7/t/../perl/blib/lib:/pro/3gl/LINUX/git-1.5.
3.7/t/../perl/blib/arch/auto/Git
+ export GITPERLLIB
+ test -d ../templates/blt
+ test -x ../test-chmtime
+ test=trash
+ rm -fr trash
+ test_create_repo trash
+ cd trash
+ + expr ./t0001-init.sh : .*/\(t[0-9]*\)-[^/]*$
this_test=t0001
+ test_expect_success plain
(
unset GIT_DIR GIT_WORK_TREE &&
mkdir plain &&
cd plain &&
git init
) &&
check_config plain/.git false unset
* expecting success:
(
unset GIT_DIR GIT_WORK_TREE &&
mkdir plain &&
cd plain &&
git init
) &&
check_config plain/.git false unset
* FAIL 1: plain
(
unset GIT_DIR GIT_WORK_TREE &&
mkdir plain &&
cd plain &&
git init
) &&
check_config plain/.git false unset
> to find out what made it fail.
>
> Thanks,
> Dscho
>
>
--
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