Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

git 1.7.9: error: RPC failed; result=22, HTTP code = 401, LOG has Password Mismatch #2

Open
GoogleCodeExporter opened this issue Mar 31, 2016 · 7 comments

Comments

@GoogleCodeExporter
Copy link

What steps will reproduce the problem?
1. install 1.7.9
2. try to push to repo
3. will fail with text "ref 22" and "401" looking in the error log, if you have 
one, will say "authentication failure for <therepo>/git-receive-pack: Password 
Mismatch"

What is the expected output? What do you see instead?

should push normally

What version of the product are you using? On what operating system?

previously 1.7.6, upgraded to 1.7.9, all attempts fail

Please provide any additional information below.

this seems to affect all operating systems, I have a windows machine with 
msysgit installed and 1.7.9 would fail to push with the exact same problem, 
downgraded to 1.7.6 and it would push successfully.

a linux box a co-worker uses had 1.7.9 upgraded on his debian squeeze box, 
immediately he started to have the same problem

I have a macbook, I had previously 1.7.6 installed and when I upgraded my 
macports, it installed 1.7.9 and then I had the same issue.

on our local office development server (it's ubuntu 11.10) I had git 1.7.5.4 
installed throughout all our tests, perhaps upgrading them all to 1.7.9 will 
fix the problem?

is GIT sensitive to version differences across platforms and can only work with 
versions similar to each other? I thought the version wouldnt make much 
difference albeit with some exceptions.

Original issue reported on code.google.com by chris.al...@gmail.com on 15 Feb 2012 at 1:43

@GoogleCodeExporter
Copy link
Author

We are having the same issue...just to note that it does not prompt for 
password...  I wonder if the newer versions are not reading the 401 correctly.

Original comment by smbambl...@gmail.com on 24 Feb 2012 at 3:14

@GoogleCodeExporter
Copy link
Author

yes, just to clarify because I realise that I didn't do that before, but also 
with us it was not prompting for the password, just failing with that error and 
not prompting for anything.

Original comment by chris.al...@gmail.com on 24 Feb 2012 at 3:17

@GoogleCodeExporter
Copy link
Author

Chris...would you mind sharing your apache conf and are you using smart http?  
http://pastebin.com/dz2NXJES this is what ours looks like.

Original comment by smbambl...@gmail.com on 24 Feb 2012 at 3:39

@GoogleCodeExporter
Copy link
Author

Also we don't seem to be the only ones...

http://stackoverflow.com/questions/9364901/git-push-doesnt-ask-for-password-and-
gives-401-fine-when-password-typed-inline

Original comment by smbambl...@gmail.com on 24 Feb 2012 at 3:40

@GoogleCodeExporter
Copy link
Author

this is our virtualhost configuration: http://pastebin.com/cseNxQJH

you have a lot more options than us, maybe because it's publically facing? ours 
is only used internally for the programmings in the office.

Original comment by chris.al...@gmail.com on 24 Feb 2012 at 3:44

@GoogleCodeExporter
Copy link
Author

we found the following "temporary" solution was to downgrade msysgit to 1.7.6 
apparently it happened with all our windows machines using 1.7.9 and 
downgrading to 1.7.6 solved it for the meantime.....

the solution on my macbook was also to downgrade to the previous version

Original comment by chris.al...@gmail.com on 24 Feb 2012 at 3:50

@GoogleCodeExporter
Copy link
Author

this error is still present in the 1.7.10+ version of git and the solution was 
downgrade to 1.7.7 on my mac and probably (I can't test this) 1.7.6 on windows, 
however this time I had a chance to do more testing, so here is what I found 
out.

the problem is not anything to do with curl, I suppose you have setup access to 
your repository for anonymous read and authenticated write, then triggering the 
Basic auth you've setup for write access like this:

curl --user u:p http://domain.com/repo.git/git-receive-pack

with the correct credentials, you'll login correctly, however without the 
"--user u:p" part of that command it'll fail with the predictable apache 401 
error page.

if you try to open this url in the browser:

http://u:p@domain.com/repo.git/git-receive-pack

then it'll work, if you remove the username and password part of the url, it'll 
predictably fail again with the apache 401 error page, however this time your 
browser interprets the html instead of dumping it to the command line

so the problem is not the auth and the problem is not curl, the problem is with 
git-core and the version of it.

if you downgrade to 1.7.7.2 on my macbook and 1.7.6.x on windows then you will 
eliminate this problem.

when you try to setup a git remote such as 

http://username@domain.dom/repo.git

then try to push "git push origin master" or similar, you'll be prompted for 
the password and everything will work fine

Original comment by chris.al...@gmail.com on 4 Jun 2012 at 6:36

GoogleCodeExporter pushed a commit that referenced this issue Mar 31, 2016
GoogleCodeExporter pushed a commit that referenced this issue Mar 31, 2016
GoogleCodeExporter pushed a commit that referenced this issue Mar 31, 2016
GoogleCodeExporter pushed a commit that referenced this issue Mar 31, 2016
GoogleCodeExporter pushed a commit that referenced this issue Mar 31, 2016
GoogleCodeExporter pushed a commit that referenced this issue Mar 31, 2016
When ac49f5c (rerere "remaining", 2011-02-16) split out a new
helper function check_one_conflict() out of find_conflict()
function, so that the latter will use the returned value from the
new helper to update the loop control variable that is an index into
active_cache[], the new variable incremented the index by one too
many when it found a path with only stage #1 entry at the very end
of active_cache[].

This "strange" return value does not have any effect on the loop
control of two callers of this function, as they all notice that
active_nr+2 is larger than active_nr just like active_nr+1 is, but
nevertheless it puzzles the readers when they are trying to figure
out what the function is trying to do.

In fact, there is no need to do an early return.  The code that
follows after skipping the stage #1 entry is fully prepared to
handle a case where the entry is at the very end of active_cache[].

Help future readers from unnecessary confusion by dropping an early
return.  We skip the stage #1 entry, and if there are stage #2 and
stage #3 entries for the same path, we diagnose the path as
THREE_STAGED (otherwise we say PUNTED), and then we skip all entries
for the same path.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant