Re: [PATCH] send-email: recognize absolute path on Windows

On Tue, Apr 15, 2014 at 12:32 PM, Johannes Sixt wrote: > Am 4/15/2014 10:44, schrieb Erik Faye-Lund: >> From: Erik Faye-Lund >> >> On Windows, absolute paths might start with a DOS drive prefix, >> which this check fails to recognize. >> >>

[PATCH] send-email: recognize absolute path on Windows

From: Erik Faye-Lund On Windows, absolute paths might start with a DOS drive prefix, which this check fails to recognize. Unfortunately, we cannot simply use the file_name_is_absolute helper in File::Spec::Functions, because Git for Windows has an MSYS-based Perl, where this helper doesn't

Re: [msysGit] GitMinutes about Git for Windows

On Mon, Apr 14, 2014 at 5:14 PM, Johannes Schindelin wrote: > Dear friends of Git for Windows, > > it was very delightful to be on the show, hosted by Thomas Ferris > Nicolaisen: > > http://episodes.gitminutes.com/2014/04/gitminutes-28-johannes-schindelin-on.html Really enjoyable, thanks! -- To u

Re: Our official home page and logo for the Git project

On Fri, Apr 11, 2014 at 9:25 PM, Junio C Hamano wrote: > The motion is about this: > > Outside people, like the party who approached us about putting > our logo on their trinket, seem to associate that logo we see on > git-scm.com today with our project, but we never officially said >

Re: [PATCH 17/19] Portable alloca for Git

On Wed, Apr 9, 2014 at 2:48 PM, Kirill Smelkov wrote: > On Thu, Mar 27, 2014 at 06:22:50PM +0400, Kirill Smelkov wrote: >> On Mon, Mar 24, 2014 at 02:47:24PM -0700, Junio C Hamano wrote: >> > Kirill Smelkov writes: >> > >> > > On Fri, Feb 28, 2014 at

Re: msysgit color scheme

On Fri, Feb 28, 2014 at 11:38 PM, Robert Dailey wrote: > Is there a way to change color scheme in msysgit without going through > the Properties >> Colors settings? > > Reason I ask is because I share the same HOME directory and .bashrc > file between msysgit and cygwin, and it'd be nice to use th

Re: [PATCH 17/19] Portable alloca for Git

On Fri, Feb 28, 2014 at 6:00 PM, Kirill Smelkov wrote: > On Fri, Feb 28, 2014 at 02:50:04PM +0100, Erik Faye-Lund wrote: >> On Fri, Feb 28, 2014 at 2:44 PM, Erik Faye-Lund wrote: >> > On Mon, Feb 24, 2014 at 5:21 PM, Kirill Smelkov wrote: >> >> diff --git a/M

Re: [PATCH 17/19] Portable alloca for Git

On Fri, Feb 28, 2014 at 2:44 PM, Erik Faye-Lund wrote: > On Mon, Feb 24, 2014 at 5:21 PM, Kirill Smelkov wrote: >> diff --git a/Makefile b/Makefile >> index dddaf4f..0334806 100644 >> --- a/Makefile >> +++ b/Makefile >> @@ -316,6 +321,7 @@ e

Re: [PATCH 17/19] Portable alloca for Git

On Mon, Feb 24, 2014 at 5:21 PM, Kirill Smelkov wrote: > diff --git a/Makefile b/Makefile > index dddaf4f..0334806 100644 > --- a/Makefile > +++ b/Makefile > @@ -316,6 +321,7 @@ endif > ifeq ($(uname_S),Windows) > GIT_VERSION := $(GIT_VERSION).MSVC > pathsep = ; > + HAVE_ALL

Re: [msysGit] Git for Windows 1.9.0 (fwd)

On Tue, Feb 18, 2014 at 3:33 AM, Mike Hommey wrote: > On Tue, Feb 18, 2014 at 12:52:28AM +0100, Johannes Schindelin wrote: >> Hopefully the Postfix Greylisting Policy Server will not try again to >> greylist me, as it might however do without violating the RFC. >> >> -- Forwarded message -

Re: Make the git codebase thread-safe

On Wed, Feb 12, 2014 at 7:34 PM, Stefan Zager wrote: > On Wed, Feb 12, 2014 at 10:27 AM, Erik Faye-Lund wrote: >> On Wed, Feb 12, 2014 at 7:20 PM, Stefan Zager wrote: >>> >>> I don't want to steal the thunder of my coworker, who wrote the >>> implementat

Re: Make the git codebase thread-safe

On Wed, Feb 12, 2014 at 7:20 PM, Stefan Zager wrote: > On Wed, Feb 12, 2014 at 3:59 AM, Erik Faye-Lund wrote: >> On Wed, Feb 12, 2014 at 2:54 AM, Stefan Zager wrote: >>> >>> We are particularly concerned with the performance of msysgit, and we >>> h

Re: pack bitmap woes on Windows

