top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

How to solve "Recv failure: Connection reset" issue?

0 votes
1,406 views

Getting Recv Failure error while cloning the repository from bitbucket. Any idea to resolve this?

posted Nov 21, 2018 by anonymous

Looking for an answer?  Promote on:
Facebook Share Button Twitter Share Button LinkedIn Share Button

Similar Questions
0 votes
How to delete a branch permanently in mercurial/bitbucket?

I need to delete a branch in mercurial in order to move it into a private repository. I have heard of the "hg strip" method but Bitbucket is warning me that this operation will affect branches I would prefer keeping...

So I just have no idea right now how to prune this specific branch out of my public repo! :(

Any suggestions for doing this would be much appreciated!

+1 vote
Git reset should be able to ignore file permissions

Recently I had to write some automation scripts and I found that git reset --hard actually restores each file's permissions.

That is causing both the created and the last-modified dates of the file to get changed to the time of the git reset.

This behavior is easy to demonstrate:

echo "test" > myfile
chmod 777 myfile

git add myfile && git commit -m "Test" & the only solution I'm able to think about is actually restoring the permissions of each file to the ones git thinks they should have before doing the git reset.

Maybe I'm wrong and there is a way for doing what I want, if so, please correct me. But if there isn't, should this be implemented? Are there any reasons for not doing it?

+1 vote
git reset for index restoration?

If I have a git repository with a clean working tree, and I delete the index, then I can use git reset (with no arguments) to recreate it. However, when I do recreate it, it doesn't come back the same. I have not analyzed this in detail, but the effect is that commands like git status take much longer because they must read objects out of a pack file.

In other words, the index seems to not realize that the index (or at least most of it) represents the same state as HEAD. If I do git reset --hard, the index is restored to the original state (it's byte-for-byte identical), and the pack file is no longer read.

Before I try to dig in to why this should be so, does anyone happen to know off the top of their head? Does this constitute a bug in git, or a bug in my understanding of git?

+2 votes
Git merge commit message issue

In the past, when we do the merge in git, if conflicts occurred, when we commit, the conflict list will be appended to the default commit message automatically.

eg:
Conflicts:
....a.java
....b.java

Today, after using Git 2.3.0 for a merge, it seems now the conflict list was commented out by default.

I just searched a bit in the release notes, don't know whether below item has to do with this change.

"git interpret-trailers" learned to properly handle the "Conflicts:"
block at the end.

We quite rely on the default generated conflict list to reminder us about the "history".

Is this the default behavior now (conflict list commented out)?

...