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 setup_unpack_trees_porcelain(struct
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 repositories on
> BitBucket
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 2016, I installed Git-Bash
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 opt
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 "err"
variable inter
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 large
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
pat
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
in
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 t
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 has
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 file
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 h
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
Neither Debian dash (that
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 || ascii_only;
> +
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 lines:
>>> if pre_blank
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 = opt->regflags & REG_ICASE |
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 show --word-diff" f
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
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 tes
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
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), and strike-throu
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 --co
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.
https://www.gnu.org/softwar
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);
> > > /*
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 t
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.
>> >
>> > Signed-off-by: Jeff Ki
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
> > ---
> > This was mostl
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 be
> useful, and I'm not sure
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
> > supported", but it does se
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 int parse_attr(con
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 completionism is as
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 | 4 +++-
t/t4
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 over-alloca
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 add
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 += 3
>> elif blank an
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. */
> >
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", &buf))
len -= 3;
That's not that complicated, but it
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, th
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 f
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
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, i.e. I'll want to collect
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. A
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 t
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 color size beca
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 prob
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 m
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 | 8 ++
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 compile_regexp(struct grep_pat *p, struct
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
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
---
diffcore-pickaxe.c | 16
1
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 100644
--- a/test-regex.c
+++ b/test-rege
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 46c5ba1..8c516a
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 compile_regexp(struct grep_pat *p, struct
g
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 undef
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 in
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
---
t/t0070-fundamental.sh | 2 +-
test-regex.c | 12 ++--
2 files changed,
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 s
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 unsubscribe from this l
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
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 attrib
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 over-alloca
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 update
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
tb/convert-peek-in-i
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).
>
> I'd
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 wit
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 trying to run
git update-ref -d git-p4-tmp/6
>>>
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 bottom)
>
> Nobody. It is too cumberso
67 matches
Mail list logo