On Wed, Feb 12, 2014 at 3:22 PM, Erik Faye-Lund wrote: > On Wed, Feb 12, 2014 at 3:09 PM, Duy Nguyen wrote: >> On Wed, Feb 12, 2014 at 8:23 PM, David Kastrup wrote: >>> Johannes Sixt writes: >>> >>>> Am 2/12/2014 13:55, schrieb David Kastrup: >>&g

Re: pack bitmap woes on Windows

On Wed, Feb 12, 2014 at 3:09 PM, Duy Nguyen wrote: > On Wed, Feb 12, 2014 at 8:23 PM, David Kastrup wrote: >> Johannes Sixt writes: >> >>> Am 2/12/2014 13:55, schrieb David Kastrup: Johannes Sixt writes: > Running test suite of 'next' on Windows fails in t5310-pack-bitmaps with >>

Re: Make the git codebase thread-safe

On Wed, Feb 12, 2014 at 2:54 AM, Stefan Zager wrote: > We in the chromium project have a keen interest in adding threading to > git in the pursuit of performance for lengthy operations (checkout, > status, blame, ...). Our motivation comes from hitting some > performance walls when working with r

Re: pack bitmap woes on Windows

On Wed, Feb 12, 2014 at 8:27 AM, Johannes Sixt wrote: > Running test suite of 'next' on Windows fails in t5310-pack-bitmaps with > the following symptoms. I haven't followed the topic. Have there been > patches floating that addressed the problem in one way or another? > > (gdb) run > Starting pro

Re: [PATCH v2 2/2] gc: config option for running --auto in background

On Mon, Feb 10, 2014 at 2:17 PM, Duy Nguyen wrote: > On Mon, Feb 10, 2014 at 6:03 PM, Erik Faye-Lund wrote: >>> `gc --auto` takes time and can block the user temporarily (but not any >>> - if (!quiet) >>> -

Re: [PATCH v2 1/2] daemon: move daemonize() to libgit.a

On Sat, Feb 8, 2014 at 8:08 AM, Nguyễn Thái Ngọc Duy wrote: > Signed-off-by: Nguyễn Thái Ngọc Duy > diff --git a/setup.c b/setup.c > index 6c3f85f..b09a412 100644 > --- a/setup.c > +++ b/setup.c > @@ -787,3 +787,27 @@ void sanitize_stdfds(void) > if (fd > 2) > close(fd); >

Re: [PATCH v2 2/2] gc: config option for running --auto in background

On Sat, Feb 8, 2014 at 8:08 AM, Nguyễn Thái Ngọc Duy wrote: > `gc --auto` takes time and can block the user temporarily (but not any > less annoyingly). Make it run in background on systems that support > it. The only thing lost with running in background is printouts. But > gc output is not reall

Re: Feature Request Google Authenticator Support

On Thu, Jan 30, 2014 at 5:07 AM, Max Rahm wrote: > Github supports google authenticator 2-step authentication. I enabled it > and how can't figure out how to connect to my github account through git. > I've looked pretty hard in the man pages and on google and can't seem to > find anything on how

Re: [msysGit] Consecutive git gc fails on Windows network share

On Tue, Jan 21, 2014 at 5:57 PM, Johannes Schindelin wrote: > Hi kusma, > > On Tue, 21 Jan 2014, Erik Faye-Lund wrote: > >> On Tue, Jan 21, 2014 at 12:25 AM, Johannes Schindelin >> wrote: >> > >> > On Mon, 20 Jan 2014, Torsten Bögershausen wrote: >&

Re: [msysGit] Consecutive git gc fails on Windows network share

On Tue, Jan 21, 2014 at 12:25 AM, Johannes Schindelin wrote: > > On Mon, 20 Jan 2014, Torsten Bögershausen wrote: > >> b) add "+++" at the places where you added the stat() and chmod(), >> c) and to send the question "is this a good implementation ?" to upstream >> git. >> >> I think your impleme

Re: [PATCH 1/2] prefer xwrite instead of write

