Git
Dave Yeo
(1.6.2.2) and it almost works it seems to screw up between downloading
the repository and unpacking it.
eg
[I:\usr\src\git-1.6.2.2]git clone git://anongit.freedesktop.org/git/pixman
Initialized empty Git repository in I:/usr/src/git-1.6.2.2/pixman/.git/
remote: Counting objects: 2334, done.
remote: Compressing objects: 100% (864/864), done.
remote: Total 2334 (delta 1719), reused 1977 (delta 1468)
Receiving objects: 100% (2334/2334), 547.31 KiB | 1 KiB/s, done.
Resolving deltas: 100% (1719/1719), done.
fatal: You don't exist. Go away!
leaving an empty pixman directory besides hidden .git including the
packed pixman.
Dave
Tellerbop
wrote:
Hi Dave,
http://ebisa.hp.infoseek.co.jp/os2/index.htm#git
I use this and worked fine :P
--
With the best regards from the Netherlands,
Dave Yeo
> Hi Dave,
>
> http://ebisa.hp.infoseek.co.jp/os2/index.htm#git
>
> I use this and worked fine :P
>
Excellent, will download and test. Seems like a bunch of other useful
stuff there as well
Dave
Dave Yeo
Ok, finally got around to patching git-1.6.2.2 and building with my
preferred $PREFIX. The patch applied pretty cleanly and the tree
compiles fine excepting it wants to use -pthread instead of -lpthread
(this problem was there before patching as well) and running git clone
git://anongit.freedesktop.org/git/cairo
results in a clone of cairo. Changing into the resulting cairo directory
and issuing a git pull results in
[I:\git\cairo]git pull
git: 'pull' is not a git-command. See 'git --help'.
Did you mean this?
pull
which was also a problem before patching. Does git pull work for you? Or
is there a newer way to update a tree? I also tried running sh git-pull
which resulted in
[I:\git\cairo]sh ../libexec/git-core/git-pull
- not something we can merge17cfd59b4abfce33f3
Dave
Steven Levine
at 12:28 AM, Dave Yeo <dave....@gmail.com> said:
>Ok, finally got around to patching git-1.6.2.2 and building with my
>preferred $PREFIX.
FWIW, the diff contains
+#if defined(__MINGW32__) && defined(__OS2__)
which does not look right to me. Did you change this?
>[I:\git\cairo]git pull
>git: 'pull' is not a git-command. See 'git --help'.
>Did you mean this?
> pull
I wonder if this is a CR/NL issue?
Steven
--
--------------------------------------------------------------------------------------------
Steven Levine <ste...@earthlink.bogus.net>
eCS/Warp/DIY etc. www.scoug.com www.ecomstation.com
--------------------------------------------------------------------------------------------
Dave Yeo
> In<WAaEl.21389$Db2.8527@edtnps83>, on 04/12/2009
> at 12:28 AM, Dave Yeo<dave....@gmail.com> said:
>
>> Ok, finally got around to patching git-1.6.2.2 and building with my
>> preferred $PREFIX.
>
> FWIW, the diff contains
>
>
> which does not look right to me. Did you change this?
I did now though I'm not sure what the point of the code is. It checks
for an executable, by looking at the binary signature on OS/2 and
Windows. Possibly a security thing? Or differentiating between binary
and shell script?
>
>> [I:\git\cairo]git pull
>> git: 'pull' is not a git-command. See 'git --help'.
>> Did you mean this?
>> pull
>
> I wonder if this is a CR/NL issue?
>
No I don't think so. Most commands I've tried seem to work. The couple
I've found that don't use shell scripts so that is part of the problem
as well as a lot of the executables are symlinks.
It is desperately in need of a DLL, installing with cp instead of ln -s
results in a git directory of 1.3 GBs. Unluckily my attempts to build a
DLL are frustrated by 3 missing symbols.
Dave
Paul Ratcliffe
>> +#if defined(__MINGW32__)&& defined(__OS2__)
>>
>> which does not look right to me. Did you change this?
>
> I did now though I'm not sure what the point of the code is. It checks
> for an executable, by looking at the binary signature on OS/2 and
> Windows.
I think the point Steven was making was that it should be an OR not an AND.
Dave Yeo
Guess I wasn't clear. After Steven pointed it out I changed the AND to
an OR and saw no change.
I have to find the time to read the documentation and try to follow the
code.
Dave
Steven Levine
Regards,
Steven Levine
at 01:35 AM, Dave Yeo <dave....@gmail.com> said:
Hi,
>Excellent, will download and test. Seems like a bunch of other useful
>stuff there as well
Definitely. Can anyone read the site well enough to find and email
address? There a defect in the diff that causes the GIT_SHELL logic to
fail.
Thanks,
Tellerbop
<ste...@earthlink.bogus.net> wrote:
Hi Steve,
Sorry i don't know the email adrss, i been looking for it to, cause
the latest git don't work here :(
I get this:
U:\git\bin>git clone git://repo.or.cz/cclive.git
warning: $GIT_FIND is not defined. Assume GIT_FIND=/Moztools/find.exe.
warning: $GIT_SORT is not defined. Assume GIT_SORT=/Moztools/sort.exe.
Initialized empty Git repository in U:/git/bin/cclive/.git/
fatal: index-pack failed
> In <X5yCl.21812$PH1.9193@edtnps82>, on 04/07/2009
> at 01:35 AM, Dave Yeo <dave....@gmail.com> said:
>
> Hi,
>
> >Excellent, will download and test. Seems like a bunch of other useful
> >stuff there as well
>
> Definitely. Can anyone read the site well enough to find and email
> address? There a defect in the diff that causes the GIT_SHELL logic to
> fail.
>
> Thanks,
>
> Steven
>
--
Dave Yeo
> at 12:28 AM, Dave Yeo<dave....@gmail.com> said:
>
>> >Ok, finally got around to patching git-1.6.2.2 and building with my
>> >preferred $PREFIX.
> FWIW, the diff contains
>
> +#if defined(__MINGW32__)&& defined(__OS2__)
>
I haven't had time to revisit this but I should mention that this code
is just for traversing the executables and getting the help output for
them and falling back to the *nix permissions is probably good enough
with klibc.
Dave
Steven Levine
at 10:11 PM, "Tellerbop" <Tell...@wint.nl> said:
Hi,
>U:\git\bin>git clone git://repo.or.cz/cclive.git
>warning: $GIT_FIND is not defined. Assume GIT_FIND=/Moztools/find.exe.
>warning: $GIT_SORT is not defined. Assume GIT_SORT=/Moztools/sort.exe.
>Initialized empty Git repository in U:/git/bin/cclive/.git/ fatal:
>index-pack failed
You need to add libexec\git-core to the PATH.
A successful git will look like
Initialized empty Git repository in I:/Tmp/git_test/cclive/.git/ remote:
Counting objects: 1265, done.
remote: Compressing objects: 100% (370/370), done.
remote: Total 1265 (delta 891), reused 1265 (delta 891)
Receiving objects: 100% (1265/1265), 396.00 KiB | 39 KiB/s, done.
Resolving deltas: 100% (891/891), done.
Steven
>> In <X5yCl.21812$PH1.9193@edtnps82>, on 04/07/2009
>> at 01:35 AM, Dave Yeo <dave....@gmail.com> said:
>>
>> Hi,
>>
>> >Excellent, will download and test. Seems like a bunch of other useful
>> >stuff there as well
>>
>> Definitely. Can anyone read the site well enough to find and email
>> address? There a defect in the diff that causes the GIT_SHELL logic to
>> fail.
>>
>> Thanks,
>>
>> Steven
>>
Regards,
Dave Yeo
> In<dFLodVgnWr1K-pn2-j5300gBxkkm3@localhost>, on 05/13/2009
> at 10:11 PM, "Tellerbop"<Tell...@wint.nl> said:
>
> Hi,
>
>> >U:\git\bin>git clone git://repo.or.cz/cclive.git
>> >warning: $GIT_FIND is not defined. Assume GIT_FIND=/Moztools/find.exe.
>> >warning: $GIT_SORT is not defined. Assume GIT_SORT=/Moztools/sort.exe.
>> >Initialized empty Git repository in U:/git/bin/cclive/.git/ fatal:
>> >index-pack failed
> You need to add libexec\git-core to the PATH.
>
> A successful git will look like
>
> Initialized empty Git repository in I:/Tmp/git_test/cclive/.git/ remote:
> Counting objects: 1265, done.
> remote: Compressing objects: 100% (370/370), done.
> remote: Total 1265 (delta 891), reused 1265 (delta 891)
> Receiving objects: 100% (1265/1265), 396.00 KiB | 39 KiB/s, done.
> Resolving deltas: 100% (891/891), done.
>
When I built Git with prefix=/git it worked (clone) fine without needing
anything added to the %PATH%. I did experiment with %PATH% trying to get
pull to work, no difference.
There are also environment variables to tell Git where it is running,
see the install instructions under running without make install
Dave
Dave
Dave Yeo
> There are also environment variables to tell Git where it is running,
> see the install instructions under running without make install
GIT_EXEC_PATH=`pwd`
PATH=`pwd`:$PATH
GITPERLLIB=`pwd`/perl/blib/lib
export GIT_EXEC_PATH PATH GITPERLLIB
Dave
Steven Levine
at 02:14 AM, Dave Yeo <dave....@gmail.com> said:
Hi,
>When I built Git with prefix=/git it worked (clone) fine without needing
>anything added to the %PATH%. I did experiment with %PATH% trying to get
>pull to work, no difference.
Note that I am using the Japanese build as a reference. If you post your
diffs and configure settings, I'll apply them to the sources and this
might help with analysis.
>There are also environment variables to tell Git where it is running,
>see the install instructions under running without make install
There are lots of environment variables. :-) GIT_EXEC_PATH does not work
here. I suspect the reason may be in in strip_path_suffix which does not
appear to be case-insensitive.
Back to your original problem, which I can duplicate with git clone
followed by
i:\tmp\gittest\clone_from_remote
>git pull git://repo.or.cz/cclive.git master
From git://repo.or.cz/cclive
* branch master -> FETCH_HEAD
- not something we can merge06f607ef23aeb0c036
The same failure occurs pulling from a local clone.
i:\tmp\gittest\clone_from_local
>git pull ..\clone_from_remote master
From ..\clone_from_remote
* branch master -> FETCH_HEAD
- not something we can merge06f607ef23aeb0c036
This is from builtin-merge.c#902 which is doing
remote_head = peel_to_type(argv[0], 0, NULL, OBJ_COMMIT);
if (!remote_head)
die("%s - not something we can merge", argv[0]);
A couple of printfs in peel_to_type should tell you why this is occuring.
However, I'm not sure this is an error. It may be saying there's nothing
useful to pull or it may be related to what I see if I attempt to pull
from a modified repository with
i:\tmp\gittest\clone_from_local
>git pull
error: poll failed, resuming: Invalid argument
error: poll failed, resuming: Invalid argument
This will continue until I kill it with a Ctrl-C which results in
fatal: The remote end hung up unexpectedly
fatal: protocol error: bad pack header
There seems to be a problem comminicating witht he daemon process/thread.
FWIW, fetch behaves similarly when accessing a modified repository
i:\tmp\gittest\clone_from_local
>git fetch
error: poll failed, resuming: Invalid argument
error: poll failed, resuming: Invalid argument
fatal: The remote end hung up unexpectedly
fatal: protocol error: bad pack header
but seems to work correctly when accessing an unmodified directory
i:\tmp\gittest\clone_from_local
>git fetch ..\clone_from_remote_unmodified master
From ..\clone_from_remote_unmodified
* branch master -> FETCH_HEAD
The .diff shows an implementation of poll() so this might be where the
problem lies.
Dave Yeo
> In<88LOl.28028$PH1.4928@edtnps82>, on 05/14/2009
> at 02:14 AM, Dave Yeo<dave....@gmail.com> said:
>
> Hi,
>
>> When I built Git with prefix=/git it worked (clone) fine without needing
>> anything added to the %PATH%. I did experiment with %PATH% trying to get
>> pull to work, no difference.
>
> Note that I am using the Japanese build as a reference. If you post your
> diffs and configure settings, I'll apply them to the sources and this
> might help with analysis.
At the time i just applied the diffs that came with the Japanese build,
which applied cleanly with just a slight fuzz factor. (git-1.6.2.2 was
the source I had handy). I don't remember using any configure settings
besides prefix, since previous versions of git installed a lot of crap
with no uninstall script.
Anyways I'm downloading the latest source (1.6.3.1) and will apply the
latest patches and also use the configure settings that our Japanese
friends used, in particular the LN_S=ln4exe.
I also see they recommend to update make though I never noticed any
problems with the one I have installed.
I'll have to revisit that, long ago I installed a poll emulating library
just for git which configure finds. http://www.clapper.org/software/poll/
Dave, who seems not to have much time lately :)
Dave Yeo
> At the time i just applied the diffs that came with the Japanese build,
> which applied cleanly with just a slight fuzz factor. (git-1.6.2.2 was
> the source I had handy). I don't remember using any configure settings
> besides prefix, since previous versions of git installed a lot of crap
> with no uninstall script.
> Anyways I'm downloading the latest source (1.6.3.1) and will apply the
> latest patches and also use the configure settings that our Japanese
> friends used, in particular the LN_S=ln4exe.
> I also see they recommend to update make though I never noticed any
> problems with the one I have installed.
I just told configure where to find perl and not to use tcltk.
For some reason with the newer GCC's configure trys to use -pthread so I
edited it to -lpthread and hardcoded ln4exe in the makefile.
Unluckily now I can't build the daemon,
daemon.c:575: error: field 'address' has incomplete type
daemon.c: In function 'service_loop':
daemon.c:853: error: storage size of 'ss' isn't known
daemon.c:855: warning: pointer targets in passing argument 3 of 'accept'
differ in signedness
daemon.c:853: warning: unused variable 'ss'
daemon.c: In function 'main':
daemon.c:928: warning: passing argument 2 of 'git_os2_main' from
incompatible pointer type
daemon.c: In function 'git_os2_main':
daemon.c:1103: error: storage size of 'ss' isn't known
daemon.c:1103: warning: unused variable 'ss'
make: *** [daemon.o] Error 1
Stupid GCC, if ss is unused why worry about the size. I was getting a
lot of warnings with gcc 3.3.5 and the build died early so now am using
4.3.3
Dave
Steven Levine
at 11:54 PM, Dave Yeo <dave....@gmail.com> said:
Hi,
>> The .diff shows an implementation of poll() so this might be where the
>> problem lies.
>>
>I'll have to revisit that, long ago I installed a poll emulating library
>just for git which configure finds. http://www.clapper.org/software/poll/
The implementation is very close to what the library uses.
>Dave, who seems not to have much time lately :)
Me too. :-)
Steven Levine
at 01:22 AM, Dave Yeo <dave....@gmail.com> said:
Hi,
>I just told configure where to find perl and not to use tcltk. For some
>reason with the newer GCC's configure trys to use -pthread so I edited
>it to -lpthread and hardcoded ln4exe in the makefile. Unluckily now I
>can't build the daemon,
Perhaps this is why the readme contains
* configured with '--without-pthreads'
BTW, I think the porter's name is sava (t.ebisawa). He did the dbcs
enabled version of VirtualBox.
Dave Yeo
>> >I'll have to revisit that, long ago I installed a poll emulating library
> The implementation is very close to what the library uses.
>
Actually I misremembered, I had to add it to the linking stage
Dave
Dave Yeo
> Unluckily now I can't build the daemon,
>
> daemon.c:575: error: field 'address' has incomplete type
> daemon.c: In function 'service_loop':
With GCC 3.3.5 it builds fine now, just 4.3.3 was picky about the above.
Will test later...
Dave
Dave Yeo
> at 02:14 AM, Dave Yeo<dave....@gmail.com> said:
>
> Hi,
>
>> When I built Git with prefix=/git it worked (clone) fine without needing
>> anything added to the %PATH%. I did experiment with %PATH% trying to get
>> pull to work, no difference.
>
> Note that I am using the Japanese build as a reference. If you post your
> diffs and configure settings, I'll apply them to the sources and this
> might help with analysis.
>
>> There are also environment variables to tell Git where it is running,
>> see the install instructions under running without make install
>
> There are lots of environment variables. :-) GIT_EXEC_PATH does not work
> here. I suspect the reason may be in in strip_path_suffix which does not
> appear to be case-insensitive.
>
> Back to your original problem, which I can duplicate with git clone
> followed by
>
> i:\tmp\gittest\clone_from_remote
>> git pull git://repo.or.cz/cclive.git master
> From git://repo.or.cz/cclive
> * branch master -> FETCH_HEAD
> - not something we can merge06f607ef23aeb0c036
Yes I'm now getting a similar error, (attempting to update cairo)
[I:\git\cairo]git pull
warning: $GIT_FIND is not defined. Assume GIT_FIND=/Moztools/find.exe.
warning: $GIT_SORT is not defined. Assume GIT_SORT=F:/USR/BIN/gsort.exe.
remote: Counting objects: 116, done.
remote: Compressing objects: 100% (78/78), done.
remote: Total 78 (delta 63), reused 0 (delta 0)
Unpacking objects: 100% (78/78), done.
warning: $EMAIL is not set.
From git://anongit.freedesktop.org/git/cairo
088d2a6..31596cf master -> origin/master
- not something we can merge0ae77a3388eadc0d8b
Interesting assumptions as /Moztools is not on the path but exists and
gsort also exists though I can't remember it.
.git/objects has a bunch of subdirs with 2 hex digit names each
containing at least on packed file. File reports that they are
VAX COFF executable not stripped - version 1590 :) (actually various
version numbers)
I don't get any errors with git fetch besides the warnings about not
setting $GIT_FIND etc.
I probably need to read up on GIT, though really all I want to do is
keep a repositry in synch and do the occasional diff.
>
> i:\tmp\gittest\clone_from_local
>> git fetch ..\clone_from_remote_unmodified master
> From ..\clone_from_remote_unmodified
> * branch master -> FETCH_HEAD
>
> The .diff shows an implementation of poll() so this might be where the
> problem lies.
>
I haven't seen any poll() errors, perhaps our Japanese friends have a
different TCPIP stack from you?
Anyways I guess the next step is to look into the code and place a few
strategic printfs.
Dave
Steven Levine
at 01:49 AM, Dave Yeo <dave....@gmail.com> said:
Hi,
>Interesting assumptions as /Moztools is not on the path but exists and
>gsort also exists though I can't remember it.
I noticed some code in git to prefix PATH with some of the compile time
variables, such as BINDIR. Perhaps that's where Moztools is coming from.
>..git/objects has a bunch of subdirs with 2 hex digit names each
>containing at least on packed file. File reports that they are VAX COFF
>executable not stripped - version 1590 :) (actually various version
>numbers)
This may be normal after a successful pull. Someone said
<snip>
git is heavily optimized for fast storage and retrieval on a per-command
basis. However, over a long period of time, it can be useful to perform
further optimizations, including packing all git objects into single
"packfile" for fast retrieval and less wasted disk space. </snip>
To collect everything into a single packfile, use git gc. Of course, git
gc does not seem to be working here. It claims premature end of input.
>I don't get any errors with git fetch besides the warnings about not
>setting $GIT_FIND etc.
git fetch works fine here when accessing a remote repository, as does git
merge. It's just accessing a local clone that fails with the poll error.
>I probably need to read up on GIT, though really all I want to do is
>keep a repositry in synch and do the occasional diff.
Based on what little I know of git, at the moment, all you should need to
use is git clone the first time and the git pull after that. I think that
pull is essentially a shorthand for git fetch and git merge.
>I haven't seen any poll() errors, perhaps our Japanese friends have a
>different TCPIP stack from you?
Perhaps, but it's not likely. The stack is 32-bit and probably at about
the eCS 1.2R level. IAC, I'll test on an rc6+ box to verify that nothing
changes.
Alex Taylor
wrote:
> >Excellent, will download and test. Seems like a bunch of other useful
> >stuff there as well
>
> Definitely. Can anyone read the site well enough to find and email
> address? There a defect in the diff that causes the GIT_SHELL logic to
> fail.
There appears to be no email address listed on that site.
However, the bochs page does include what looks like a 'back' link to
this site <http://hp.vector.co.jp/authors/VA003720/lpproj/> which has
an email address at the bottom. I have no idea if this is the same
person, though.
--
Alex Taylor
Fukushima, Japan
http://www.socis.ca/~ataylo00
Please take off hat when replying.