Re: [PATCH v12 11/20] index-helper: use watchman to avoid refreshing, index with lstat()

On 06/19/2016 01:07 AM, David Turner wrote: Duy Nguyen wrote: > On Fri, May 20, 2016 at 4:45 AM, David Turner wrote: > > diff --git a/read-cache.c b/read-cache.c > > index 1719f5a..8ec4be3 100644 > > --- a/read-cache.c > > +++ b/read-cache.c

Re: [PATCH v3 0/3] Introduce log.showSignature config variable

Mehul Jain writes: > In patch 2/3 and 3/3, there are many tests which requires a branch > similar to that of "signed" branch, i.e. a branch with a commit having > GPG signature. So previously in v2, I created two new branches, > "test_sign" and "no_sign", which are

Re: What's cooking in git.git (Jun 2016, #05; Thu, 16)

On 06/20/2016 09:57 AM, Lars Schneider wrote: > >> On 20 Jun 2016, at 01:51, Junio C Hamano wrote: >> >> Junio C Hamano writes: >> >>> Michael Haggerty writes: >>> According to [1], something in that test seems to have been

Re: [PATCH] pathspec: warn on empty strings as pathspec

Emily Xie writes: > Awesome. Thanks, Junio---this is exciting! No, thank _you_. > As for step 2: do you have a good sense on the timing? Around how long > should I wait to submit the patch for it? Not so fast. We'll wait for others to comment first. I am queuing this

Re: [PATCH] doc: git-htmldocs.googlecode.com is no more

Junio C Hamano writes: > On Wed, Jun 22, 2016 at 12:00 PM, Eric Wong wrote: >> >> Just wondering, who updates >> https://kernel.org/pub/software/scm/git/docs/ >> and why hasn't it been updated in a while? >> (currently it says Last updated 2015-06-06 at the

Italics formatting