On Fri, Jan 17, 2014 at 8:07 PM, Junio C Hamano wrote: > Jonathan Nieder writes: > >> Hi, >> >> Erik Faye-Lund wrote: >> >>> --- a/builtin/merge.c >>> +++ b/builtin/merge.c >>> @@ -367,7 +367,7 @@ static void squash_message(s

[PATCH 2/2] mingw: remove mingw_write

Since 0b6806b9 ("xread, xwrite: limit size of IO to 8MB"), this wrapper is no longer needed, as read and write are already split into small chunks. Signed-off-by: Erik Faye-Lund --- compat/mingw.c | 17 - compat/mingw.h | 3 --- 2 files changed, 20 deletions(-) di

[PATCH 1/2] prefer xwrite instead of write

Our xwrite wrapper already deals with a few potential hazards, and are as such more robust. Prefer it instead of write to get the robustness benefits everywhere. Signed-off-by: Erik Faye-Lund --- With this patch, we don't call write directly any more; all calls goes via the xwrite-wr

Re: Synchronize git-credential-wincred from msysgit

On Sun, Jan 12, 2014 at 12:59 PM, 乙酸鋰 wrote: > Hi, > > Please cherry pick from msysgit/git > commit 3c8cbb4edc8f577940c52115c992d17575587f99 > > to synchronize git-credential-wincred > > This was the change they made half year ago. It's actually a two-patch series. Cover-letter: http://permalink

Re: [PATCH] Fix safe_create_leading_directories() for Windows

On Thu, Jan 2, 2014 at 9:46 PM, Johannes Schindelin wrote: > Hi Sebastian, > > On Thu, 2 Jan 2014, Sebastian Schuberth wrote: > >> On 02.01.2014 18:33, Johannes Schindelin wrote: >> >> > -- snip -- >> > On Linux, we can get away with assuming that the directory separator is a >> > forward slash, b

Re: [msysGit] Fwd: static initializers

On Mon, Jan 6, 2014 at 11:05 PM, Stefan Zager wrote: > Forwarding to msysgit for any guidance about win equivalents for > PTHREAD_MUTEX_INITIALIZER or __attribute__((constructor)). As you've probably already guessed, PTHREAD_MUTEX_INITIALIZER isn't supported in our pthreads-emulator. I did send o

Re: Crash on context menu

On Thu, Dec 26, 2013 at 2:16 PM, George Bateman wrote: > Win7 SP1; Git identifies itself as version 1.8.4-preview20130916. > I copied the Git Bash shortcut from the start menu to the root of a > Git repository (no remote part). I use the advanced context menu. For > other files in the directory, i

Re: [PATCH v4 23/23] compat/mingw.h: Fix the MinGW and msvc builds

On Sat, Dec 21, 2013 at 3:00 PM, Jeff King wrote: > From: Ramsay Jones > > Signed-off-by: Ramsay Jones > Signed-off-by: Junio C Hamano > Signed-off-by: Jeff King > --- > compat/mingw.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/compat/mingw.h b/compat/mingw.h > index 92cd728..88

Re: [PATCH] pager: turn on "cat" optimization for DEFAULT_PAGER

On Wed, Nov 20, 2013 at 6:33 PM, Junio C Hamano wrote: > Erik Faye-Lund writes: > >>> ... >>> is set to empty., 2006-04-16). At that time, the line >>> directly above used: >>> >>>if (!pager) >>>pager = "less&qu

Re: [PATCH] pager: turn on "cat" optimization for DEFAULT_PAGER

On Wed, Nov 20, 2013 at 6:30 PM, Jeff King wrote: > On Wed, Nov 20, 2013 at 06:24:45PM +0100, Erik Faye-Lund wrote: > >> > diff --git a/pager.c b/pager.c >> > index c1ecf65..fa19765 100644 >> > --- a/pager.c >> > +++ b/pager.c >> > @@ -54

Re: [PATCH] pager: turn on "cat" optimization for DEFAULT_PAGER

On Tue, Sep 3, 2013 at 9:41 AM, Jeff King wrote: > On Mon, Sep 02, 2013 at 10:27:48PM -0400, Dale R. Worley wrote: > >> > I guess the "else" could and should be dropped. If you do so (and >> > possibly insert a blank line between the DEFAULT_PAGER case and the >> > "pager = NULL" case), you get a

Re: [PATCH v2 01/10] test-chmtime: Fix exit code on Windows

On Fri, Jun 7, 2013 at 10:53 PM, Johannes Sixt wrote: > MinGW's bash does not recognize an exit code -1 as failure. See also > 47e3de0e (MinGW: truncate exit()'s argument to lowest 8 bits) and 2488df84 > (builtin run_command: do not exit with -1). Exit code 1 is good enough. > > Signed-off-by: Joh

Re: Check out doesn't set x-flag on CIFS

Sigh, it seems replying from Gmail on my phone culled the CC-list. Sorry about that, and here's the rest of the discussion in case someone else is interested: On Wed, Nov 20, 2013 at 1:38 PM, Andre Esser wrote: > On 2013-11-20 12:23, Erik Faye-Lund wrote: >> On Wed, Nov 20, 20

Re: Check out doesn't set x-flag on CIFS

On Wed, May 29, 2013 at 4:16 PM, Andre Esser wrote: > Hello, > > When on a CIFS filesystem a git checkout does not replicate the executable > flag from the repository: > > $ git clone git://git/abettersqlplus > Cloning into 'abettersqlplus'... > remote: Counting objects: 522, done. > remot

Re: write() _will_ fail on Mac OS X/XNU if nbytes > INT_MAX

I know I'm extremely late to the party, and this patch has already landed, but... On Sat, May 11, 2013 at 1:05 AM, Junio C Hamano wrote: > Filipe Cabecinhas writes: > >> Due to a bug in the Darwin kernel, write() calls have a maximum size of >> INT_MAX bytes. >> >> This patch introduces a new co

