"Piotr Szlazak via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > http.cookieFile:: > The pathname of a file containing previously stored cookie lines, > - which should be used > - in the Git http session, if they match the server. The file format > - of the file to read cookies from should be plain HTTP headers or > - the Netscape/Mozilla cookie file format (see `curl(1)`). > + which should be used in the Git http session, if they match the server. > + The file format of the file to read cookies from should be plain HTTP > + headers or the Netscape/Mozilla cookie file format (see `curl(1)`). With line wrapping it is hard to see if there is any change above here, but I assume there is none? > + Set it to empty value, to enable in-memory cookies processing. Is it understandable what "in-memory cookies processing" means to expected audience of this manual page? I somehow doubt it (I certainly do not know what you wanted it to mean). https://curl.se/libcurl/c/CURLOPT_COOKIEFILE.html has this to say: By passing the empty string ("") to this option, you enable the cookie engine without reading any initial cookies. But http.cookiefile is also used for CURLOPT_COOKIEJAR when http.savecookies is true. Its documentation page does not say what would happen if you give an empty string to it. So, a casual one-line mention you added is a bit irresponsible. At least you should warn against setting http.savecookies if the user chooses to use "" for this, or better yet, fix the codepath to use http.savecookies to prevent us from writing to a file with an empty filename. Also the libcURL documentation for CURLOPT_COOKIEFILE has another thing that is a bit worrysome: If you tell libcurl the filename is "-" (just a single minus sign), libcurl instead reads from stdin. So you can easily get your git get stuck by doing git -c http.cookiefile=- fetch https://..... as libcURL will want to read from your stdin, while you are waiting for the fetch to finish and are not typing anything?