Re: [PATCH v4 1/2] refs.c: optimize check_refname_component()

2014-06-01 Thread Andreas Schwab
David Turner writes: > +static unsigned char refname_disposition[] = { > + 1, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, > + 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, > + 9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 9, 0, 0, 0, 2, 1, > + 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 9, 0, 0, 0, 0, 9, >

Re: Reset by checkout?

2014-06-01 Thread Kevin Bracey
On 01/06/2014 07:26, Atsushi Nakagawa wrote: Kevin Bracey wrote: The original "git reset --hard" used to be a pretty top-level command. It was used for aborting merges in particular. But I think it now stands out as being one of the only really dangerous porcelain commands, and I can't think of

[PATCH] mailinfo: use strcmp() for string comparison

2014-06-01 Thread René Scharfe
The array header is defined as: static const char *header[MAX_HDR_PARSED] = { "From","Subject","Date", }; When looking for the index of a specfic string in that array, simply use strcmp() instead of memcmp(). This avoids running over the end of the string (e.g. with

[PATCH] pack-objects: use free()+xcalloc() instead of xrealloc()+memset()

2014-06-01 Thread René Scharfe
Whenever the hash table becomes too small then its size is increased, the original part (and the added space) is zerod out using memset(), and the table is rebuilt from scratch. Simplify this proceess by returning the old memory using free() and allocating the new buffer using xcalloc(), which alr

[PATCH v2 2/4] replace: add test for --graft

2014-06-01 Thread Christian Couder
Signed-off-by: Christian Couder --- t/t6050-replace.sh | 12 1 file changed, 12 insertions(+) diff --git a/t/t6050-replace.sh b/t/t6050-replace.sh index 68b3cb2..ca45a84 100755 --- a/t/t6050-replace.sh +++ b/t/t6050-replace.sh @@ -351,4 +351,16 @@ test_expect_success 'replace ref cl

[PATCH v2 0/4] Add --graft option to git replace

2014-06-01 Thread Christian Couder
Here is a small patch series to implement: git replace [-f] --graft [...] This patch series goes on top of the patch series that implements --edit. The changes since v1 are the following thanks to Eric, Junio and Peff: - change commit message of patch 1/4 - added patch 4/4 that was pre

[PATCH v2 1/4] replace: add --graft option

2014-06-01 Thread Christian Couder
The usage string for this option is: git replace [-f] --graft [...] First we create a new commit that is the same as except that its parents are [...] Then we create a replace ref that replace with the commit we just created. With this new option, it should be straightforward to convert graf

[PATCH v2 3/4] Documentation: replace: add --graft option

2014-06-01 Thread Christian Couder
Signed-off-by: Christian Couder --- Documentation/git-replace.txt | 8 1 file changed, 8 insertions(+) diff --git a/Documentation/git-replace.txt b/Documentation/git-replace.txt index 61461b9..491875e 100644 --- a/Documentation/git-replace.txt +++ b/Documentation/git-replace.txt @@ -10,

[PATCH v2 4/4] contrib: add convert-grafts-to-replace-refs.sh

2014-06-01 Thread Christian Couder
This patch adds into contrib/ an example script to convert grafts from an existing grafts file into replace refs using the new --graft option of "git replace". While at it let's mention this new script in the "git replace" documentation for the --graft option. Signed-off-by: Christian Couder ---

Re: [PATCH v1 1/3] replace: add --graft option

2014-06-01 Thread Christian Couder
From: Jeff King > On Thu, May 22, 2014 at 11:33:04PM +0200, Christian Couder wrote: > >> The usage string for this option is: >> >> git replace [-f] --graft [...] >> >> First we create a new commit that is the same as >> except that its parents are [...] >> >> Then we create a replace ref t

[PATCH v3 2/9] connect.c: replace signal() with sigaction()

2014-06-01 Thread Jeremiah Mahler
>From the signal(2) man page: The behavior of signal() varies across UNIX versions, and has also var‐ ied historically across different versions of Linux. Avoid its use: use sigaction(2) instead. Replaced signal() with sigaction() in connect.c Signed-off-by: Jeremiah Mahler --- conne

[PATCH v3 1/9] compat/mingw.c: expand MinGW support for sigaction

2014-06-01 Thread Jeremiah Mahler
Due to portability issues across UNIX versions sigaction(2) should be used instead of signal(2). >From the signal(2) man page: The behavior of signal() varies across UNIX versions, and has also var‐ ied historically across different versions of Linux. Avoid its use: use sigaction(2) ins

[PATCH v3 0/9] replace signal() with sigaction()

2014-06-01 Thread Jeremiah Mahler
This is version 3 of the patch set to convert signal(2) to sigaction(2) (previous discussion [1]). [1]: http://marc.info/?l=git&m=140148352416926&w=2 Changes in this revision include: - Using NULL pointers instead of 0 as per the Documentation/CodingGuidlines pointed out by Chris Packham.

[PATCH v3 4/9] write_or_die.c: replace signal() with sigaction()

2014-06-01 Thread Jeremiah Mahler
>From the signal(2) man page: The behavior of signal() varies across UNIX versions, and has also var‐ ied historically across different versions of Linux. Avoid its use: use sigaction(2) instead. Replaced signal() with sigaction() in write_or_die.c Signed-off-by: Jeremiah Mahler ---

[PATCH v3 3/9] progress.c: replace signal() with sigaction()

2014-06-01 Thread Jeremiah Mahler
>From the signal(2) man page: The behavior of signal() varies across UNIX versions, and has also var‐ ied historically across different versions of Linux. Avoid its use: use sigaction(2) instead. Replaced signal() with sigaction() in progress.c Signed-off-by: Jeremiah Mahler --- prog

[PATCH v3 5/9] daemon.c: replace signal() with sigaction()

2014-06-01 Thread Jeremiah Mahler
>From the signal(2) man page: The behavior of signal() varies across UNIX versions, and has also var‐ ied historically across different versions of Linux. Avoid its use: use sigaction(2) instead. Replaced signal() with sigaction() in daemon.c Signed-off-by: Jeremiah Mahler --- daemon

[PATCH v3 6/9] builtin/log.c: replace signal() with sigaction()

2014-06-01 Thread Jeremiah Mahler
>From the signal(2) man page: The behavior of signal() varies across UNIX versions, and has also var‐ ied historically across different versions of Linux. Avoid its use: use sigaction(2) instead. Replaced signal() with sigaction() in builtin/log.c Signed-off-by: Jeremiah Mahler --- b

[PATCH v3 9/9] sigchain.c: replace signal() with sigaction()

2014-06-01 Thread Jeremiah Mahler
>From the signal(2) man page: The behavior of signal() varies across UNIX versions, and has also var‐ ied historically across different versions of Linux. Avoid its use: use sigaction(2) instead. Replaced signal() with sigaction() in sigchain.c Signed-off-by: Jeremiah Mahler --- sigc

[PATCH v3 8/9] builtin/verify-tag.c: replace signal() with sigaction()

2014-06-01 Thread Jeremiah Mahler
>From the signal(2) man page: The behavior of signal() varies across UNIX versions, and has also var‐ ied historically across different versions of Linux. Avoid its use: use sigaction(2) instead. Replaced signal() with sigaction() in builtin/verify-tag.c Signed-off-by: Jeremiah Mahler

[PATCH v3 7/9] builtin/merge-index.c: replace signal() with sigaction()

2014-06-01 Thread Jeremiah Mahler
>From the signal(2) man page: The behavior of signal() varies across UNIX versions, and has also var‐ ied historically across different versions of Linux. Avoid its use: use sigaction(2) instead. Replaced signal() with sigaction() in builtin/merge-index.c Signed-off-by: Jeremiah Mahler

Re: [PATCH v2 4/4] contrib: add convert-grafts-to-replace-refs.sh

2014-06-01 Thread Eric Sunshine
On Sun, Jun 1, 2014 at 11:10 AM, Christian Couder wrote: > This patch adds into contrib/ an example script to convert > grafts from an existing grafts file into replace refs using > the new --graft option of "git replace". > > While at it let's mention this new script in the > "git replace" docume

Re: [PATCH v4 1/2] refs.c: optimize check_refname_component()

2014-06-01 Thread Philip Oakley
From: "David Turner" In a repository with many refs, check_refname_component can be a major contributor to the runtime of some git commands. One such command is git rev-parse HEAD Timings for one particular repo, with about 60k refs, almost all packed, are: Old: 35 ms New: 29 ms Many other c

Re: [PATCH v4 1/2] refs.c: optimize check_refname_component()

2014-06-01 Thread Michael Haggerty
Thanks for splitting this up into two patches. See my comments below. On 06/01/2014 07:17 AM, David Turner wrote: > In a repository with many refs, check_refname_component can be a major > contributor to the runtime of some git commands. One such command is > > git rev-parse HEAD > > Timings fo

[no subject]

2014-06-01 Thread C. Benson Manica
The documentation for installing git from source here, http://git-scm.com/book/en/Getting-Started-Installing-Git, incorrectly fails to mention that the MakeMaker perl module is also required and is installable via $ yum install perl-ExtUtils-MakeMaker Also, you might want to let people know that

[PATCH 2/2] userdiff: support Java try keyword

2014-06-01 Thread Sup Yut Sum
try keyword is enhanced in Java 7, see try-with-resources Statement try (XX yy = new XX()) { } catch (Exception e){ } Signed-off-by: Sup Yut Sum --- userdiff.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/userdiff.c b/userdiff.c index 96eda6c..49e898b 100644 --- a/userdiff

[PATCH 1/2] userdiff: support C# async methods and correct C# keywords

2014-06-01 Thread Sup Yut Sum
async is in C# 5.0 foreach is in C# 1.0 instanceof is in Java. The similar keywords are typeof, is, as in C# 1.0 default, try are in C# 1.0 Signed-off-by: Sup Yut Sum --- userdiff.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/userdiff.c b/userdiff.c index fad52d6..96e

Re: [PATCH v3 1/9] compat/mingw.c: expand MinGW support for sigaction

2014-06-01 Thread Johannes Sixt
Am 6/1/2014 20:10, schrieb Jeremiah Mahler: > Due to portability issues across UNIX versions sigaction(2) should be used > instead of signal(2). > >>From the signal(2) man page: > > The behavior of signal() varies across UNIX versions, and has also var‐ > ied historically across different ver

[PATCH v5 1/2] refs.c: optimize check_refname_component()

2014-06-01 Thread David Turner
In a repository with many refs, check_refname_component can be a major contributor to the runtime of some git commands. One such command is git rev-parse HEAD Timings for one particular repo, with about 60k refs, almost all packed, are: Old: 35 ms New: 29 ms Many other commands which read refs

[PATCH v5 2/2] refs.c: SSE4.2 optimizations for check_refname_component

2014-06-01 Thread David Turner
Optimize check_refname_component using SSE4.2, where available. git rev-parse HEAD is a good test-case for this, since it does almost nothing except parse refs. For one particular repo with about 60k refs, almost all packed, the timings are: Look up table: 29 ms SSE4.2:25 ms This is abo

Re: [PATCH] sideband.c: Get rid of ANSI sequences for non-terminal shell

2014-06-01 Thread Jeff King
On Fri, May 30, 2014 at 11:10:51PM +, Naumov, Michael (North Sydney) wrote: > Some git tools such as GitExtensions for Windows use environment > variable TERM=msys which causes the weird ANSI sequence shown for the > messages returned from server-side hooks > We add those ANSI sequences to hel

Re: [ANNOUNCE] Git v2.0.0

2014-06-01 Thread Jeff King
On Sat, May 31, 2014 at 11:52:24AM +0200, David Kastrup wrote: > Some mailing list filters and/or spam filters flag mails with too many > recipients so that they need to pass through moderation first. The > typical threads on this list are short and have few recipients while > longer threads, due

Re: [PATCH] Improve function dir.c:trim_trailing_spaces()

2014-06-01 Thread Jeff King
On Sat, May 31, 2014 at 08:21:31AM -0700, Pasha Bolokhov wrote: > + char *p, *last_space = NULL; > + > + for (p = buf; *p; p++) > + if (*p == ' ') { > + if (!last_space) > + last_space = p; > + } else { > +

Re: [ANNOUNCE] Git v2.0.0

2014-06-01 Thread Felipe Contreras
Jeff King wrote: > On Sat, May 31, 2014 at 11:52:24AM +0200, David Kastrup wrote: > > And frankly, if I were a list moderator and software asked me through > > this sort of coincidence whether a mail should be delivered or not and a > > glance at it shows nothing but insults, wild accusations, thr