Re: [PATCH 1/2] entry.c: convert checkout_entry to use strbuf

On Wed, Oct 23, 2013 at 7:29 PM, Jeff King wrote: > On Wed, Oct 23, 2013 at 07:55:06PM +0700, Nguyen Thai Ngoc Duy wrote: > >> The old code does not do boundary check so any paths longer than >> PATH_MAX can cause buffer overflow. Replace it with strbuf to handle >> paths of arbitrary length. > >

Re: [msysGit] [PATCH] Prevent buffer overflows when path is too big

On Mon, Oct 21, 2013 at 9:02 PM, Johannes Sixt wrote: > Am 21.10.2013 03:31, schrieb Duy Nguyen: >> On Mon, Oct 21, 2013 at 12:57 AM, Antoine Pelisse wrote: >>> My main motive was to not *stop* the process when a long path is met. >>> Because somebody created a repository on Linux with a long fil

Re: [PATCH] mingw-multibyte: fix memory acces violation and path length limits.

On Thu, Oct 3, 2013 at 7:25 PM, Antoine Pelisse wrote: > I've not followed the thread so much but, in that > entry.c::checkout_entry,() we do: > > memcpy(path, state->base_dir, len); > strcpy(path + len, ce->name); > > which can of course result in memory violation if PATH is not long enough. > .

Re: [PATCH] mingw-multibyte: fix memory acces violation and path length limits.

On Mon, Sep 30, 2013 at 7:00 PM, René Scharfe wrote: > Am 29.09.2013 04:56, schrieb Wataru Noguchi: >> Hi, >> >> Thanks for comments. >> >> My currently working repository is >> >> https://github.com/wnoguchi/git/tree/hotfix/mingw-multibyte-path-checkout-failure >> >> I have revert commits to 1f10

Re: CPPCheck found 24 high risk bugs in Git v.1.8.3.4

On Wed, Aug 21, 2013 at 1:01 AM, Andreas Schwab wrote: > Erik Faye-Lund writes: > >> I don't see how it's undefined. It's using the memory that 'pos' >> *points to* that is undefined, no? The difference between 'pos' and >> &#

Re: CPPCheck found 24 high risk bugs in Git v.1.8.3.4

On Tue, Aug 20, 2013 at 10:34 PM, René Scharfe wrote: > Am 20.08.2013 20:44, schrieb Andreas Schwab: > >> Erik Faye-Lund writes: >> >>> diff --git a/compat/win32/syslog.c b/compat/win32/syslog.c >>> index d015e43..0641f4e 100644 >>> --- a/compat/w

Re: CPPCheck found 24 high risk bugs in Git v.1.8.3.4

On Tue, Aug 20, 2013 at 8:44 PM, Andreas Schwab wrote: > Erik Faye-Lund writes: > >> diff --git a/compat/win32/syslog.c b/compat/win32/syslog.c >> index d015e43..0641f4e 100644 >> --- a/compat/win32/syslog.c >> +++ b/compat/win32/syslog.c >> @@ -43,11 +43,1

Re: CPPCheck found 24 high risk bugs in Git v.1.8.3.4

This one seems real, although it's quite theoretical. It should only happen in cases where the log-message contains "%1", the initial malloc passed and reallocing two more bytes failed. However, what's much more of a disaster: "pos" is used after the call to realloc might have moved the memory! I

Re: git clone doesn't work in symlink dir roots on Windows

On Sun, Aug 11, 2013 at 9:28 AM, Sedat Kapanoglu wrote: > Thanks folks. So that this won't be fixed, I added a new Q&A to > MsysGit FAQ at > https://github.com/msysgit/msysgit/wiki/Frequently-Asked-Questions > , I appreciate if you can review and correct if needed. I hope it will > help avoiding

Re: git clone doesn't work in symlink dir roots on Windows

On Sat, Aug 10, 2013 at 6:34 PM, Fredrik Gustafsson wrote: > On Sat, Aug 10, 2013 at 07:22:03PM +0300, Sedat Kapanoglu wrote: >> > git is a disk intense program, so this setup is not sane at all. With >> > that said I know that git on windows historically had problems with >> > working on smb-moun

Re: [PATCH] t0005: skip signal death exit code test on Windows

On Mon, Jun 10, 2013 at 7:30 AM, Johannes Sixt wrote: > Am 6/9/2013 22:31, schrieb Junio C Hamano: >> Jeff King writes: >> >>> I'm a little negative on handling just SIGTERM. That would make the test >>> pass, but does it really address the overall issue? To me, the >>> usefulness is having exit

Re: [PATCH] mingw: make mingw_signal return the correct handler

On Mon, Jun 10, 2013 at 7:48 AM, Johannes Sixt wrote: > From: Erik Faye-Lund > > Returning the SIGALRM handler for SIGINT is not very useful. > > Signed-off-by: Erik Faye-Lund > Signed-off-by: Johannes Sixt > --- > Am 6/7/2013 16:20, schrieb Erik Faye-Lund: >>

