dulwich-users team mailing list archive

[Crispin Wellington <crispinw@xxxxxxxxxx>]

OK. digging a bit further it seems that the push is actually 'working'. If
I don't make any commit, just pull and then push, I get the aforementioned
error. I suppose there is nothing to send, but dulwich advertises that
there is something to send and then sends nothing causing an remote
unexpected eof error? perhaps...

If I pull, change a file, and commit it. Then push. I also get an error.
But the commit does get pushed and appears on the server. With a commit I
get "UpdateRefsError: HEAD, refs/heads/develop failed to update".

It seems the remote server has trouble updating its refs? If I pull the
repo fresh (using the same pull code)  I get the repo BEFORE the commit. If
I then issue another change and commit, and push, I again get the
UpdateRefsError, and on bitbucket, the old commit has now dissapeared and
been REPLACED by the new one!!!

It's like the remote is accepting the blob, adding it to the repository,
but not updating its refs to point at that new HEAD.

debugging in as before to this "UpdateRefsError" I get the following
response:

ipdb> resp.code
200
ipdb> resp.msg
'OK'
ipdb> resp.url
'https://bitbucket.org/cwellington/raven.git/git-receive-pack'
ipdb> resp.read()
"0088\x02error: refusing inconsistent update between symref 'HEAD'
(0000000..1ff6474) and its target 'refs/heads/master'
(c7c2899..1ff6474)\n0074\x01000eunpack ok\n0028ng HEAD inconsistent aliased
update\n0035ng refs/heads/master inconsistent aliased update\n00000000"

Any ideas?

Crispin



On Wed, Oct 16, 2013 at 10:01 AM, Crispin Wellington <crispinw@xxxxxxxxxx>wrote:

> So I put the debugger in to break at dulwich/client.py line 924 ish...
> just after 'resp' response object is created. Seems to be the remote server
> telling me it has had problems unpacking HEAD:
>
> > /.../python2.7/site-packages/dulwich/client.py(926)send_pack()
>     925
> --> 926         resp_proto = Protocol(resp.read, None)
>     927         self._handle_receive_pack_tail(resp_proto,
> negotiated_capabilities,
>
> ipdb> resp
> <addinfourl at 30480288 whose fp = <socket._fileobject object at
> 0x1ce5650>>
> ipdb> resp.code
> 200
> ipdb> resp.msg
> 'OK'
> ipdb> resp.url
> 'https://bitbucket.org/username/project.git/git-receive-pack'
> ipdb> resp.read()
> '00a6\x010031unpack eof before pack header was fully read\n001bng HEAD
> unpacker error\n0029ng refs/heads/develop unpacker error\n0028ng
> refs/heads/master unpacker error\n00000000'
> ipdb>
>
> I'm not familiar with the git http(s) 'dumb' protocol. Is it documented
> anywhere?
>
> Regards
>
> Crispin
>
>
> On Wed, Oct 16, 2013 at 5:26 AM, Jelmer Vernooij <jelmer@xxxxxxxxx> wrote:
>
>> On Tue, Oct 15, 2013 at 06:16:01PM +0800, Crispin Wellington wrote:
>> > I've been trying to get a full round trip happening from/to a repo on
>> > bitbucket over Https. Firstly my Https client (that remembers username
>> and
>> > password):
>> >
>> > ---------------
>> >
>> > class HttpsGitClient(HttpGitClient):
>> >     USER_AGENT = 'git/1.7.9.5'
>> >
>> >     def __init__(self, base_url, username=None, password=None,
>> dumb=None,
>> > *args, **kwargs):
>> >         parsed = urlparse.urlparse(base_url)
>> >         assert parsed.scheme in ('http', 'https')
>> >         self.username = username or parsed.username
>> >         self.password = password or parsed.password
>> >
>> >         # strip username:password if its there
>> >         if parsed.username:
>> >             base_url = urlparse.urlunparse([parsed[0],
>> >                                             parsed[1].split('@',1)[1],
>> >                                             parsed[2],
>> >                                             parsed[3],
>> >                                             parsed[4],
>> >                                             parsed[5]])
>> >
>> >         return HttpGitClient.__init__(self, base_url, dumb, *args,
>> **kwargs)
>> >
>> >     def _perform(self, req):
>> >         """Perform a HTTP(S) request with auth"""
>> >         base64string = base64.encodestring('%s:%s' % (self.username,
>> > self.password)).replace('\n', '')
>> >         req.add_header("Authorization", "Basic %s" % base64string)
>> >
>> >         if self.USER_AGENT:
>> >             req.add_header('User-Agent', self.USER_AGENT)
>> >
>> >         return HttpGitClient._perform(self,req)
>> >
>> > -----------
>> >
>> > This adds a user agent string (bitbuckets nginx rejects it otherwise)
>> and
>> > adds the authorization in the http headers.
>> See https://bitbucket.org/site/master/issue/6666/ for the background on
>> this.
>>
>> Ideally I'd like HttpGitClient to just take a urllib http client; that way
>> HttpGitClient doesn't have to support every authentication method under
>> the sun.
>>
>> > Doing the pull as follows works fine:
>> >
>> >         client = HttpsGitClient(url, ....)
>> >         parse = urlparse(url)
>> >         remote_refs = client.fetch(parse.path, self.repo,
>> > progress=sys.stderr.write)
>> >         self.repo['HEAD'] = remote_refs['HEAD']
>> >         self.repo._build_tree()
>> Note that with the porcelain branch of Dulwich you can now just use
>> dulwich.porcelain.clone().
>>
>> > Now when I try and do the push as follows:
>> >
>> >         client = HttpsGitClient(url, ...)
>> >         parse = urlparse(url)
>> >
>> >         def wantmaster(oldrefs):
>> >             return self.repo.get_refs()
>> >
>> >         client.send_pack(parse.path, wantmaster,
>> > self.repo.object_store.generate_pack_contents)
>> >
>> > Traceback (most recent call last):
>> >   File "repository.py", line 257, in <module>
>> >     r.push('https://bitbucket.org/username/project.git',
>> > username="username", password=sys.argv[1])
>> >   File "/.../repository.py", line 85, in push
>> >     self.repo.object_store.generate_pack_contents)
>> >   File "/.../python2.7/site-packages/dulwich/client.py", line 924, in
>> > send_pack
>> >     progress)
>> >   File "/.../python2.7/site-packages/dulwich/client.py", line 345, in
>> > _handle_receive_pack_tail
>> >     self._report_status_parser.check()
>> >   File "/.../python2.7/site-packages/dulwich/client.py", line 99, in
>> check
>> >     raise SendPackError(self._pack_status)
>> > dulwich.errors.SendPackError: unpack eof before pack header was fully
>> read
>> >
>> > Has anyone has any luck pushing to bitbucket using HTTPS?
>> > What is the meaning of this error?
>>
>> Can you check what the actual contents are of the response? Is it just
>> some sort of authentication error?
>>
>> Cheers,
>>
>> Jelmer
>>
>>
>
>


-- 
*Crispin Wellington*
Senior Software Developer *|* *Sign**IQ
**T:* +61 8 6230 2478
*F:** *+61 8 9221 7484 *|* *W:** *signiq.com
*E:** *crispinw@xxxxxxxxxx

Level 1 / 36 Pier Street, Perth WA 6000

LinkedIN <http://www.linkedin.com/groups?home=&gid=4572317&trk=anet_ug_hm/>
*|* Twitter <https://twitter.com/SignIQ/> *|*
Google+<https://plus.google.com/u/1/117274575392609123823/>

*SignIQ Pty Ltd  **|** ABN 98 114 916 504
**
*This message contains confidential information and is intended only for
the individual named. If you are not the named addressee you should not
disseminate, distribute or copy this email. Please notify the sender
immediately if you have received this email by mistake and delete it from
your system. Email transmissions cannot be guaranteed to be secure or
error-free as information can be intercepted, corrupted, lost, destroyed.
arrive late or incomplete, or contain viruses. The sender does not
therefore accept liability for any errors or omissions in the contents of
this message.