Problem pushing things

Darkhog

git did not exit cleanly (exit code 128) (47 ms @ 18.02.2014 01:46:50) That what I am getting when trying to push things via Tortoise Git (Windows) to bitbucket. Last commited like in November last year (2013) and it worked fine. Haven't change anything in my TortoiseGIT configuration since then, but it now spits out git did not exit cleanly (exit code 128) (47 ms @ 18.02.2014 01:46:50) Can you help me?

Darkhog

Here's what I got from atlassian support (JIRA):

Hi there,

Sometimes Git will create some sort of 'lock' or 'index_lock' file which prevents from Git operations. Can you check your .git folder for this and delete it?

You can also view this post on stack overflow for more solutions: http://stackoverflow.com/questions/14848263/tortoisegit-trouble-git-did-not-exit-cleanly-exit-code-128(it could be a variety of things, such as incorrect path to your ssh RSA keys)

Thanks,
Jesse

Darkhog added a comment - 18/Feb/14 6:53 PM

Already did as I did extensive googling of this issue before submitting it. The only other was that SSH invalidation that Github did after they were hacked (which doesn't apply here because a) I use bitbucket b) I am logging via HTTPS) and that lock file.

Sorry, but there is no such file.

Tried various things to solve it: double checked info I entered into Tortoise git, reinstalled git and TrotoiseGit, even tried to use ssh to log here (semi-success here as Tortoise showed different error, in window: "Disconnected: No supported authentication methods available (server sent publickey". Weird because ssh -T git@bitbucket.orgshowed:
logged in as [redacted].

You can use git or hg to connect to Bitbucket. Shell access is disabled.which according to docs is what it was supposed to show). Nothing works.

Jesse Yowell [Atlassian] added a comment - 18/Feb/14 7:44 PM

The 'Disconnected: No supported authentication methods available (server sent publickey' error seems to give us more of a clue.

Have you checked to see if Pageant is running correctly? It might be that Pageant is not serving up your ssh key file to the server. It might be worth reinstalling Pageant and seeing if this solves the issue.

If all else fails, can you try going into the SSH settings of ToirtoiseGit and removing the link to either ssh.exe or Pageant and seeing what error it gives you?

Thanks,
Jesse

Darkhog added a comment - 18/Feb/14 7:48 PM

What is a Pageant? Seriously, all the time I was aunthenticating via HTTPS and never used SSH for that, only after I try to resolve this issue.

Darkhog added a comment - 18/Feb/14 7:48 PM

What is a Pageant? Seriously, all the time I was aunthenticating via HTTPS and never used SSH for that, only after I try to resolve this issue.

Jesse Yowell [Atlassian] added a comment - 18/Feb/14 7:54 PM

Ah, ok – I assumed you were working with SSH too. Disregard Pageant if that is the case.

What happens when you try to clone a fresh repo and push? Do you get a similar error upon cloning or is the error only on pushing?

Thanks,
Jesse

Darkhog added a comment - 18/Feb/14 10:33 PM

I am receiving same error upon trying to clone my repo.

Jesse Yowell [Atlassian] added a comment - 18/Feb/14 11:29 PM

What is the account name / repo? I'll take a look to make sure there isn't a lock on the server side.. being unable to clone seems strange.

Thanks,
Jesse

Darkhog added a comment - 18/Feb/14 11:32 PM

Account name is ]redacted] and repo is named [Redacted] (capital R in case it's important)

Jesse Yowell [Atlassian] added a comment - 18/Feb/14 11:42 PM

Got it.. looks like it's a local issue, as the server repo appears fine.

Can you try the following:

git config –global http.postBuffer 524288000

(I'm not sure about the equivalent setting in TortoiseGit, or if it allows a command-line input)

Thanks,
Jesse

Darkhog added a comment - 18/Feb/14 11:49 PM

error: key doesn't contain a section -global

That's what I'm getting. I've executed it where local copy of my repo, which worked fine last time I pushed (7 Nov 2013). I have literally no experience with commandline git (otherwise I wouldn't need GUI tool like Tortoise), so I need noob-friendly instructions.

Thank you for trying to help though, I hope you'll get bonus for that afterwards.

Jesse Yowell [Atlassian] added a comment - 19/Feb/14 12:37 AM

Odd, you may want to consider trying another Git-GUI app such as SourceTree (http://sourcetreeapp.com/)

The error you are getting is still a bit vague.. as it may be a setting in TortoiseGit or it may be a lockfile under your .git/refs/heads that is causing this issue. I am scouring the same number of online/stackoverflow documents, but it doesn't seem to be a clear answer.

Have you tried just starting over and reinstalling TortoiseGit alltogether?

Thanks,
Jesse

Darkhog added a comment - 19/Feb/14 11:43 AM

Yes, but that didn't work. If you had to guess which settings could cause such issue?

Jesse Yowell [Atlassian] added a comment - 19/Feb/14 7:44 PM

The most common issue I've seen (with that error), is the lockfile found under /.git/refs/heads in your current working copy of the repo.

If not, it might just be something as simple as the URL you are using to clone. How is the URL written in TortoiseGit that you're using to clone? (possibly send us a screenshot of the configuration screen?)

Thanks,
Jesse

Darkhog added a comment - 19/Feb/14 8:04 PM

Url is [redacted, my repo url] - but I don't think that's it. It worked fine in November last year, as my commit history on your side does prove, I didn't change settings since then and now it doesn't work (I tried to fiddle with settings on my part ONLY after I saw this error).. No lock file on my part either.

Jesse Yowell [Atlassian] added a comment - 19/Feb/14 8:17 PM

Yeah.. that does look fine. I'd say try to omit the 'password' part of the URL and try. Also, what does your '.git/config' file look like?

Thanks,
Jesse

Darkhog added a comment - Yesterday 4:42 PM - edited

[core]
repositoryformatversion = 0
filemode = false
bare = false
logallrefupdates = true
symlinks = false
ignorecase = true
hideDotFiles = dotGitOnly
[remote "origin"]
url = [redacted, my repo url]
fetch = +refs/heads/:refs/remotes/origin/
prune = false
[tgit]
commitshowpatch = true

//edit: And trying without password shows exact same error.

Darkhog added a comment - Yesterday 6:16 PM

Could this bear any significance? https://bitbucket.org/site/master/issue/4537/about-the-exit-code-128

Jesse Yowell [Atlassian] added a comment - Yesterday 7:57 PM

Reading that public issue has given me a couple new ideas – first off, I went ahead and did some cleanup on your repo. I'd try cloning now, if you could, and seeing if anything changes right off the bat.

Second, can you send me output from the following:

ping bitbucket.org

traceroute bitbucket.org

I'm starting to think it may be slightly network related..

Cheers,
Jesse

Darkhog added a comment - Yesterday 8:14 PM

Cloning did nothing and here are results:

Microsoft Windows [Wersja 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. Wszelkie prawa zastrzeżone.

C:\Users\Darkhog>ping bitbucket.org

Badanie bitbucket.org[131.103.20.167] z 32 bajtami danych:
Odpowiedź z 131.103.20.167: bajtów=32 czas=190ms TTL=51
Odpowiedź z 131.103.20.167: bajtów=32 czas=189ms TTL=51
Odpowiedź z 131.103.20.167: bajtów=32 czas=191ms TTL=51
Odpowiedź z 131.103.20.167: bajtów=32 czas=190ms TTL=51

Statystyka badania ping dla 131.103.20.167:
Pakiety: Wysłane = 4, Odebrane = 4, Utracone = 0
(0% straty),
Szacunkowy czas błądzenia pakietów w millisekundach:
Minimum = 189 ms, Maksimum = 191 ms, Czas średni = 190 ms

C:\Users\Darkhog>traceroute bitbucket.org
Nazwa 'traceroute' nie jest rozpoznawana jako polecenie wewnętrzne lub zewnętrzne,
program wykonywalny lub plik wsadowy.

C:\Users\Darkhog>tracert bitbucket.org

Śledzenie trasy do bitbucket.org[131.103.20.167]
z maksymalną liczbą 30 przeskoków:

1 * * * Upłynął limit czasu żądania.
2 9 ms 7 ms 10 ms 89-75-11-97.infra.chello.pl [89.75.11.97]
3 190 ms 191 ms 189 ms 84.116.252.158
4 198 ms 189 ms 195 ms 84.116.252.166
5 191 ms 193 ms 196 ms 84.116.252.34
6 188 ms 193 ms * 84.116.252.37
7 190 ms 192 ms 200 ms 84.116.136.141
8 118 ms * 130 ms us-nyc01b-rd1-gi-2-0-0.aorta.net[84.116.130.26]
9 188 ms 189 ms 211 ms 84.116.137.222
10 190 ms 188 ms 188 ms xe-0.equinix.snjsca04.us.bb.gin.ntt.net[206.223.116.12]
11 200 ms 191 ms 198 ms ae-7.r20.snjsca04.us.bb.gin.ntt.net[129.250.5.52]
12 191 ms 189 ms 193 ms ae-4.r21.asbnva02.us.bb.gin.ntt.net[129.250.4.102]
13 188 ms 186 ms 186 ms ae-2.r04.asbnva02.us.bb.gin.ntt.net[129.250.4.207]
14 187 ms 193 ms 188 ms po-1.a00.asbnva03.us.da.verio.net[129.250.27.130]
15 202 ms 189 ms 192 ms 131.103.20.156
16 188 ms 189 ms 196 ms 131.103.20.167

Śledzenie zakończone.

Darkhog added a comment - Yesterday 8:15 PM

I am using Google's DNSs by the way.

Jesse Yowell [Atlassian] added a comment - Yesterday 8:27 PM

The ping/traceroute is a little high, but I'm not certain that this is the cause of the issue.

For sanity's sake, would it be possible to setup another client (http://downloads.atlassian.com/software/sourcetree/windows/SourceTreeSetup_1.4.1.exe) and enter in your URL and try to clone that way? This way we could determine if it's an actual network issue, or if it's just a client configuration issue with TortoiseGit.

Cheers,
Jesse

Darkhog added a comment - Yesterday 8:34 PM

OK, I'll try it, but I'm pretty sure problem exists between your side and mine (possibly on ISP level) if not on your side as it worked previously great and I didn't change anything in config until I found about this problem. Will inform you if this work.

Darkhog added a comment - Yesterday 8:39 PM

git -c diff.mnemonicprefix=false -c core.quotepath=false push -v --tags --set-upstream origin master:master
Completed with errors, see above.

Nothing more than that (in SourceTree)

Jesse Yowell [Atlassian] added a comment - Today 8:16 PM - edited

Is there anyway, you can place the following before your Git command:

GIT_CURL_VERBOSE=1 git clone [redacted, my repo url]

Unfortunately, doing some command-line Git would be the best for troubleshooting this issue.. that above command will spitout a bunch of information which is vital for troubleshooting..

Thanks,
Jesse

Darkhog added a comment - an hour ago

In standard Windows message box (probably from Windows itself as it is in Polish) message that amount to No entry point for EVP_md2 in library LIBEAV32.dll (in case you or someone you know who can translate it better, original message is Nie znaleziono punktu wejścia procedury EVP_md2 w bibliotece LIBEAV32.dll). In title bar it refers git-remote-https.exe (my git version is Git-1.9.0-preview20140217 (copied installer name used to install it), it should be noted that I updated to it only after issue happened thinking it will solve it, my problem, previous was Git-1.7.11-preview20120620 (again copied installer's name, except extension)).

Jesse Yowell [Atlassian] added a comment - an hour ago

Interesting. Have you tried Git 1.8? I'm curious as to why it would have an issue with that .dll, strangely this may just be a Git binary issue.

Cheers,
Jesse

Darkhog added a comment - 33 minutes ago - edited

You know how there are those sites that offer DLL files for download? I got LIBEAY32.dll from one of these and copied where git-remote-https.exe is located and it seems to work for now (my commit history should show that as there's new commit ). I have no idea what caused original issue but as it seems to work fine and I know what I need to try to debug issue if happens again, you may close this now.

I hope you'll get a hefty bonus for dealing with such troublesome client like me. No, really I hope so.