Re: [PATCH] t0005: skip signal death exit code test on Windows

On Fri, Jun 7, 2013 at 3:07 PM, Johannes Sixt wrote: > Am 6/7/2013 14:46, schrieb Erik Faye-Lund: >> On Fri, Jun 7, 2013 at 2:19 PM, Johannes Sixt wrote: >>> Am 6/7/2013 14:00, schrieb Erik Faye-Lund: >>>> On Fri, Jun 7, 2013 at 12:24 PM, Johannes Sixt >&

Re: [PATCH] t0005: skip signal death exit code test on Windows

On Fri, Jun 7, 2013 at 2:19 PM, Johannes Sixt wrote: > Am 6/7/2013 14:00, schrieb Erik Faye-Lund: >> On Fri, Jun 7, 2013 at 12:24 PM, Johannes Sixt wrote: >>> Am 6/7/2013 12:12, schrieb Erik Faye-Lund: >>>> On Thu, Jun 6, 2013 at 7:40 PM, Jeff King wrote: >&

Re: [PATCH] t0005: skip signal death exit code test on Windows

On Fri, Jun 7, 2013 at 12:24 PM, Johannes Sixt wrote: > Am 6/7/2013 12:12, schrieb Erik Faye-Lund: >> On Thu, Jun 6, 2013 at 7:40 PM, Jeff King wrote: >>> On Thu, Jun 06, 2013 at 10:21:47AM -0700, Junio C Hamano wrote: >>> >>>>> The particular deficien

Re: [PATCH] t0005: skip signal death exit code test on Windows

On Thu, Jun 6, 2013 at 7:40 PM, Jeff King wrote: > On Thu, Jun 06, 2013 at 10:21:47AM -0700, Junio C Hamano wrote: > >> > The particular deficiency is that when a signal is raise()d whose SIG_DFL >> > action will cause process death (SIGTERM in this case), the >> > implementation of raise() just c

Re: [PATCH] t0005: skip signal death exit code test on Windows

On Fri, Jun 7, 2013 at 12:01 PM, Erik Faye-Lund wrote: > On Thu, Jun 6, 2013 at 8:34 AM, Johannes Sixt wrote: >> From: Johannes Sixt >> >> The test case depends on that test-sigchain can commit suicide by a call >> to raise(SIGTERM) in a way that run-command.c::wait_

Re: [PATCH] t0005: skip signal death exit code test on Windows

On Thu, Jun 6, 2013 at 8:34 AM, Johannes Sixt wrote: > From: Johannes Sixt > > The test case depends on that test-sigchain can commit suicide by a call > to raise(SIGTERM) in a way that run-command.c::wait_or_whine() can detect > as death through a signal. There are no POSIX signals on Windows, a

Re: [PATCH v2 0/2] avoid bogus "recursion detected in die handler" message

On Tue, Apr 16, 2013 at 9:44 PM, Jeff King wrote: > On Tue, Apr 16, 2013 at 04:13:56PM +0200, Johannes Sixt wrote: > >> > I'm not clear on what you are suggesting. That we protect only the main >> > thread from recursion, or that we drop the check entirely? Or that we >> > implement thread-local s

Re: [PATCH] Extend runtime prefix computation

On Wed, Mar 6, 2013 at 9:19 AM, Michael Weiser wrote: > Hello Junio, > > On Tue, Mar 05, 2013 at 08:13:50AM -0800, Junio C Hamano wrote: > >> >> Support determining the binaries' installation path at runtime even if >> >> called without any path components (i.e. via search path). > >> The default

Re: [PATCH master] convert: The native line-ending is \r\n on MinGW

On Mon, Apr 15, 2013 at 11:43 PM, Junio C Hamano wrote: > Erik Faye-Lund writes: > >> This is absolutely the right thing to do. However, stuff have changed >> a bit since the patch was written; this change now needs to go in >> config.mak.uname instead of config.mak

Re: [PATCH master] convert: The native line-ending is \r\n on MinGW

On Mon, Apr 15, 2013 at 11:00 PM, Junio C Hamano wrote: > Junio C Hamano writes: > >> Jonathan Nieder writes: >> >>> If you try this: >>> >>> 1. Install Git for Windows (from the msysgit project) >>> 2. Put >>> >>> [core] >>> autocrlf = false >>> eol = native >>>

Re: [PATCH 3/4] drop some obsolete "x = x" compiler warning hacks

On Thu, Mar 21, 2013 at 12:10 PM, Jeff King wrote: > In cases where the setting and access of a variable are > protected by the same conditional flag, older versions of > gcc would generate a "might be used unitialized" warning. We > silence the warning by initializing the variable to itself, > a

Re: [PATCH/RFC] http_init: only initialize SSL for https

