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.

Sign up for GitHub

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

Jump to bottom

" error setting certificate verify locations" for https fetch on XP #168

Closed
PhilipOakley opened this issue May 28, 2015 · 4 comments
Closed

" error setting certificate verify locations" for https fetch on XP #168

PhilipOakley opened this issue May 28, 2015 · 4 comments
Assignees
@dscho
Labels
bug git
Milestone
First release of ...

Comments

@PhilipOakley
Copy link

The https fetch now fails with a certificate error, while a git:// fetch succeeds.

Quick test of:

  $ git --version
  git version 2.4.2.windows.1
  $ uname -a
  MINGW32_NT-5.1 PhilipOakley 2.1.2(0.288/5/3) 2015-05-25 16:03 i686 Msys

(It's XP !)

gave:

  Philip@PhilipOakley MINGW32 /c/msysgit195/git (msvc-PR318-2b)
  $ git fetch https://github.com/dscho/git.git
  fatal: unable to access 'https://github.com/dscho/git.git/': error setting certificate verify locations:
    CAfile: C:/Program Files/Git/mingw32/libexec/ssl/certs/ca-bundle.crt
    CApath: none

Philip@PhilipOakley MINGW32 /c/msysgit195/git (msvc-PR318-2b)
$ git fetch git://github.com/dscho/git.git
From git://github.com/dscho/git
 * branch            HEAD       -> FETCH_HEAD

I previously had Git-2.4.0.2-dev-preview-32-bit.exe installed and it worked OK then (I have a scripted update that was working until minutes before the install/update).

There is no /ssl/ sub-directory to C:/Program Files/Git/mingw32/libexec in my install.

Do others see this difference between protocols (and their security setup)?, and is it only on my XP m/c?
@dscho
Copy link
Member

dscho commented May 29, 2015

Ah, darn. You know what happened? When I reworked the Windows-wide config based on @kblees' Pull Request, I broke XP support (the getenv() way to obtain the %PROGRAMDATA% value has an XP-only bug). I am on it.

@dscho
Copy link
Member

dscho commented May 29, 2015

Testing dscho/git@git-for-windows:master...xp-fix

@dscho dscho self-assigned this May 29, 2015
@dscho dscho closed this as completed in d32afb6 May 29, 2015
@dscho
Copy link
Member

dscho commented May 29, 2015

My test confirmed that it works now.

@PhilipOakley
Copy link
Author

Ah, darn. You know what happened? When I reworked the Windows-wide config based on @kblees' Pull Request, I broke XP support (the getenv() way to obtain the %PROGRAMDATA% value has an XP-only bug). I am on it.

Testing dscho@git-for-windows:master...xp-fix

Just did a clean download of the latest SDK, and it's fixed in that (i.e. my BringGitUptodate.sh script) works just fine again.

I did not get chance to create an insteller and try that version, so there's still a minor possiblility of some other nuance, but I consider it tested.

Many thanks Philip

jeffhostetler pushed a commit to jeffhostetler/git that referenced this issue Aug 13, 2019
@derrickstolee
Merge pull request git-for-windows#168: commit: remove parse_commit_n…
baf16c8 
…o_graph()

The parse_commit_no_graph() method was added in 43d3561 ("commit-graph
write: don't die if the existing graph is corrupt" 2019-03-25) as a way
to avoid persisting bad data across commit-graph files. That is, if the
commit-graph file has undetected corrupt data -- such as a flipped bit
in a parent int-id value -- then that data will persist to the next
commit-graph file. The parse_commit_no_graph() method was used to always
use the pack data directly instead.

Unfortunately, this comes at a significant performance cost. In both
time and memory, parsing from pack files is much slower than parsing
from the commit-graph file. In a repository with 4.5 million commits,
this can lead to Git taking up to 11gb of memory to rewrite the file.

Now that the incremental commit-graph file format exists, we can rely
on the quality of the commit-graph file if we follow the two-step
pattern of (1) write a commit-graph with "--split" and (2) run "git
commit-graph verify --shallow" to verify the tip file.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@dscho dscho

Labels
bug git
Projects
None yet
Milestone
First release of Git for Windows gene...
Development

No branches or pull requests
2 participants
@dscho @PhilipOakley