Re: [PATCH v2 02/38] rename_ref_available(): add docstring

On 09/06/2016 04:25 PM, Jakub Narębski wrote: > W dniu 04.09.2016 o 18:08, Michael Haggerty pisze: > >> +/* >> + * Check whether an attempt to rename old_refname to new_refname would >> + * cause a D/F conflict with any existing reference (other than >> + * possibly old_refname). If there would

Re: Draft of Git Rev News edition 18

Josh Triplett wrote: > On Tue, Aug 16, 2016 at 09:27:04PM +, Eric Wong wrote: > > As for other projects, I'm not aware of anybody else using it, > > yet. I have some small projects using it, but most of those are > > one-off throwaways and I'm not comfortable promoting

Re: [PATCH] sequencer: support folding in rfc2822 footer

On 09/06/2016 03:08 PM, Jonathan Tan wrote: On 09/02/2016 07:23 PM, Junio C Hamano wrote: A slightly related tangent. An unconditionally good change you could make is to allow folding of in-body headers. I.e. you can have e.g. -- >8 -- Subject: [PATCH] sequencer: support in-body

Re: [PATCH] sequencer: support folding in rfc2822 footer

On 09/02/2016 07:23 PM, Junio C Hamano wrote: Jonathan Tan writes: Sample-field: multiple-line field body that causes a blank line below I am not sure this is unconditionally good, or may cause problems to those with workflows you did not consider when you wrote

Re: [PATCH v1 2/2] read-cache: make sure file handles are not inherited by child processes

larsxschnei...@gmail.com wrote: > static int ce_compare_data(const struct cache_entry *ce, struct stat *st) > { > int match = -1; > - int fd = open(ce->name, O_RDONLY); > + int fd = open(ce->name, O_RDONLY | O_CLOEXEC); > > if (fd >= 0) { > unsigned char

Re: How to simulate a real checkout to test a new smudge filter?

On 9/6/16, Torsten Bögershausen wrote: > On 06.09.16 19:47, john smith wrote: >> I am looking for a way to force smudge filter to run by simulating a >> real life checkout. Let's say I just created a new branch and did not >> modify any files but want to test my new smudge filter.

Re: Your email

Johannes, You know what, lets end it. You are right and I am sorry. Have a great life. -- -Best Idan

Re: If a branch moves a submodule, "merge --ff[-only]" succeeds while "merge --no-ff" fails with conflicts

On Tue, Sep 6, 2016 at 3:00 PM, Stefan Beller wrote: > On Fri, Sep 2, 2016 at 12:22 PM, Dakota Hawkins > wrote: >> Below is a simple reproduction of the issue. >> >> The _real_ problem is that this is how our pull request merges work, > > So your

Re: How to simulate a real checkout to test a new smudge filter?

On 06.09.16 19:47, john smith wrote: > I am looking for a way to force smudge filter to run by simulating a > real life checkout. Let's say I just created a new branch and did not > modify any files but want to test my new smudge filter. According to > some answers such as >

Re: 2.10.0: multiple versionsort.prereleasesuffix buggy?

Hi, Quoting Jeff King : On Tue, Sep 06, 2016 at 03:07:59AM +0200, SZEDER Gábor wrote: So that seems wrong. Even weirder, if I set _only_ "-beta", I get: $ git tag -l --sort=version:refname | grep -v ^2.6.0 2.6.0-beta-2 2.6.0-beta-3 2.6.0-beta-4 2.6.0 2.6.0-RC1

[PATCH] gitweb: use highlight's shebang detection

The highlight binary can detect language by shebang when we can't tell the syntax type by the name of the file. To use highlight's shebang detection, add highlight to the pipeline whenever highlight is enabled. Document the shebang detection and add a test which exercises it in

Re: Fixup of a fixup not working right

From: "Johannes Schindelin" Hi Philip, On Sun, 4 Sep 2016, Philip Oakley wrote: From: "Johannes Schindelin" > The point is that fixup! messages are really special, and are always > intended to be squashed into the referenced commit

Re: If a branch moves a submodule, "merge --ff[-only]" succeeds while "merge --no-ff" fails with conflicts

On Fri, Sep 2, 2016 at 12:22 PM, Dakota Hawkins wrote: > Below is a simple reproduction of the issue. > > The _real_ problem is that this is how our pull request merges work, So your workflow is the problem or is the actual bug just exposed in your workflow? > they're

[PATCH v2] rebase -i: improve advice on bad instruction lines

If we found bad instruction lines in the instruction sheet of interactive rebase, we give the user advice on how to fix it. However, we don't tell the user what to do afterwards. Give the user advice to run 'git rebase --continue' after the fix. Signed-off-by: Ralf Thielow

Re: [PATCH v14 00/41] libify apply and use lib in am, part 2

On Sun, Sep 4, 2016 at 1:17 PM, Christian Couder wrote: > Goal > > > This is a patch series about libifying `git apply` functionality, and > using this libified functionality in `git am`, so that no 'git apply' > process is spawn anymore. This makes `git am`

Re: [PATCH] rebase -i: improve advice on bad instruction lines

2016-09-06 20:08 GMT+02:00 Ralf Thielow : > - warn "$(gettext "You can fix this with 'git rebase > --edit-todo'.")" > + warn "$(gettext "You can fix this with 'git rebase > --edit-todo' and then run 'git rebase --continue'.")" >

Re: [PATCH 1/3] Demonstrate a problem: our pickaxe code assumes NUL-terminated buffers

On Mon, Sep 05, 2016 at 05:45:02PM +0200, Johannes Schindelin wrote: > Typically, on Linux the test passes. On Windows, it fails virtually > every time due to an access violation (that's a segmentation fault for > you Unix-y people out there). And Windows would be correct: the > regexec() call

Re: [PATCH 2/3] diff_populate_filespec: NUL-terminate buffers

On Tue, Sep 06, 2016 at 06:02:59PM +0200, Johannes Schindelin wrote: > It will still be quite tricky, because we have to touch a function that is > rather at the bottom of the food chain: diff_populate_filespec() is called > from fill_textconv(), which in turn is called from pickaxe_match(), and

Re: If a branch moves a submodule, "merge --ff[-only]" succeeds while "merge --no-ff" fails with conflicts

Is there any additional information I could provide that would be helpful? Dakota On Fri, Sep 2, 2016 at 3:22 PM, Dakota Hawkins wrote: > Below is a simple reproduction of the issue. > > The _real_ problem is that this is how our pull request merges work, > they're not

Re: [PATCH 0/3] Fix a segfault caused by regexec() being called on mmap()ed data

On Tue, Sep 06, 2016 at 04:06:32PM +0200, Johannes Schindelin wrote: > > I think re_search() the correct replacement function but it's been a > > while since I've looked into it. > > The segfault I investigated happened in a call to strlen(). I see many > calls to strlen() in compat/regex/...

Re: [PATCH v14 30/41] Move libified code from builtin/apply.c to apply.{c,h}

On Sun, Sep 4, 2016 at 1:18 PM, Christian Couder wrote: > As most of the apply code in builtin/apply.c has been libified by a number of > previous commits, it can now be moved to apply.{c,h}, so that more code can > use it. > > Helped-by: Nguyễn Thái Ngọc Duy

[PATCH] rebase -i: improve advice on bad instruction lines

If we found bad instruction lines in the instruction sheet of interactive rebase, we give the user advice on how to fix it. However, we don't tell the user what to do afterwards. Give the user advice to run 'git rebase --continue' after the fix. Signed-off-by: Ralf Thielow

Bug? ran into a "fatal" using interactive rebase

Hi, today I accidentally triggered a "fatal" using interactive rebase. If you edit the instruction sheet after 'rebase -i' and add an unknown command, Git stops because it doesn't know the command. That's fine, however, now we are in a state where 'git status' fails with interactive rebase in

Git Miniconference at Plumbers

Folks, I have recently been enlisted by folks at the Linux Foundation to help run a Miniconference on Git at the Plumbers Conference [*] this fall. We currently have both Junio Hamano and Josh Triplett signed up to do talks. Hopefully, though not confirmed yet, Junio will give us a brief

Re: [PATCH] xdiff: remove unneeded declarations

On Fri, Sep 2, 2016 at 8:16 PM, Stefan Beller wrote: > Signed-off-by: Stefan Beller > --- > xdiff/xemit.c | 9 - > 1 file changed, 9 deletions(-) Despite the moved coloring patch moving into a different direction, I think this is still an

Re: [PATCHv4] diff.c: emit moved lines with a different color

W dniu 06.09.2016 o 19:03, Stefan Beller pisze: > On Tue, Sep 6, 2016 at 7:05 AM, Jakub Narębski wrote: >> If not for `color.moved`, I would have thought that instead of adding >> new command line option `--color-moved` (and the fact that it is on >> by default), we could

How to simulate a real checkout to test a new smudge filter?

I am looking for a way to force smudge filter to run by simulating a real life checkout. Let's say I just created a new branch and did not modify any files but want to test my new smudge filter. According to some answers such as

Re: [PATCHv4] diff.c: emit moved lines with a different color

On Tue, Sep 6, 2016 at 7:05 AM, Jakub Narębski wrote: > W dniu 06.09.2016 o 09:01, Stefan Beller pisze: > >> --- >> >> * moved new data structures into struct diff_options >> * color.moved=bool as well as --[no-]color-moved to {dis,en}able the new >> feature >> *

Re: [WIP PATCH v2] diff.c: emit moved lines with a different color

On Tue, Sep 6, 2016 at 5:44 AM, Junio C Hamano wrote: > By the way, not running xdiff twice would also remove another worry > I have about correctness, in that the approach depends on xdiff > machinery to produce byte-for-byte identical result given the same > pair of input.

Re: [PATCH] gpg-interface: reflect stderr to stderr

Hi Michael, okay, final mail on this issue today: On Tue, 6 Sep 2016, Johannes Schindelin wrote: > Your original issue seemed to be that the gpg command could succeed, but > still no signature be seen. There *must* be a way to test whether the > called program added a signature, simply by

Re: [PATCH] Unbreak interactive GPG prompt upon signing

Hi Michael, On Tue, 6 Sep 2016, Michael J Gruber wrote: > Johannes Schindelin venit, vidit, dixit 06.09.2016 10:01: > > With the recent update in efee955 (gpg-interface: check gpg signature > > creation status, 2016-06-17), we ask GPG to send all status updates to > > stderr, and then catch the

Re: Windows Git will not start external diff at all

Hi Jaakko, On Tue, 6 Sep 2016, Jaakko Pääkkönen wrote: > I am using beyond compare, but it does not really matter which one > because even I create a dummy script as a external diff program, it > will not get called ever. Only internal diff is started. Any chance you can come up with an MCVE

Re: [PATCH] gpg-interface: reflect stderr to stderr

Hi Michael, On Tue, 6 Sep 2016, Michael J Gruber wrote: > efee955 ("gpg-interface: check gpg signature creation status", > 2016-06-17) used stderr to capture gpg's status output, which is the > only reliable way for status checks. As a side effect, stderr was not > shown to the user any more. >

Re: Your email

Hi Idan, please only write public mails when discussing Open Source. On Tue, 6 Sep 2016, Idan Shimoni wrote: > "This" top-posting is auto generated when hitting on the magic button > called "Reply", and it is the generic way that the industry works. How > do you expect me to know that this is

[PATCH v2 5/6] git-gui: Update Japanese translation

Signed-off-by: Satoshi Yasushima --- po/ja.po | 77 +--- 1 file changed, 35 insertions(+), 42 deletions(-) diff --git a/po/ja.po b/po/ja.po index 23974cc..deaf8e3 100644 --- a/po/ja.po +++ b/po/ja.po @@ -102,6

[PATCH v2 2/6] git-gui: consistently use the same word for "blame" in Japanese

Signed-off-by: Satoshi Yasushima --- po/ja.po | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/po/ja.po b/po/ja.po index 8a2c16f..b692b5c 100644 --- a/po/ja.po +++ b/po/ja.po @@ -598,7 +598,7 @@ msgstr "文脈を見せる" #: lib/blame.tcl:291 msgid "Blame

[PATCH v2 6/6] git-gui: Update Japanese information

Signed-off-by: Satoshi Yasushima --- po/ja.po | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/po/ja.po b/po/ja.po index deaf8e3..208651c 100644 --- a/po/ja.po +++ b/po/ja.po @@ -1,15 +1,17 @@ # Translation of git-gui to Japanese # Copyright (C)

[PATCH v2 4/6] git-gui: Add Japanese language code

Signed-off-by: Satoshi Yasushima --- po/ja.po | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/po/ja.po b/po/ja.po index b140e8b..23974cc 100644 --- a/po/ja.po +++ b/po/ja.po @@ -11,7 +11,7 @@ msgstr "" "PO-Revision-Date: 2010-02-02 19:03+0900\n"

Re: [PATCH 3/3] diff_grep: add assertions verifying that the buffers are NUL-terminated

Hi Peff, On Tue, 6 Sep 2016, Jeff King wrote: > On Mon, Sep 05, 2016 at 05:45:09PM +0200, Johannes Schindelin wrote: > > > Before calling regexec() on the file contents, we better be certain that > > the strings fulfill the contract of C strings assumed by said function. > > If you have a

[PATCH v2 1/6] git-gui: consistently use the same word for "remote" in Japanese

Signed-off-by: Satoshi Yasushima --- po/ja.po | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/po/ja.po b/po/ja.po index 9aff249..8a2c16f 100644 --- a/po/ja.po +++ b/po/ja.po @@ -765,7 +765,8 @@ msgstr "トラッキング・ブランチを選択して下さい。" #:

Re: [PATCH 2/3] diff_populate_filespec: NUL-terminate buffers

Hi Peff, On Tue, 6 Sep 2016, Jeff King wrote: > On Mon, Sep 05, 2016 at 05:45:06PM +0200, Johannes Schindelin wrote: > > > It is true that many code paths populate the mmfile_t structure > > silently appending a NUL, e.g. when running textconv on a temporary > > file and reading the results

Windows Git will not start external diff at all

Hi I am using beyond compare, but it does not really matter which one because even I create a dummy script as a external diff program, it will not get called ever. Only internal diff is started. Re-installing git will not remove the problem. I am using the latest git Any hints how I can debug

Re: [PATCH] introduce hex2chr() for converting two hexadecimal digits to a character

Am 04.09.2016 um 09:49 schrieb Johannes Schindelin: Hi René, On Sat, 3 Sep 2016, René Scharfe wrote: Add and use a helper function that decodes the char value of two hexadecimal digits. It returns a negative number on error, avoids running over the end of the given string and doesn't shift

Re: [PATCH] compat: move strdup(3) replacement to its own file

Am 04.09.2016 um 09:46 schrieb Johannes Schindelin: Hi René, I imagine you Cc:ed me because the nedmalloc stuff came in via the Windows port, contributed by Marius (who is no longer active on the Git project because it works well enough for him)? Kind of; it's also a follow-up to the recent

h

Sent from my iPhone

Re: [PATCH v2 02/38] rename_ref_available(): add docstring

W dniu 04.09.2016 o 18:08, Michael Haggerty pisze: > +/* > + * Check whether an attempt to rename old_refname to new_refname would > + * cause a D/F conflict with any existing reference (other than > + * possibly old_refname). If there would be a conflict, emit an error > + * message and return

Re: [PATCH 0/3] Fix a segfault caused by regexec() being called on mmap()ed data

Hi Peff, On Tue, 6 Sep 2016, Jeff King wrote: > On Mon, Sep 05, 2016 at 05:44:57PM +0200, Johannes Schindelin wrote: > > > The problem with that: mmap()ed memory is *not* NUL-terminated, yet > > the pickaxe code calls regexec() on it just the same. > > > > This problem has been reported by my

Re: [PATCH 0/3] Fix a segfault caused by regexec() being called on mmap()ed data

Hi Peff & Junio, On Tue, 6 Sep 2016, Jeff King wrote: > On Mon, Sep 05, 2016 at 12:10:11PM -0700, Junio C Hamano wrote: > > > * We could use variant of regexp engine as you proposed, > >which I think is a preferrable solution. Do people know of a > >widely accepted

Re: [PATCHv4] diff.c: emit moved lines with a different color

W dniu 06.09.2016 o 09:01, Stefan Beller pisze: > --- > > * moved new data structures into struct diff_options > * color.moved=bool as well as --[no-]color-moved to {dis,en}able the new > feature > * color.diff.movedfrom and color.diff.movedto to control the colors > * added a test [...] >

Re: [PATCHv4] diff.c: emit moved lines with a different color

On 06/09/16 08:01, Stefan Beller wrote: [snip] > This patch was motivated by e.g. reviewing 3b0c4200 ("apply: move > libified code from builtin/apply.c to apply.{c,h}", 2016-08-08) > > Signed-off-by: Stefan Beller > --- > > * moved new data structures into struct

Re: [PATCH 0/3] Fix a segfault caused by regexec() being called on mmap()ed data

Hi Junio, On Mon, 5 Sep 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > > This patch series addresses a problem where `git diff` is called using > > `-G` or `-S --pickaxe-regex` on new-born files that are configured > > without user diff drivers, and

[PATCH] gpg-interface: reflect stderr to stderr

efee955 ("gpg-interface: check gpg signature creation status", 2016-06-17) used stderr to capture gpg's status output, which is the only reliable way for status checks. As a side effect, stderr was not shown to the user any more. In case of a gpg error, reflect the whole captured buffer to

Re: [WIP PATCH v2] diff.c: emit moved lines with a different color

Stefan Beller writes: > This new coloring is linear to the size of the patch, i.e. O(number of > added/removed lines) in memory and for computational efforts I'd > think it is O(n log n) as inserting into the hashmap is an amortized > log n. In addition to that O(n log n)

Re: [PATCH] Unbreak interactive GPG prompt upon signing

Johannes Schindelin venit, vidit, dixit 06.09.2016 10:01: > With the recent update in efee955 (gpg-interface: check gpg signature > creation status, 2016-06-17), we ask GPG to send all status updates to > stderr, and then catch the stderr in an strbuf. > > But GPG might fail, and send error

Re: Context Menu is missing

Hi Idan, On Tue, 6 Sep 2016, Idan Shimoni wrote: > ??? Please understand that you continue to annoy Stefan, who is only trying to help you, by adding your replies *above* the quoted email. This is called top-posting and considered very, very rude on this mailing list. Also, your replies are

Re: [PATCH v1 2/2] read-cache: make sure file handles are not inherited by child processes

Hi Lars, On Mon, 5 Sep 2016, larsxschnei...@gmail.com wrote: > [... commit message ...] Makes sense. > diff --git a/read-cache.c b/read-cache.c > index 491e52d..02f74d3 100644 > --- a/read-cache.c > +++ b/read-cache.c > @@ -156,7 +156,7 @@ void fill_stat_cache_info(struct cache_entry *ce,

Re: [PATCH v1 1/2] sha1_file: open window into packfiles with CLOEXEC

Hi Eric & Lars, On Mon, 5 Sep 2016, Eric Wong wrote: > larsxschnei...@gmail.com wrote: > > All processes that the Git main process spawns inherit the open file > > descriptors of the main process. These leaked file descriptors can > > cause problems. > > > > -int git_open_noatime(const char

Re: [PATCH v1 1/2] sha1_file: open window into packfiles with CLOEXEC

W dniu 06.09.2016 o 00:27, Eric Wong pisze: > larsxschnei...@gmail.com wrote: >> -int git_open_noatime(const char *name) >> +int git_open_noatime_cloexec(const char *name) [...] > > I question the need for the "_cloexec" suffixing in the > function name since the old function is going away

re

Did you get my message?

Re: Context Menu is missing

??? On Tue, Sep 6, 2016 at 11:20 AM, wrote: > (and s/he did it againhitting "reply all" seems really complicated) > > Am 06.09.2016 um 10:07 schrieb Idan Shimoni: >> it is part of git cheetah plugin not tortoise. >> But it was part of the git installer for

Re: Context Menu is missing

(and s/he did it againhitting "reply all" seems really complicated) Am 06.09.2016 um 10:07 schrieb Idan Shimoni: > it is part of git cheetah plugin not tortoise. > But it was part of the git installer for windows, I did not installed > anything else before. > > On Tue, Sep 6, 2016 at 10:54

[PATCH] Unbreak interactive GPG prompt upon signing

With the recent update in efee955 (gpg-interface: check gpg signature creation status, 2016-06-17), we ask GPG to send all status updates to stderr, and then catch the stderr in an strbuf. But GPG might fail, and send error messages to stderr. And we simply do not show them to the user. Even

Re: Context Menu is missing

(Please, please, please, use "reply all" in your mail reader i.e. make sure you don't remove 'git@vger.kernel.org' from the "To:" or "CC:" field. Thank you!) Am 06.09.2016 um 09:47 schrieb Idan Shimoni: > On Tue, Sep 6, 2016 at 10:33 AM, wrote: >> (Please

Re: Context Menu is missing

(Please don't top post and do "reply all") Am 06.09.2016 um 09:28 schrieb Idan Shimoni: > > On Tue, Sep 6, 2016 at 10:23 AM, wrote: >> Am 06.09.2016 um 09:12 schrieb Idan Shimoni: >>> Hi, >>> >>> The last install removed the old good context menu I used to

Re: [PATCH] t6026-merge-attr: wait for process to release trash directory

On Mon, Sep 05, 2016 at 09:03:48PM +0200, Johannes Sixt wrote: > The process spawned in the hook uses the test's trash directory as CWD. > As long as it is alive, the directory cannot be removed on Windows. > Although the test succeeds, the 'test_done' that follows produces an > error message and

Re: [PATCH] t6026-merge-attr: wait for process to release trash directory

Hi Hannes, On Mon, 5 Sep 2016, Johannes Sixt wrote: > The process spawned in the hook uses the test's trash directory as CWD. > As long as it is alive, the directory cannot be removed on Windows. > Although the test succeeds, the 'test_done' that follows produces an > error message and leaves

Re: Context Menu is missing

Am 06.09.2016 um 09:12 schrieb Idan Shimoni: > Hi, > > The last install removed the old good context menu I used to work with. > > Is that on purpose or is it a bug? is there any way to get it back? > You're working on a Cray system using git 1.3.2, right ? SCNR --

Re: [PATCH] t9903: fix broken && chain

On Mon, Sep 05, 2016 at 09:00:47PM +0200, Johannes Sixt wrote: > We might wonder why our && chain check does not catch this case: > The && chain check uses a strange exit code with the expectation that > the second or later part of a broken && chain would not exit with this > particular code. >

Re: [PATCH 0/3] Fix a segfault caused by regexec() being called on mmap()ed data

On Mon, Sep 05, 2016 at 12:10:11PM -0700, Junio C Hamano wrote: > * We could use variant of regexp engine as you proposed, >which I think is a preferrable solution. Do people know of a >widely accepted implementation that we can throw into compat/ as >fallback that is

Re: 2.10.0: multiple versionsort.prereleasesuffix buggy?

On 06.09.2016 04:07, SZEDER Gábor wrote: [versionsort] prereleasesuffix = beta prereleasesuffix = -beta prereleasesuffix = RC prereleasesuffix = -RC Best, Gábor Yes, yes you are the best. Workaround works, tyvm. I was heading in that direction, too, but never

Context Menu is missing

Hi, The last install removed the old good context menu I used to work with. Is that on purpose or is it a bug? is there any way to get it back? -- -Best Idan

Re: [PATCH 3/3] diff_grep: add assertions verifying that the buffers are NUL-terminated

On Mon, Sep 05, 2016 at 05:45:09PM +0200, Johannes Schindelin wrote: > Before calling regexec() on the file contents, we better be certain that > the strings fulfill the contract of C strings assumed by said function. If you have a buffer that is exactly "size" bytes and you are worried about

Re: [PATCH 2/3] diff_populate_filespec: NUL-terminate buffers

On Mon, Sep 05, 2016 at 05:45:06PM +0200, Johannes Schindelin wrote: > It is true that many code paths populate the mmfile_t structure silently > appending a NUL, e.g. when running textconv on a temporary file and > reading the results back into an strbuf. > > The assumption is most definitely

[PATCHv4] diff.c: emit moved lines with a different color

When we color the diff, we'll mark moved lines with a different color. This is achieved by doing a two passes over the diff. The first pass will inspect each line of the diff and store the removed lines and the added lines in its own hash map. The second pass will check for each added line if

Re: [PATCHv3] diff.c: emit moved lines with a different color

On Mon, Sep 5, 2016 at 7:20 PM, Stefan Beller wrote: >> If I understand, this is to ensure that we don't keep re-hashing each >> line right? > > No, this is to ensure we have the context sensitivity of one prior line. > > In the collection phase we look at each line of the

Re: [PATCH 0/3] Fix a segfault caused by regexec() being called on mmap()ed data

On Mon, Sep 05, 2016 at 05:44:57PM +0200, Johannes Schindelin wrote: > The problem with that: mmap()ed memory is *not* NUL-terminated, yet the > pickaxe code calls regexec() on it just the same. > > This problem has been reported by my colleague Chris Sidi. > > Please note that this patch