On Mon, Mar 18, 2013 at 11:38 AM, Erik Faye-Lund wrote: > On Sun, Mar 17, 2013 at 11:27 PM, Junio C Hamano wrote: >> Daniel Stenberg writes: >> >>> On Sun, 17 Mar 2013, Antoine Pelisse wrote: >>> >>>>> With redirects taken into account, I can'

Re: [PATCH/RFC] http_init: only initialize SSL for https

On Sun, Mar 17, 2013 at 11:27 PM, Junio C Hamano wrote: > Daniel Stenberg writes: > >> On Sun, 17 Mar 2013, Antoine Pelisse wrote: >> With redirects taken into account, I can't think of any really good way around avoiding this init... >>> >>> Is there any way for curl to initialize SSL

Re: [PATCH/RFC] http_init: only initialize SSL for https

On Thu, Mar 14, 2013 at 11:45 PM, Junio C Hamano wrote: > Johannes Schindelin writes: > >> Apparently, ftps is also handled by cURL and most likely requires SSL. >> >> How about optimizing for the common case and instead of prefixcmp(url, >> "https:")) ask for !prefixcmp(url, "http:")? > > I thin

Re: [msysGit] [PATCH/RFC] http_init: only initialize SSL for https

On Thu, Mar 14, 2013 at 4:23 PM, Johannes Schindelin wrote: > Hi kusma, > > On Thu, 14 Mar 2013, Erik Faye-Lund wrote: > >> Since ancient times, we have been calling curl_global_init with the >> CURL_GLOBAL_ALL-flag, which initializes SSL (and the Win32 so

Re: [PATCH/RFC] http_init: only initialize SSL for https

On Thu, Mar 14, 2013 at 2:51 PM, Erik Faye-Lund wrote: > Since ancient times, we have been calling curl_global_init with the > CURL_GLOBAL_ALL-flag, which initializes SSL (and the Win32 socket > stack on Windows). > > Initializing SSL takes quite some time on Windows, so let

[PATCH/RFC] http_init: only initialize SSL for https

user0m0.000s sys 0m0.015s Signed-off-by: Erik Faye-Lund --- http.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/http.c b/http.c index 3b312a8..528a736 100644 --- a/http.c +++ b/http.c @@ -343,7 +343,8 @@ void http_init(struct remote *remote, const char *url,

Re: git-am and CRLF

On Wed, Mar 13, 2013 at 6:42 PM, Brandon Casey wrote: > On Wed, Mar 13, 2013 at 9:54 AM, Erik Faye-Lund wrote: >> I recently tried to apply a patch-series to a repo that is >> unfortunately full of CRLF files, and was a bit surprised that it >> didn't work at all. >

git-am and CRLF

I recently tried to apply a patch-series to a repo that is unfortunately full of CRLF files, and was a bit surprised that it didn't work at all. So I made a small repro-case, and it seems CRLF new-lines is indeed the problem. Any clue how to fix it? The way I see it, we should simply be able top t

Re: [RFC/PATCH] Documentation/technical/api-fswatch.txt: start with outline

On Tue, Mar 12, 2013 at 10:43 AM, Ramkumar Ramachandra wrote: > Heiko Voigt wrote: >> While talking about platform independence. How about Windows? AFAIK >> there are no file based sockets. How about using shared memory, thats >> available, instead? It would greatly reduce the needed porting effor

[PATCH v2] Revert "compat: add strtok_r()"

This reverts commit 78457bc0ccc1af8b9eb776a0b17986ebd50442bc. commit 28c5d9e ("vcs-svn: drop string_pool") previously removed the only call-site for strtok_r. So let's get rid of the compat implementation as well. Signed-off-by: Erik Faye-Lund Reviewed-by: Jonathan Nieder

Re: [PATCH v2 0/2] improve-wincred-compatibility

On Tue, Feb 26, 2013 at 12:51 AM, Junio C Hamano wrote: > My question was if msysgit folks > want me to take your patch (which I cannot test myself) and then > merge my tree to the msysgit tree as part of their regular updates > to catch up with 1.8.2 (and future releases), or they want to test >

Re: [PATH/RFC] Revert "compat: add strtok_r()"

On Mon, Feb 25, 2013 at 7:55 AM, Junio C Hamano wrote: > Care to tie the loose end on this one, with a sign-off? Yes, I'll get right to it, sorry for the delay! -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo i

Re: [PATCH] Fix in Git.pm cat_blob crashes on large files (reviewed by Jeff King)

On Fri, Feb 22, 2013 at 6:03 PM, Joshua Clayton wrote: > Read and write each 1024 byte buffer, rather than trying to buffer > the entire content of the file. > Previous code would crash on all files > 2 Gib, when the offset variable > became negative (perhaps below the level of perl), resulting in

Re: Is this a bug?

On Tue, Feb 19, 2013 at 10:32 AM, David Wade wrote: > Hi, > > I wrote a commit message beginning with a hash (#) character, like this: 'git > commit -m "#ifdef " ' > > Everything went okay when committing, but then I tried 'git commit -amend' > and without editing the commit message I was to

[PATCHv2] parse-options: report uncorrupted multi-byte options

reporting code report the whole argument-string when a non-ASCII short-option is detected. Signed-off-by: Erik Faye-Lund Improved-by: Jeff King --- Here's a second attempt at fixing error-reporting with UTF-8 encoded input, this time without corrupting other non-ascii multi-byte encodings. I de

Re: [PATH/RFC] parse-options: report invalid UTF-8 switches

On Mon, Feb 11, 2013 at 6:19 PM, Jeff King wrote: > On Mon, Feb 11, 2013 at 09:07:53AM -0800, Junio C Hamano wrote: > >> Erik Faye-Lund writes: >> >> > However, since git only looks at one byte at the time for >> > short-options, it ends up reporting a parti

Re: [PATH/RFC] parse-options: report invalid UTF-8 switches

On Mon, Feb 11, 2013 at 6:07 PM, Junio C Hamano wrote: > Erik Faye-Lund writes: > >> However, since git only looks at one byte at the time for >> short-options, it ends up reporting a partial UTF-8 sequence >> in such cases, leading to corruption of the output. > &g

Re: [PATH/RFC] parse-options: report invalid UTF-8 switches

On Mon, Feb 11, 2013 at 5:28 PM, Torsten Bögershausen wrote: > On 11.02.13 14:34, Erik Faye-Lund wrote: >> Even though parse-options doesn't support UTF-8 switches (which >> makes sense; non-ascii switches would be difficult to enter on >> some keyboard layouts),

Re: [PATH/RFC] parse-options: report invalid UTF-8 switches

On Mon, Feb 11, 2013 at 3:05 PM, Matthieu Moy wrote: > Erik Faye-Lund writes: > >> But isn't UTF-8 constructed to be very unlikely to clash with existing >> encodings? If so, I could add a case for non-ascii and non-UTF-8, that >> simply writes the byte as a hex-tup

Re: [PATH/RFC] parse-options: report invalid UTF-8 switches

On Mon, Feb 11, 2013 at 2:43 PM, Matthieu Moy wrote: > Erik Faye-Lund writes: > >> --- a/parse-options.c >> +++ b/parse-options.c >> @@ -3,6 +3,7 @@ >> #include "cache.h" >> #include "commit.h" >> #include "color.h&

[PATH/RFC] parse-options: report invalid UTF-8 switches

h UTF-8 characters on it. Make the reporting code grok UTF-8 in the option sequence, and write a variable-width output sequence. Signed-off-by: Erik Faye-Lund --- As being both clumsy and Norwegian, I some times to enter the Norwegian bizarro-letters ('æ', 'ø' and 'å'

Re: inotify to minimize stat() calls

On Sun, Feb 10, 2013 at 12:17 PM, Duy Nguyen wrote: > On Sun, Feb 10, 2013 at 12:24:58PM +0700, Duy Nguyen wrote: >> On Sun, Feb 10, 2013 at 12:10 AM, Ramkumar Ramachandra >> wrote: >> > Finn notes in the commit message that it offers no speedup, because >> > .gitignore files in every directory s

Re: [RFC] test-lib.sh: No POSIXPERM for cygwin

On Sun, Jan 27, 2013 at 3:57 PM, Torsten Bögershausen wrote: > t0070 and t1301 fail when running the test suite under cygwin. > Skip the failing tests by unsetting POSIXPERM. > But is this the real reason? I thought Cygwin implemented POSIX permissions...? -- To unsubscribe from this list: send t

Re: git-svn problems with white-space in tag names

On Sun, Jan 27, 2013 at 3:12 PM, Hans-Juergen Euler wrote: > This seems to be a problem of the windows version. At least with its > complete severity. Installed git on Ubuntu in a virtual machine was > able to clone the subversion repos past the tag with the white-space > at the end. I am not sure

Re: [PATCH v3 2/8] git_remote_helpers: fix input when running under Python 3

On Fri, Jan 25, 2013 at 9:23 PM, Brandon Casey wrote: > On Wed, Jan 23, 2013 at 12:36 PM, Junio C Hamano wrote: >> Sverre Rabbelier writes: >> >>> On Wed, Jan 23, 2013 at 11:47 AM, John Keeping wrote: > When did we last revisit what minimal python version we are ok with > requiring? >>

Re: [PATH/RFC] Revert "compat: add strtok_r()"

On Fri, Feb 1, 2013 at 11:33 AM, Erik Faye-Lund wrote: > This reverts commit 78457bc0ccc1af8b9eb776a0b17986ebd50442bc. > > commit 28c5d9e ("vcs-svn: drop string_pool") previously removed > the only call-site for strtok_r. So let's get rid of the compat > impleme

[PATH/RFC] Revert "compat: add strtok_r()"

This reverts commit 78457bc0ccc1af8b9eb776a0b17986ebd50442bc. commit 28c5d9e ("vcs-svn: drop string_pool") previously removed the only call-site for strtok_r. So let's get rid of the compat implementation as well. Conflicts: Makefile config.mak.in configure.ac --- I just

Re: [feature request] git-daemon http connection filtering of client types

On Thu, Jan 31, 2013 at 1:46 PM, wrote: > Hey folks, > > When I checked for false positives in my spam this morning, I spotted > an interesting malformed img link at the top of a spam message. > > {snip} >> >> >> Employ a medal tiffany bracelet

Re: [msysGit] Re: Bug in EOL conversion?

On Wed, Jan 23, 2013 at 10:55 PM, Philip Oakley wrote: > The msysgit list msys...@googlegroups.com may be a better place for this. > > It is likely that you have a windows specific EOL conversion set within the > wider config's (i.e. --system, --global). You may have core.safecrlf set > which doe

Re: GIT get corrupted on lustre

On Wed, Jan 23, 2013 at 4:44 PM, Thomas Rast wrote: > Erik Faye-Lund writes: > >> On Wed, Jan 23, 2013 at 4:32 PM, Thomas Rast wrote: >>> Erik Faye-Lund writes: >>> >>>> POSIX allows error codes >>>> to be generated other than those d

Re: GIT get corrupted on lustre

On Wed, Jan 23, 2013 at 4:32 PM, Thomas Rast wrote: > Erik Faye-Lund writes: > >> On Tue, Jan 22, 2013 at 11:14 PM, Thomas Rast wrote: >>> Eric Chamberland writes: >>> >>> Other than that I agree with Junio, from what we've seen so far, Lustre

Re: GIT get corrupted on lustre

On Tue, Jan 22, 2013 at 11:14 PM, Thomas Rast wrote: > Eric Chamberland writes: > > Other than that I agree with Junio, from what we've seen so far, Lustre > returns EINTR on all sorts of calls that simply aren't allowed to do so. I don't think this analysis is 100% accurate, POSIX allows error

Re: git-svn does not like format=4

On Wed, Jan 23, 2013 at 11:43 AM, Hans-Juergen Euler wrote: > it's part of a sequence of problems you can find on > groups.google.com/d/topic/git-users/kfMFZ3uEFsM/discussion > > windows 7 64 bit > Git version 1.8.0 > git bash and git gui installed and using > > using subversion > TortoiseSVN 1.7.

Re: GIT get corrupted on lustre

On Fri, Jan 18, 2013 at 6:50 PM, Eric Chamberland wrote: > Good idea! > > I did a strace and here is the output with the error: > > http://www.giref.ulaval.ca/~ericc/strace_git_error.txt > > Hope it will be insightful! This trace doesn't seem to contain child-processes, but instead having their s

Re: [PATCH v2 0/2] improve-wincred-compatibility

ndows versions > > .../credential/wincred/git-credential-wincred.c| 206 > - > 1 file changed, 75 insertions(+), 131 deletions(-) > > Wonderful! Acked-by: Erik Faye-Lund -- To unsubscribe from this list: send the line "unsubscribe git" in the

Re: [PATCH] wincred: improve compatibility with windows versions

On Tue, Jan 8, 2013 at 5:20 PM, Karsten Blees wrote: > Am 04.01.2013 22:57, schrieb Erik Faye-Lund: >> The only reason why I used Cred[Un]PackAuthenticationBuffer, were that >> I wasn't aware that it was possible any other way. I didn't even know >> there was

Re: [BUG/PATCH] setup: Copy an environment variable to avoid overwrites

On Sat, Jan 5, 2013 at 1:35 AM, David Michael wrote: > It is possible for this pointer of the GIT_DIR environment variable to > survive unduplicated until further getenv calls are made. The standards > allow for subsequent calls of getenv to overwrite the string located at > its returned pointer,

Re: [PATCH] wincred: improve compatibility with windows versions

On Fri, Jan 4, 2013 at 9:28 PM, Karsten Blees wrote: > On WinXP, the windows credential helper doesn't work at all (due to missing > Cred[Un]PackAuthenticationBuffer APIs). On Win7, the credential format used > by wincred is incompatible with native Windows tools (such as the control > panel apple

Re: sys/param.h

On Tue, Dec 18, 2012 at 6:01 PM, Junio C Hamano wrote: > Johannes Sixt writes: > >>> Junio C Hamano wrote: It could turn out that we may be able to get rid of sys/param.h altogether, but one step at a time. Inputs from people on minority platforms are very much appreciated---does

Re: [PATCHv2] mingw_rmdir: do not prompt for retry when non-empty

On Mon, Dec 10, 2012 at 5:25 PM, Junio C Hamano wrote: > Erik Faye-Lund writes: > >> in ab1a11be ("mingw_rmdir: set errno=ENOTEMPTY when appropriate"), >> a check was added to prevent us from retrying to delete a directory >> that is both in use and non-em

<    1   2   3   >