Hi, I was looking for a way to use italics in my git log. I ended-up looking at the code dealing with colors and style and noticed that the italic code was skipped when defining the list (color.c:128 if I'm not mistaken). I'd love to propose a contribution but I'm sadly not very well versed

[PATCH 0/2] more ANSI attributes

On Thu, Jun 23, 2016 at 01:54:34PM +0200, Simon Courtois wrote: > I was looking for a way to use italics in my git log. I ended-up > looking at the code dealing with colors and style and noticed that the > italic code was skipped when defining the list (color.c:128 if I'm not > mistaken). > >

[PATCH 2/2] color: support "italic" attribute

We already support bold, underline, and similar attributes. Let's add italic to the mix. According to the Wikipedia page on ANSI colors, this attribute is "not widely supported", but it does seem to work on my xterm. We don't have to bump the maximum color size because we were already

Re: What's cooking in git.git (Jun 2016, #05; Thu, 16)

On 22/06/16 23:09, Joey Hess wrote: Torsten Bögershausen wrote: There is a conflict in pu: "jh/clean-smudge-annex" does not work together with "tb/convert-peek-in-index" (And currently pu didn't compile) I'm sending a v4 of jh/clean-smudge-annex that is rebased on top of

[PATCH 1/2] color: fix max-size comment

We use fixed-size buffers for colors, because we know our parsing cannot grow beyond a particular bound. However, our comment describing the max-size has two issues: 1. It has the description in two forms: a short one, and one with more explanation. Over time the latter has been

Re: [PATCH v12 11/20] index-helper: use watchman to avoid refreshing, index with lstat()

On Thu, Jun 23, 2016 at 8:24 AM, David Turner wrote: > So I'll remove it and re-roll (with some other changes) Please hold it for a few days. I wanted to have another look at this series, but I've been busy. I should be able to really look at it this weekend. -- Duy -- To

Re: [PATCH 2/2] color: support "italic" attribute

Wow I wasn't expecting such a rapid response, you're awesome! :-D Simon Courtois On 23 June 2016 at 15:10:33, Jeff King (p...@peff.net) wrote: > We already support bold, underline, and similar attributes. > Let's add italic to the mix. According to the Wikipedia > page on ANSI colors, this

Git Bash Slow in Windows (possible fix)

Ok, the subject may be a little misleading, but here is what happened. Back in February 2016, I installed Git-Bash on my Windows 7 computer and everything worked great. Git-Bash would execute commands as fast as the Windows command prompt. In June, Microsoft, in its infinite wisdom, decided to

GIT admin access

Hi, We need some help accessing our private Git as admin. The admin is currently unavailable and we need to provide access to a new Git user. Thanks & best regards, John AJAH-- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org

[PATCH v2 4/7] color: refactor parse_attr

The list of attributes we recognize is a bit unwieldy, as we actually have two arrays that must be kept in sync. Instead, let's have a single array-of-struct to represent our mapping. That means we can never have an accident that causes us to read off the end of an array, and it makes diffs for

[PATCH v2 5/7] color: allow "no-" for negating attributes

Using "no-bold" rather than "nobold" is easier to read and more natural to type (to me, anyway, even though I was the person who introduced "nobold" in the first place). It's easy to allow both. Signed-off-by: Jeff King --- Documentation/config.txt | 2 +- color.c

[PATCH v2 6/7] color: support "italic" attribute

We already support bold, underline, and similar attributes. Let's add italic to the mix. According to the Wikipedia page on ANSI colors, this attribute is "not widely supported", but it does seem to work on my xterm. We don't have to bump the maximum color size because we were already

Re: [PATCH v2 7/7] color: support strike-through attribute

Jeff King writes: > Hmm. I see the same thing screen and with tmux, as well (though I don't > usually use either myself). I suspect they have to filter ANSI codes > because they're using the codes themselves (so anything that moves the > cursor is going to be a definite problem),

[PATCH v2 3/7] add skip_prefix_mem helper

The skip_prefix function has been very useful for simplifying pointer arithmetic and avoiding repeated magic numbers, but we have no equivalent for length-limited buffers. So we're stuck with: if (3 <= len && skip_prefix(buf, "foo", )) len -= 3; That's not that complicated, but it

[PATCH v2 1/7] color: fix max-size comment

We use fixed-size buffers for colors, because we know our parsing cannot grow beyond a particular bound. However, our comment description has two issues: 1. It has the description in two forms: a short one, and one with more explanation. Over time the latter has been updated, but the

Re: [PATCH v2 6/7] color: support "italic" attribute

Jeff King writes: > We already support bold, underline, and similar attributes. > Let's add italic to the mix. According to the Wikipedia > page on ANSI colors, this attribute is "not widely > supported", but it does seem to work on my xterm. > ... > @@ -133,6 +133,7 @@ static

Re: [PATCH v2 7/7] color: support strike-through attribute

Junio C Hamano writes: > What is sad for me is that I usually work in GNU screen, displaying > on either xterm or gnome-terminal. Without screen, strike shows but > inside it I cannot seem to be able to get strike-thru in effect. ... which unfortunately is expected.

Re: [PATCH v2 7/7] color: support strike-through attribute

On Thu, Jun 23, 2016 at 11:52:51AM -0700, Junio C Hamano wrote: > >> It indeed is fun and it even makes sense in this context: > >> > >> $ ./git -c diff.color.old='red strike' show > > > > Ooh, I hadn't thought of that. It's a bit noisy for my tastes in a > > line-oriented diff, but with

Re: [PATCH] diff compaction heuristic: favor shortest neighboring blank lines

On Thu, Jun 23, 2016 at 10:10 AM, Michael Haggerty wrote: > On 06/17/2016 06:09 PM, Stefan Beller wrote: >> I think before spending more time on discussing and implementing new >> (hopefully better) heuristics, I'd want to step back and try to be a bit more >> systematic,

Re: [PATCH v3] Refactor recv_sideband()

On Thu, 23 Jun 2016 at 00:47:39, Nicolas Pitre wrote: > On Wed, 22 Jun 2016, Nicolas Pitre wrote: > [...] > > if (*b) { > > xwrite(STDERR_FILENO, outbuf.buf, outbuf.len); > > /* Incomplete line, skip the next prefix. */ > >

Re: [PATCH v2 7/7] color: support strike-through attribute

Jeff King writes: > This is the only remaining attribute that is commonly > supported (at least by xterm) that we don't support. Let's > add it for completeness. > > Signed-off-by: Jeff King > --- > This was mostly for fun. I can't think of a way in which it would

Re: [PATCH] diff compaction heuristic: favor shortest neighboring blank lines

On 06/17/2016 06:09 PM, Stefan Beller wrote: > I think before spending more time on discussing and implementing new > (hopefully better) heuristics, I'd want to step back and try to be a bit more > systematic, i.e. I'll want to collect lots of test cases in different > languages > and use cases.

Re: [PATCH] diff compaction heuristic: favor shortest neighboring blank lines

Michael Haggerty writes: > Scoring heuristic: > >> # A place to accumulate bonus factors (positive makes this >> # index more favored): >> bonus = 0 >> >> # Bonuses based on the location of blank lines: >> if pre_blank and not blank: >> bonus +=

Re: [PATCH v2 7/7] color: support strike-through attribute

On Thu, Jun 23, 2016 at 11:36:23AM -0700, Junio C Hamano wrote: > Jeff King writes: > > > This is the only remaining attribute that is commonly > > supported (at least by xterm) that we don't support. Let's > > add it for completeness. > > > > Signed-off-by: Jeff King

Re: [PATCH v2 7/7] color: support strike-through attribute

Jeff King writes: > On Thu, Jun 23, 2016 at 11:36:23AM -0700, Junio C Hamano wrote: > >> Jeff King writes: >> >> > This is the only remaining attribute that is commonly >> > supported (at least by xterm) that we don't support. Let's >> > add it for completeness.

Re: GIT admin access

Brigning this back on list so that someone else can help... On Thursday, June 23, 2016 05:01:18 PM John Ajah wrote: > I'm on a private git, installed on a work server. Now the > guy who set it up is not available and I want to give > access to someone working for me, but I don't know how to > do

Re: [PATCH 2/2] color: support "italic" attribute

On Thu, Jun 23, 2016 at 09:46:57AM -0700, Junio C Hamano wrote: > > diff --git a/Documentation/config.txt b/Documentation/config.txt > > index 58673cf..4b97d8d 100644 > > --- a/Documentation/config.txt > > +++ b/Documentation/config.txt > > @@ -154,7 +154,7 @@ color:: > > colors (at most

[PATCH v2 2/7] doc: refactor description of color format

This is a general cleanup of the description of colors in git-config, mostly to address inaccuracies and confusion that had grown over time: - you can have many attributes, not just one - the discussion flip-flopped between colors and attributes; now we discuss everything about colors,

[PATCH v2 7/7] color: support strike-through attribute

This is the only remaining attribute that is commonly supported (at least by xterm) that we don't support. Let's add it for completeness. Signed-off-by: Jeff King --- This was mostly for fun. I can't think of a way in which it would be useful, and I'm not sure how compelling

Re: [PATCH 1/2] archive-tar: write extended headers for file sizes >= 8GB

On Wed, Jun 22, 2016 at 07:46:13AM +0200, René Scharfe wrote: > Yes, it's only useful as a debug flag, but the fact that it breaks > highlights a (admittedly mostly theoretical) shortcoming: The code doesn't > handle extended headers that are over the size limit as nicely as it could. > So the

Re: [PATCH 05/11] grep/icase: avoid kwsset when -F is specified

Nguyễn Thái Ngọc Duy writes: > @@ -408,7 +427,11 @@ static void compile_regexp(struct grep_pat *p, struct > grep_opt *opt) > ascii_only = !has_non_ascii(p->pattern); > > if (opt->fixed) { > - p->fixed = 1; > + p->fixed = !icase ||

Re: [PATCH v2 6/7] color: support "italic" attribute

On Thu, Jun 23, 2016 at 11:34:00AM -0700, Junio C Hamano wrote: > Jeff King writes: > > > We already support bold, underline, and similar attributes. > > Let's add italic to the mix. According to the Wikipedia > > page on ANSI colors, this attribute is "not widely > >

Re: [PATCH v3] Refactor recv_sideband()

On Thu, 23 Jun 2016, Lukas Fleischer wrote: > On Thu, 23 Jun 2016 at 00:47:39, Nicolas Pitre wrote: > > On Wed, 22 Jun 2016, Nicolas Pitre wrote: > > [...] > > > if (*b) { > > > xwrite(STDERR_FILENO, outbuf.buf, outbuf.len); > > > /*

Re: [PATCH 09/11] diffcore-pickaxe: "share" regex error handling code

On Thu, Jun 23, 2016 at 06:29:05PM +0200, Nguyễn Thái Ngọc Duy wrote: > diff --git a/diffcore-pickaxe.c b/diffcore-pickaxe.c > index 7715c13..69c6567 100644 > --- a/diffcore-pickaxe.c > +++ b/diffcore-pickaxe.c > @@ -204,20 +204,13 @@ void diffcore_pickaxe(struct diff_options *o) > int opts

Re: [PATCH 2/2] archive-tar: write extended headers for far-future mtime

On Wed, Jun 22, 2016 at 07:46:25AM +0200, René Scharfe wrote: > Am 21.06.2016 um 00:54 schrieb René Scharfe: > > Am 16.06.2016 um 06:37 schrieb Jeff King: > > >2. System tars that cannot handle pax headers. > > > > In t5000 there is a simple interpreter for path headers for systems > > whose

Re: [PATCH v2 7/7] color: support strike-through attribute

Jeff King writes: > ... but with --color-words, it actually helps quite a > bit (try it on the documentation patch from this series, for example). This gets me back to another tangent, but this time a one that is quite a lot more relevant to Git. There is this change in "git

Re: [PATCH] diff compaction heuristic: favor shortest neighboring blank lines

On 06/23/2016 07:37 PM, Junio C Hamano wrote: > Michael Haggerty writes: > >> Scoring heuristic: >> >>> # A place to accumulate bonus factors (positive makes this >>> # index more favored): >>> bonus = 0 >>> >>> # Bonuses based on the location of blank

Re: [PATCH 04/11] grep/icase: avoid kwsset on literal non-ascii strings

Nguyễn Thái Ngọc Duy writes: > static void compile_regexp(struct grep_pat *p, struct grep_opt *opt) > { > + int icase, ascii_only; > int err; > > p->word_regexp = opt->word_regexp; > p->ignore_case = opt->ignore_case; > + icase =

What's cooking in git.git (Jun 2016, #08; Thu, 23)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear in any of the integration branches, but I am still holding onto them. The first batch for this cycle

Re: [PATCH 2/2] archive-tar: write extended headers for far-future mtime

Am 23.06.2016 um 21:22 schrieb Jeff King: On Wed, Jun 22, 2016 at 07:46:25AM +0200, René Scharfe wrote: Am 21.06.2016 um 00:54 schrieb René Scharfe: Am 16.06.2016 um 06:37 schrieb Jeff King: 2. System tars that cannot handle pax headers. In t5000 there is a simple interpreter for path

Re: [PATCH 2/2] archive-tar: write extended headers for far-future mtime

On Thu, Jun 23, 2016 at 11:38:19PM +0200, René Scharfe wrote: > > Yeah, I had a similar thought while writing it, but wasn't quite sure > > how that was supposed to be formatted. I modeled my output after what > > GNU tar writes, but of course they are expecting a different mtime for > > each

[PATCH v3 3/4] archive-tar: write extended headers for far-future mtime

The ustar format represents timestamps as seconds since the epoch, but only has room to store 11 octal digits. To express anything larger, we need to use an extended header. This is exactly the same case we fixed for the size field in the previous commit, and the solution here follows the same

[PATCH v3 1/4] t5000: test tar files that overflow ustar headers

The ustar format only has room for 11 (or 12, depending on some implementations) octal digits for the size and mtime of each file. After this, we have to add pax extended headers to specify the real data, and git does not yet know how to do so. Before fixing that, let's start off with some test

[PATCH v3 2/4] archive-tar: write extended headers for file sizes >= 8GB

The ustar format has a fixed-length field for the size of each file entry which is supposed to contain up to 11 bytes of octal-formatted data plus a NUL or space terminator. These means that the largest size we can represent is 0777, or 1 byte short of 8GB. The correct solution for a

[PATCH v3 4/4] archive-tar: drop return value

We never do any error checks, and so never return anything but "0". Let's just drop this to simplify the code. Signed-off-by: Jeff King --- I wasn't sure if this was perhaps kept as an interface decision, in case the function grew errors later on. If so, it can still drop the

Re: [PATCH v3 1/4] t5000: test tar files that overflow ustar headers

On Thu, Jun 23, 2016 at 07:20:44PM -0400, Jeff King wrote: > I'm still not excited about the 64MB write, just because it's awfully > heavyweight for such a trivial test. It runs pretty fast on my RAM disk, > but maybe not on other people's system. > > I considered but didn't explore two other

Re: [PATCH 2/2] color: support "italic" attribute

Jeff King writes: > We already support bold, underline, and similar attributes. > Let's add italic to the mix. According to the Wikipedia > page on ANSI colors, this attribute is "not widely > supported", but it does seem to work on my xterm. > > We don't have to bump the maximum

[PATCH v2 0/7] more ANSI attributes

Here's a re-roll of my earlier patches to add "italic" support. It fixes the documentation problem Junio mentioned (along with some other issues there). It also cleans up parse_attr() to make it a bit easier to read and maintain, and adds a few more features. [1/7]: color: fix max-size comment

[PATCH v3] friendlier handling of overflows in archive-tar

This is a replacement for the jk/big-and-future-archive-tar topic. It's sufficiently rewritten that I won't bother with an interdiff, but rather just describe the changes below. Thanks to René for talking through some of the issues, and to Robin for suggesting the double-compression trick for the

Re: Git Bash Slow in Windows (possible fix)

Hi Michael, First up, Git for Windows has a dedicated issue tracker over at https://github.com/git-for-windows/git/issues you may want to submit a bug report there (reference this email if it's easier). On 24 June 2016 at 02:02, UberBooster wrote: > > Back in February

Re: [PATCH 00/11] nd/icase updates

Nguyễn Thái Ngọc Duy writes: > This update drops 1/12, which is an unnecessary change, and changes a > couple of echo/printf to test_write_lines. One of those echo uses > backlashes and causes problems with Debian dash. > > Interdiff therefore is not really interesting

[PATCH] unpack-trees: fix English grammar in do-this-before-that messages

Signed-off-by: Alex Henrie --- unpack-trees.c | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/unpack-trees.c b/unpack-trees.c index 6bc9512..11c37fb 100644 --- a/unpack-trees.c +++ b/unpack-trees.c @@ -62,17 +62,17 @@ void

Re: Subtree Split Includes Commits Outside Prefix Directory

Attempting to resend without HTML... - Harpreet "Eli" Sangha On Thu, Jun 23, 2016 at 7:18 PM, ELI wrote: > Sorry for the delayed response... your email somehow found it's way into my > Gmail spam folder. > > I've created a simple reproduction case and hosted the test

[PATCH 00/11] nd/icase updates

This update drops 1/12, which is an unnecessary change, and changes a couple of echo/printf to test_write_lines. One of those echo uses backlashes and causes problems with Debian dash. Interdiff therefore is not really interesting diff --git a/builtin/grep.c b/builtin/grep.c index

[PATCH 01/11] grep: break down an "if" stmt in preparation for next changes

Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano --- grep.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/grep.c b/grep.c index 7b2b96a..609f218 100644 --- a/grep.c +++ b/grep.c @@ -403,7 +403,9 @@ static void

[PATCH 05/11] grep/icase: avoid kwsset when -F is specified

Similar to the previous commit, we can't use kws on icase search outside ascii range. But we can't simply pass the pattern to regcomp/pcre like the previous commit because it may contain regex special characters, so we need to quote the regex first. To avoid misquote traps that could lead to

[PATCH 04/11] grep/icase: avoid kwsset on literal non-ascii strings

When we detect the pattern is just a literal string, we avoid heavy regex engine and use fast substring search implemented in kwsset.c. But kws uses git-ctype which is locale-independent so it does not know how to fold case properly outside ascii range. Let regcomp or pcre take care of this case

[PATCH 02/11] test-regex: isolate the bug test code

This is in preparation to turn test-regex into some generic regex testing command. Helped-by: Eric Sunshine Helped-by: Ramsay Jones Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano ---

[PATCH 06/11] grep/pcre: prepare locale-dependent tables for icase matching

The default tables are usually built with C locale and only suitable for LANG=C or similar. This should make case insensitive search work correctly for all single-byte charsets. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano --- grep.c

[PATCH 11/11] grep.c: reuse "icase" variable

Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano --- grep.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/grep.c b/grep.c index 6e99b01..cb058a5 100644 --- a/grep.c +++ b/grep.c @@ -445,10 +445,7 @@ static void

[PATCH 10/11] diffcore-pickaxe: support case insensitive match on non-ascii

Similar to the "grep -F -i" case, we can't use kws on icase search outside ascii range, so we quote the string and pass it to regcomp as a basic regexp and let regex engine deal with case sensitivity. The new test is put in t7812 instead of t4209-log-pickaxe because lib-gettext.sh might cause

[PATCH 07/11] gettext: add is_utf8_locale()

This function returns true if git is running under an UTF-8 locale. pcre in the next patch will need this. is_encoding_utf8() is used instead of strcmp() to catch both "utf-8" and "utf8" suffixes. When built with no gettext support, we peek in several env variables to detect UTF-8. pcre library

[PATCH 08/11] grep/pcre: support utf-8

In the previous change in this function, we add locale support for single-byte encodings only. It looks like pcre only supports utf-* as multibyte encodings, the others are left in the cold (which is fine). We need to enable PCRE_UTF8 so pcre can find character boundary correctly. It's needed for

[PATCH 09/11] diffcore-pickaxe: "share" regex error handling code

There's another regcomp code block coming in this function. By moving the error handling code out of this block, we don't have to add the same error handling code in the new block. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano ---

[PATCH 03/11] test-regex: expose full regcomp() to the command line

Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano --- test-regex.c | 51 +-- 1 file changed, 49 insertions(+), 2 deletions(-) diff --git a/test-regex.c b/test-regex.c index 67a1a65..eff26f5