On Tue, Feb 09, 2016 at 12:47:39AM +0200, Mikko Rapeli wrote:
> On Mon, Feb 08, 2016 at 05:36:50PM -0500, Matt McCutchen wrote:
> > On Mon, 2016-02-08 at 14:22 -0800, Junio C Hamano wrote:
> > > Matt McCutchen writes:
> > >
> > > > I found no evide
On Mon, Feb 08, 2016 at 05:36:50PM -0500, Matt McCutchen wrote:
> On Mon, 2016-02-08 at 14:22 -0800, Junio C Hamano wrote:
> > Matt McCutchen writes:
> >
> > > I found no evidence of such behavior in the source code.
> > >
> > > Signed-off-by: Matt McCutchen
> > > ---
> >
> > That was added la
This is needed in build automation where the tree really needs to
be reset to known state.
Signed-off-by: Mikko Rapeli
---
Documentation/git-clean.txt |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt
index
On Thu, Feb 26, 2015 at 02:56:40PM +0200, Mikko Rapeli wrote:
> This is needed in build automation where the tree really needs to
> be reset to known state.
>
> Signed-off-by: Mikko Rapeli
> ---
> Documentation/git-clean.txt |8 ++--
> 1 file changed, 6 inser
This is needed in build automation where the tree really needs to
be reset to known state.
Signed-off-by: Mikko Rapeli
---
Documentation/git-clean.txt |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt
index
This is needed in build automation where the tree really needs to
be reset to known state.
Signed-off-by: Mikko Rapeli
---
Documentation/git-clean.txt |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt
index
(please Cc: me in replies, not subscribed to the lists)
Hi Cygwin and git developers,
Does following scenario show signs of bugs in Cygwin and/or git?
# setup git repo
$ cd /tmp
$ mkdir foo && cd foo
$ git init
# create x: directory
$ mkdir x:
$ ls
x:
# create Windows X: drive, cygwin utils ca
On Wed, Apr 03, 2013 at 10:12:12AM -0400, Jeff King wrote:
> I would expect without the username in the URL for it to make only two
> requests: one to get the first 401, then git collects the credentials,
> then a follow-up with the credentials. But instead we get:
>
> $ GIT_CURL_VERBOSE=1 git l
Maybe my git installation was incomplete before when running from ~/bin since
I was not able to set break points to http_request() and some debug code
was not there until I ran git through bin-wrappers in the source tree.
I added some debug prints to http.c functions http_request() and
handle_curl
On Tue, Apr 02, 2013 at 04:05:51PM -0400, Jeff King wrote:
> On Tue, Apr 02, 2013 at 10:47:51PM +0300, Mikko Rapeli wrote:
>
> > Don't know anything about curl but maybe git could parse the url for a
> > username and prompt for the password before the first 401 failure roun
On Tue, Apr 02, 2013 at 03:28:45PM -0400, Jeff King wrote:
> We get redirected somewhere where we provide the (presumably wrong)
> credential again. I do not think that is git's fault; the server asked
> us to make the extra request. Is that part of the lockout procedure? If
> it is not, it seems o
On Tue, Apr 02, 2013 at 06:54:40PM +0300, Mikko Rapeli wrote:
> I have client side logs with GIT_CURL_VERBOSE=1 but from intranet so can't
> publish them directly. Here's roughly what the log shows:
Maybe this is simpler summary:
$ grep "HTTP\/1.1" log.txt
> GET ..
Hi,
I have a problem with git (1.7.9 and 1.8.2.357.gcc3e4eb) and https transport
to gerrit server (2.5.1-3-g719dfc7). I'm producing the problem on Cygwin but my
colleagues have same issue on Linux as well.
Gerrit server is matching corporate policies with single sign on, so after
three failed log
13 matches
Mail list logo
