Re: Git
- From: Dave Yeo <dave.r.yeo@xxxxxxxxx>
- Date: Thu, 14 May 2009 23:54:17 GMT
On 05/14/09 12:23 pm, Steven Levine wrote:
In<88LOl.28028$PH1.4928@edtnps82>, on 05/14/2009
at 02:14 AM, Dave Yeo<dave.r.yeo@xxxxxxxxx> 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.
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_remotegit pull git://repo.or.cz/cclive.git masterFrom 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_localgit pull ..\clone_from_remote masterFrom ..\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_localgit pullerror: 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_localgit fetcherror: 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_localgit fetch ..\clone_from_remote_unmodified masterFrom ..\clone_from_remote_unmodified
* branch master -> FETCH_HEAD
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/
Dave, who seems not to have much time lately :)
.
- References:
- Prev by Date: Re: Git
- Next by Date: Re: Git
- Previous by thread: Re: Git
- Next by thread: Re: Git
- Index(es):
Relevant Pages
|