Re: Default authentication over https?

[Isaac Levy]

After the authenticated request, curl says it's keeping the connection
open, but the next fetch seems to do two handshakes again.  The
unauthenticated request closes the connection, so the 2nd handshake is
forced, but I'm not sure why subsequent git fetches still do
handshakes.  I did a bit of sleuthing w/ source, GIT_CURL_VERBOSE and
wireshark.

We're using GitHub enterprise -- it'd just be nice if there was a
better way to configure for super fast fetches.  ssh with cached
connections does avoid the SSL this overhead -- though as I recall git
protocols over ssh are less performant.

Finally I also checked out the persistent-https contrib section as a
workaround but couldn't get it to work. Is that project dead?

Thank you for your replies and support.

Regards,
Isaac

On Thu, Apr 14, 2016 at 5:46 AM, Daniel Stenberg  wrote:
> On Wed, 13 Apr 2016, Jeff King wrote:
>
>> However, I don't think even that would give you what you want. Because I
>> think that even if we provide a credential, curl will make an initial
>> request (presumably to find out which auth type it should use, but that
>> is just a guess). I don't know if there is a way to convince curl to
>> stick the credential in the first request
>
>
> curl supports this. but then you must do exactly that: tell libcurl to use
> that single auth method only. It will of course make it fail if you select
> the wrong method etc.
>
> The unauthenticated first request is both to probe for which methods the
> server wants, but also works for the case when users provide credentials
> without the server actually ending up asking for them...
>
> --
>
>  / daniel.haxx.se
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Default authentication over https?

[Isaac Levy]

Hi all,

I use a git server which requires authentication over https. Git seems
determined to always try an unauthenticated request first, slowing
down operations by a couple seconds.

Is there a way to configure git to default to authenticated requests?  Thanks!

Regards,
Isaac Levy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bash completion doing full tree traversal?

[Isaac Levy]

I should clarify that I had an untracked directory which contained a
significant number of files; I can fix by adding it to gitignore.
Still, the long delay  tree traversal were unexpected.

Isaac

On Sun, Sep 8, 2013 at 2:12 PM, Isaac Levy il...@google.com wrote:
 I experienced a weird stall from git bash completion:
 $ git add pTAB

 I did some investigation and found this call trace:

 + __git_index_files '--others --modified' ''
--- git ls-files --exclude-standard --others --modified

 This bash function captures output of the git call and strips all but
 the base directory or base filename.  The results are limited to
 entries in the current directory.

 Appears to be from fea16b47b603e and first released in v1.8.2 (I have 1.8.4).

 Isaac
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Bash completion doing full tree traversal?

[Isaac Levy]

I experienced a weird stall from git bash completion:
$ git add pTAB

I did some investigation and found this call trace:

+ __git_index_files '--others --modified' ''
   --- git ls-files --exclude-standard --others --modified

This bash function captures output of the git call and strips all but
the base directory or base filename.  The results are limited to
entries in the current directory.

Appears to be from fea16b47b603e and first released in v1.8.2 (I have 1.8.4).

Isaac
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html