v2.9.3 and v2.10.0: `name-ref' HEAD gives wrong branch name

[Steffen Nurpmeso]

Hello again,

yah, sorry, i'm back again..
I try to find a way to find the name of the current branch in an
automated way, because i need to ensure that a commit happens on
it and no other branch.  Now the problem arises that the commit
ref at the time of that commit maybe shared in between several
different branches, but no more thereafter, of course:

  ?0[steffen@wales ]$ git branch|grep '^*'
  * stable/v14.9
  ?0[steffen@wales ]$ git name-rev --name-only HEAD
  stable/v14.8

Is there another way except looking into .git/HEAD or using sed(1)
on the output of `branch' to find the right name?
Thank you.
Ciao!

--steffen

[PATCH v3 3/3] mailinfo: handle in-body header continuations

[Jonathan Tan]

Mailinfo currently handles multi-line headers, but it does not handle
multi-line in-body headers. Teach it to handle such headers, for
example, for this input:

  From: author 
  Date: Fri, 9 Jun 2006 00:44:16 -0700
  Subject: a very long
   broken line

  Subject: another very long
   broken line

interpret the in-body subject to be "another very long broken line"
instead of "another very long".

An existing test (t/t5100/msg0015) has an indented line immediately
after an in-body header - it has been modified to reflect the new
functionality.

Signed-off-by: Jonathan Tan 
---
 mailinfo.c   | 50 +++-
 mailinfo.h   |  1 +
 t/t4150-am.sh| 23 +
 t/t5100-mailinfo.sh  |  2 +-
 t/t5100/info0018 |  5 
 t/t5100/info0018--no-inbody-headers  |  5 
 t/t5100/msg0015  |  2 --
 t/t5100/msg0018  |  2 ++
 t/t5100/msg0018--no-inbody-headers   |  8 ++
 t/t5100/patch0018|  6 +
 t/t5100/patch0018--no-inbody-headers |  6 +
 t/t5100/sample.mbox  | 19 ++
 12 files changed, 125 insertions(+), 4 deletions(-)
 create mode 100644 t/t5100/info0018
 create mode 100644 t/t5100/info0018--no-inbody-headers
 create mode 100644 t/t5100/msg0018
 create mode 100644 t/t5100/msg0018--no-inbody-headers
 create mode 100644 t/t5100/patch0018
 create mode 100644 t/t5100/patch0018--no-inbody-headers

diff --git a/mailinfo.c b/mailinfo.c
index 69391aa..2275b28 100644
--- a/mailinfo.c
+++ b/mailinfo.c
@@ -500,6 +500,21 @@ static int check_header(struct mailinfo *mi,
return ret;
 }
 
+/*
+ * Returns 1 if the given line or any line beginning with the given line is an
+ * in-body header (that is, check_header will succeed when passed
+ * mi->s_hdr_data).
+ */
+static int is_inbody_header(const struct mailinfo *mi,
+   const struct strbuf *line)
+{
+   int i;
+   for (i = 0; header[i]; i++)
+   if (!mi->s_hdr_data[i] && cmp_header(line, header[i]))
+   return 1;
+   return 0;
+}
+
 static void decode_transfer_encoding(struct mailinfo *mi, struct strbuf *line)
 {
struct strbuf *ret;
@@ -609,8 +624,33 @@ static int is_scissors_line(const char *line)
gap * 2 < perforation);
 }
 
+static void flush_inbody_header_accum(struct mailinfo *mi)
+{
+   if (!mi->inbody_header_accum.len)
+   return;
+   assert(check_header(mi, >inbody_header_accum, mi->s_hdr_data, 0));
+   strbuf_reset(>inbody_header_accum);
+}
+
 static int check_inbody_header(struct mailinfo *mi, const struct strbuf *line)
 {
+   if (mi->inbody_header_accum.len &&
+   (line->buf[0] == ' ' || line->buf[0] == '\t')) {
+   if (mi->use_scissors && is_scissors_line(line->buf)) {
+   /*
+* This is a scissors line; do not consider this line
+* as a header continuation line.
+*/
+   flush_inbody_header_accum(mi);
+   return 0;
+   }
+   strbuf_strip_suffix(>inbody_header_accum, "\n");
+   strbuf_addbuf(>inbody_header_accum, line);
+   return 1;
+   }
+
+   flush_inbody_header_accum(mi);
+
if (starts_with(line->buf, ">From") && isspace(line->buf[5]))
return is_format_patch_separator(line->buf + 1, line->len - 1);
if (starts_with(line->buf, "[PATCH]") && isspace(line->buf[7])) {
@@ -622,7 +662,11 @@ static int check_inbody_header(struct mailinfo *mi, const 
struct strbuf *line)
}
return 0;
}
-   return check_header(mi, line, mi->s_hdr_data, 0);
+   if (is_inbody_header(mi, line)) {
+   strbuf_addbuf(>inbody_header_accum, line);
+   return 1;
+   }
+   return 0;
 }
 
 static int handle_commit_msg(struct mailinfo *mi, struct strbuf *line)
@@ -888,6 +932,8 @@ static void handle_body(struct mailinfo *mi, struct strbuf 
*line)
break;
} while (!strbuf_getwholeline(line, mi->input, '\n'));
 
+   flush_inbody_header_accum(mi);
+
 handle_body_out:
strbuf_release();
 }
@@ -1003,6 +1049,7 @@ void setup_mailinfo(struct mailinfo *mi)
strbuf_init(>email, 0);
strbuf_init(>charset, 0);
strbuf_init(>log_message, 0);
+   strbuf_init(>inbody_header_accum, 0);
mi->header_stage = 1;
mi->use_inbody_headers = 1;
mi->content_top = mi->content;
@@ -1016,6 +1063,7 @@ void clear_mailinfo(struct mailinfo *mi)
strbuf_release(>name);
strbuf_release(>email);
strbuf_release(>charset);
+   strbuf_release(>inbody_header_accum);
free(mi->message_id);
 

[PATCH v3 1/3] mailinfo: separate in-body header processing

[Jonathan Tan]

The check_header function contains logic specific to in-body headers,
although it is invoked during both the processing of actual headers and
in-body headers. Separate out the in-body header part into its own
function.

Signed-off-by: Jonathan Tan 
---
 mailinfo.c | 33 +
 1 file changed, 17 insertions(+), 16 deletions(-)

diff --git a/mailinfo.c b/mailinfo.c
index e19abe3..0c4738a 100644
--- a/mailinfo.c
+++ b/mailinfo.c
@@ -495,21 +495,6 @@ static int check_header(struct mailinfo *mi,
goto check_header_out;
}
 
-   /* for inbody stuff */
-   if (starts_with(line->buf, ">From") && isspace(line->buf[5])) {
-   ret = is_format_patch_separator(line->buf + 1, line->len - 1);
-   goto check_header_out;
-   }
-   if (starts_with(line->buf, "[PATCH]") && isspace(line->buf[7])) {
-   for (i = 0; header[i]; i++) {
-   if (!strcmp("Subject", header[i])) {
-   handle_header(_data[i], line);
-   ret = 1;
-   goto check_header_out;
-   }
-   }
-   }
-
 check_header_out:
strbuf_release();
return ret;
@@ -623,6 +608,22 @@ static int is_scissors_line(const struct strbuf *line)
gap * 2 < perforation);
 }
 
+static int check_inbody_header(struct mailinfo *mi, const struct strbuf *line)
+{
+   if (starts_with(line->buf, ">From") && isspace(line->buf[5]))
+   return is_format_patch_separator(line->buf + 1, line->len - 1);
+   if (starts_with(line->buf, "[PATCH]") && isspace(line->buf[7])) {
+   int i;
+   for (i = 0; header[i]; i++)
+   if (!strcmp("Subject", header[i])) {
+   handle_header(>s_hdr_data[i], line);
+   return 1;
+   }
+   return 0;
+   }
+   return check_header(mi, line, mi->s_hdr_data, 0);
+}
+
 static int handle_commit_msg(struct mailinfo *mi, struct strbuf *line)
 {
assert(!mi->filter_stage);
@@ -633,7 +634,7 @@ static int handle_commit_msg(struct mailinfo *mi, struct 
strbuf *line)
}
 
if (mi->use_inbody_headers && mi->header_stage) {
-   mi->header_stage = check_header(mi, line, mi->s_hdr_data, 0);
+   mi->header_stage = check_inbody_header(mi, line);
if (mi->header_stage)
return 0;
} else
-- 
2.10.0.rc2.20.g5b18e70

[PATCH v3 2/3] mailinfo: make is_scissors_line take plain char *

[Jonathan Tan]

The is_scissors_line takes a struct strbuf * when a char * would
suffice. Make it take char *.

Signed-off-by: Jonathan Tan 
---
 mailinfo.c | 35 ++-
 1 file changed, 18 insertions(+), 17 deletions(-)

diff --git a/mailinfo.c b/mailinfo.c
index 0c4738a..69391aa 100644
--- a/mailinfo.c
+++ b/mailinfo.c
@@ -557,37 +557,35 @@ static inline int patchbreak(const struct strbuf *line)
return 0;
 }
 
-static int is_scissors_line(const struct strbuf *line)
+static int is_scissors_line(const char *line)
 {
-   size_t i, len = line->len;
+   const char *c;
int scissors = 0, gap = 0;
-   int first_nonblank = -1;
-   int last_nonblank = 0, visible, perforation = 0, in_perforation = 0;
-   const char *buf = line->buf;
+   const char *first_nonblank = NULL, *last_nonblank = NULL;
+   int visible, perforation = 0, in_perforation = 0;
 
-   for (i = 0; i < len; i++) {
-   if (isspace(buf[i])) {
+   for (c = line; *c; c++) {
+   if (isspace(*c)) {
if (in_perforation) {
perforation++;
gap++;
}
continue;
}
-   last_nonblank = i;
-   if (first_nonblank < 0)
-   first_nonblank = i;
-   if (buf[i] == '-') {
+   last_nonblank = c;
+   if (first_nonblank == NULL)
+   first_nonblank = c;
+   if (*c == '-') {
in_perforation = 1;
perforation++;
continue;
}
-   if (i + 1 < len &&
-   (!memcmp(buf + i, ">8", 2) || !memcmp(buf + i, "8<", 2) ||
-!memcmp(buf + i, ">%", 2) || !memcmp(buf + i, "%<", 2))) {
+   if ((!memcmp(c, ">8", 2) || !memcmp(c, "8<", 2) ||
+!memcmp(c, ">%", 2) || !memcmp(c, "%<", 2))) {
in_perforation = 1;
perforation += 2;
scissors += 2;
-   i++;
+   c++;
continue;
}
in_perforation = 0;
@@ -602,7 +600,10 @@ static int is_scissors_line(const struct strbuf *line)
 * than half of the perforation.
 */
 
-   visible = last_nonblank - first_nonblank + 1;
+   if (first_nonblank && last_nonblank)
+   visible = last_nonblank - first_nonblank + 1;
+   else
+   visible = 0;
return (scissors && 8 <= visible &&
visible < perforation * 3 &&
gap * 2 < perforation);
@@ -647,7 +648,7 @@ static int handle_commit_msg(struct mailinfo *mi, struct 
strbuf *line)
if (convert_to_utf8(mi, line, mi->charset.buf))
return 0; /* mi->input_error already set */
 
-   if (mi->use_scissors && is_scissors_line(line)) {
+   if (mi->use_scissors && is_scissors_line(line->buf)) {
int i;
 
strbuf_setlen(>log_message, 0);
-- 
2.10.0.rc2.20.g5b18e70

[PATCH v3 0/3] handle multiline in-body headers

[Jonathan Tan]

Changes since v2:
o Removed utf8 translation before scissors line check in
  check_inbody_header (I was thinking of support for encodings like
  UTF-16, but I guess those don't work with the current reencode_string
  anyway since it uses strlen internally)

With the above change, it is actually no longer necessary to make
is_scissors_line take plain char * (the second patch) - I think that
that patch still improves the code, but let me know if you want me to
remove it from this patch set.

Jonathan Tan (3):
  mailinfo: separate in-body header processing
  mailinfo: make is_scissors_line take plain char *
  mailinfo: handle in-body header continuations

 mailinfo.c   | 116 +--
 mailinfo.h   |   1 +
 t/t4150-am.sh|  23 +++
 t/t5100-mailinfo.sh  |   2 +-
 t/t5100/info0018 |   5 ++
 t/t5100/info0018--no-inbody-headers  |   5 ++
 t/t5100/msg0015  |   2 -
 t/t5100/msg0018  |   2 +
 t/t5100/msg0018--no-inbody-headers   |   8 +++
 t/t5100/patch0018|   6 ++
 t/t5100/patch0018--no-inbody-headers |   6 ++
 t/t5100/sample.mbox  |  19 ++
 12 files changed, 159 insertions(+), 36 deletions(-)
 create mode 100644 t/t5100/info0018
 create mode 100644 t/t5100/info0018--no-inbody-headers
 create mode 100644 t/t5100/msg0018
 create mode 100644 t/t5100/msg0018--no-inbody-headers
 create mode 100644 t/t5100/patch0018
 create mode 100644 t/t5100/patch0018--no-inbody-headers

-- 
2.10.0.rc2.20.g5b18e70

2.10.0: git log --oneline prints gpg signatures in 4 lines

[Leandro Lucarella]

Hi, starting from 2.10.0 I noticed that when using git log --oneline,
if commits are signed with GPG, now the signatures are printed too, and
it takes 3 lines for the signature information + 1 line for the title
of the commit, so suddenly --oneline became --fourline :)

Is this really intended?

-- 
Leandro Lucarella
Technical Development Lead
Sociomantic Labs GmbH 

Re: [PATCH v2] ls-files: add pathspec matching for submodules

[Brandon Williams]

On Mon, Sep 19, 2016 at 4:21 PM, Junio C Hamano  wrote:
>
> As the previous one that used a wrong (sorry) argument is not even
> in 'next' yet, let's pretend that it never happened.  It is OK to
> still keep it and this patch as two separate steps, i.e. a topic
> with two patches in it.
>
> That means that this patch will become 2/2 of a series, and 1/2 is
> rerolled to use submodule_prefix from the get-go, without ever
> introducing output_path_prefix variable, so that many of the above
> lines we won't have to review in 2/2.

Ah ok.  Would you like me to resend the first patch with the desired
change then?

>
>> + /*
>> +  * Pass in the original pathspec args.  The submodule will be
>> +  * responsible for prepending the 'submodule_prefix' prior to comparing
>> +  * against the pathspec for matches.
>> +  */
>
> Good.
>
>> + argv_array_push(, "--");
>> + for (i = 0; i < pathspec.nr; ++i)
>> + argv_array_push(, pathspec.items[i].original);
>> +
>
> Please prefer post-increment i++ over pre-increment ++i when writing
> a for(;;) loop, unless there is a strong reason not to (familiarlity
> in C++ is not a good reason).

I had a compiler instructor drill into my head that ++i in a for loop
was faster historically
since it wouldn't have to create a temporary value.  Of course now a days there
probably isn't much (or any) difference between the two.  If post-fix
operators are the
norm in git code then I can try to remember to use them :)

>> +
>> + if (item->flags & PATHSPEC_ONESTAR) {
>> + return WM_MATCH;
>> + } else if (item->magic & PATHSPEC_GLOB) {
>> + return wildmatch(pattern, string,
>> +  WM_PATHNAME |
>> +  (item->magic & PATHSPEC_ICASE ?
>> +   WM_CASEFOLD : 0),
>> +  NULL);
>
> Isn't this last one overly tight?  I am wondering about a scenario
> where you have a submodule at "sub/" in the superproject, and "sub/"
> has a "file" at the top of its working tree.  And you do:
>
> git ls-files --recurse-submodules ':(glob)??b/fi?e'
>
> at the top of the superproject.  The "pattern" would be '??b/fi?e"
> while string would be 'sub', and wildmatch() would not like it, but
> there is no way for this caller to append anything to 'sub' before
> making this call, as it hasn't looked into what paths appear in the
> submodule repository (and it should not want to).  And I think we
> would want it to recurse to find sub/file.  IOW, this looks like a
> false negative we must avoid in this function.  As we cannot afford
> to check if anything that matches 'fi?e' is in the index file of the
> submodule repository, we shouldn't try to match 'fi?e' portion of
> the given pathspec pattern.

good point.  Let me think about this some more.

[PATCH tg/add-chmod+x-fix 2/2] t3700-add: protect one --chmod=+x test with POSIXPERM

[Johannes Sixt]

A recently introduced test checks the result of 'git status' after
setting the executable bit on a file. This check does not yield the
expected result when the filesystem does not support the executable bit
(and core.filemode is false). Skip the test case.

Signed-off-by: Johannes Sixt 
---
 I am surprised that add --chmod=+x changes only the index, but not
 the file on disk!?!

 t/t3700-add.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/t/t3700-add.sh b/t/t3700-add.sh
index 16ab2da..13e0dd2 100755
--- a/t/t3700-add.sh
+++ b/t/t3700-add.sh
@@ -361,7 +361,7 @@ test_expect_success 'git add --chmod=[+-]x changes index 
with already added file
test_mode_in_index 100644 xfoo3
 '
 
-test_expect_success 'file status is changed after git add --chmod=+x' '
+test_expect_success POSIXPERM 'file status is changed after git add 
--chmod=+x' '
echo "AM foo4" >expected &&
echo foo >foo4 &&
git add foo4 &&
-- 
2.10.0.85.gea34e30

[PATCH tg/add-chmod+x-fix 1/2] t3700-add: create subdirectory gently

[Johannes Sixt]

The subdirectory 'sub' is created early in the test file. Later, a test
case removes it during its clean-up actions. However, this test case is
protected by POSIXPERM. Consequently, 'sub' remains when the POSIXPERM
prerequisite is not satisfied. Later, a recently introduced test case
creates 'sub' again. Use -p with mkdir so that it does not fail if 'sub'
already exists.

Signed-off-by: Johannes Sixt 
---
 t/t3700-add.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/t/t3700-add.sh b/t/t3700-add.sh
index 0a962a6..16ab2da 100755
--- a/t/t3700-add.sh
+++ b/t/t3700-add.sh
@@ -380,7 +380,7 @@ test_expect_success 'no file status change if no pathspec 
is given' '
 '
 
 test_expect_success 'no file status change if no pathspec is given in subdir' '
-   mkdir sub &&
+   mkdir -p sub &&
(
cd sub &&
>sub-foo1 &&
-- 
2.10.0.85.gea34e30

Re: [PATCH v2] format-patch: Add --rfc for the common case of [RFC PATCH]

[Jacob Keller]

On Mon, Sep 19, 2016 at 6:37 PM, Jeff King  wrote:
> On Mon, Sep 19, 2016 at 04:40:22PM -0700, Josh Triplett wrote:
>
>> >   - there are a non-trivial number of patches for other projects (JGIT,
>> > EGIT, StGit, etc). This is somewhat unique to git, where we discuss
>> > a lot of related projects on the list. But I wonder if other
>> > projects would use subsystems in a similar way (though I guess for
>> > the kernel, there are separate subsystems lists, so the "to" or "cc"
>> > header becomes the more interesting tag).
>>
>> The kernel mostly uses "[PATCH] subsystem: ...".  Occasionally I see
>> "[PATCH somegitrepo ...] ..." when it's necessary to explicitly say
>> whose git repo the patch needs to go through, but that's pretty rare.
>
> We do both. "foo: blah" is for subsystem "foo" of Git itself, but
> all-caps "JGIT PATCH" is "this is not even for Git". I don't know that
> the kernel really has an equivalent.
>
> -Peff

[net] and [net-next] are for the *tree* not the subsystem of the tree.

net: also means the networking subsystem, but it's different you might
have a new feature and say

[net-next PATCH v2] net: my awesome new feature.

Thanks,
Jake

[PATCH] git-check-ref-format.txt: fixup documentation

[Elia Pinto]

die is not a standard shell function. Use
a different shell code for the example.

Signed-off-by: Elia Pinto 
---
 Documentation/git-check-ref-format.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/git-check-ref-format.txt 
b/Documentation/git-check-ref-format.txt
index 91a3622..8611a99 100644
--- a/Documentation/git-check-ref-format.txt
+++ b/Documentation/git-check-ref-format.txt
@@ -118,8 +118,8 @@ $ git check-ref-format --branch @{-1}
 * Determine the reference name to use for a new branch:
 +
 
-$ ref=$(git check-ref-format --normalize "refs/heads/$newbranch") ||
-die "we do not like '$newbranch' as a branch name."
+$ ref=$(git check-ref-format --normalize "refs/heads/$newbranch")||
+{ echo "we do not like '$newbranch' as a branch name." >&2 ; exit 1 ; }
 
 
 GIT
-- 
2.10.0.645.gc4ba6eb

Limitiations of git rebase --preserve-merges --interactive

[Stefan Haller]

The BUGS section of the git-rebase manpage says that editing or
rewording commits "should work fine", but attempts to reorder commits
usually don't do what you want.

I'd like to know more about what does or doesn't work. For example, will
squashing commits work? (I.e. using the "fixup" or "squash" commands in
the todo sheet.)

Will dropping commits work?

Does it make sense to insert "exec" commands, or will they run at
arbitrary times?


-- 
Stefan Haller
Berlin, Germany
http://www.haller-berlin.de/

Re: [PATCH v3 0/8] Better heuristics make prettier diffs

[Michael Haggerty]

On 09/19/2016 07:27 PM, Junio C Hamano wrote:
> Junio C Hamano  writes:
> 
>> Michael Haggerty  writes:
>>
>>> On 09/08/2016 01:25 AM, Junio C Hamano wrote:
 I'd move it temporarily to t4061 with a separate SQUASH??? at the
 tip for now, as I am running out of time today.
>>>
>>> I didn't realize you were waiting for an ACK. Yes, it's totally OK to
>>> rename the test.
>>
>> I actually wasn't asking for an Ack.
>>
>> As the issue was in the one that is buried a few commits from the
>> tip, and there is a later one that adds more tests to it, I didn't
>> find enough energy to rename the new file in a buried commit and
>> then adjust the patch later updates it, I was hoping that you'd
>> reroll to save me effort, rather than forcing me to do the rebase
>> myself ;-).
> 
> Now I did, so no need to resend (unless you have changes other than
> the renaming of the test script, that is).

Thanks for taking care of this.

> Let's move it down to 'next' soonish.

Yes, it would be good to get feedback early enough in the cycle that we
can make a final decision about which diff heuristics should be used by
default and whether/what UI to implement for switching between them.

Michael

Re: Homebrew and Git

[Heiko Voigt]

Hi,

On Sun, Sep 18, 2016 at 05:50:28PM +0200, Jonas Thiel wrote:
> A while ago I have described my problem with Homebrew at the following
> GitHub channel
> (https://github.com/Homebrew/homebrew-core/issues/2970). In the
> meanwhile, I believe that I my problem with Homebrew is based on an
> issues with my Git. I have found the attached Git Crash reports on my
> Mac and because I am not familiar with reading/analysing Crash
> Reports, it would be great if someone could give me some feedback on
> it.
>  
> If you have any question, please do not hesitate to contact me.

>From your crash reports I see that git is apparently crashing in a
strchr() call from within ident_default_email() which is a function that
tries to assemble a name and email to put into your commits.

Can you post us the output of

hostname -f

and

whoami

?

Since it seems you are using an Apple git can you also give us the
output of

git version

Since it seems that Apple is compiling its own git (and not publishing
the changes they made conveniently via git). Have you tried
installing a vanilla git via homebrew and seeing whether that also
produces the issue?

In your bugreport you are talking about modifications you do to your
system after which the issue occurred. I would suggest to exactly find
out which step lead to git crashing (if it actually is the issue). First
to identify an issue we need something that is reproduceable.

Cheers Heiko

Re: Re: Homebrew and Git

[Heiko Voigt]

On Tue, Sep 20, 2016 at 01:02:28PM +0200, Heiko Voigt wrote:
> Hi,
> 
> On Sun, Sep 18, 2016 at 05:50:28PM +0200, Jonas Thiel wrote:
> > A while ago I have described my problem with Homebrew at the following
> > GitHub channel
> > (https://github.com/Homebrew/homebrew-core/issues/2970). In the
> > meanwhile, I believe that I my problem with Homebrew is based on an
> > issues with my Git. I have found the attached Git Crash reports on my
> > Mac and because I am not familiar with reading/analysing Crash
> > Reports, it would be great if someone could give me some feedback on
> > it.
> >  
> > If you have any question, please do not hesitate to contact me.
> 
> From your crash reports I see that git is apparently crashing in a
> strchr() call from within ident_default_email() which is a function that
> tries to assemble a name and email to put into your commits.

BTW, here is the callstack inlined from the crashreport:

bsystem_platform.dylib  0x7fff840db41c 
_platform_strchr$VARIANT$Haswell + 28
1   git 0x00010ba1d3f4 ident_default_email 
+ 801
2   git 0x00010ba1d68f fmt_ident + 66
3   git 0x00010ba4b495 files_log_ref_write 
+ 175
4   git 0x00010ba4b0a6 commit_ref_update + 
106
5   git 0x00010ba4c3a8 
ref_transaction_commit + 468
6   git 0x00010b994dd8 s_update_ref + 271
7   git 0x00010b994556 fetch_refs + 1969
8   git 0x00010b9935f2 fetch_one + 1913
9   git 0x00010b992bc4 cmd_fetch + 549
10  git 0x00010b9666c4 handle_builtin + 478
11  git 0x00010b96602f main + 376
12  libdyld.dylib   0x7fff834ef5ad start + 1

Maybe someone else has an idea what might be causing this...

Cheers Heiko

Aw: Re: Homebrew and Git

[Jonas Thiel]

Hi Heiko,

thanks for your reply on my issue. 

Here are the following outputs you asked for:

git version
git version 2.7.4 (Apple Git-66)

hostname -f
0x6A6E73

whoami
jns

I have tried the Homebrew version of git, but no change in case of the issue.

I just customized my system with the Mathias Bynens dotfiles 
(https://github.com/mathiasbynens/dotfiles) as well as with drduhs OS X 
Security Guide (https://github.com/drduh/OS-X-Security-and-Privacy-Guide). 
Because I reinstall my Mac on a regularly basis, wherefore I can say that one 
year ago these tweaks have not caused any issue.

Thanks a lot. I really appreciate your help.

Cheers,
Jonas

> Gesendet: Dienstag, 20. September 2016 um 13:02 Uhr
> Von: "Heiko Voigt" 
> An: "Jonas Thiel" 
> Cc: git@vger.kernel.org
> Betreff: Re: Homebrew and Git
>
> Hi,
> 
> On Sun, Sep 18, 2016 at 05:50:28PM +0200, Jonas Thiel wrote:
> > A while ago I have described my problem with Homebrew at the following
> > GitHub channel
> > (https://github.com/Homebrew/homebrew-core/issues/2970). In the
> > meanwhile, I believe that I my problem with Homebrew is based on an
> > issues with my Git. I have found the attached Git Crash reports on my
> > Mac and because I am not familiar with reading/analysing Crash
> > Reports, it would be great if someone could give me some feedback on
> > it.
> >  
> > If you have any question, please do not hesitate to contact me.
> 
> From your crash reports I see that git is apparently crashing in a
> strchr() call from within ident_default_email() which is a function that
> tries to assemble a name and email to put into your commits.
> 
> Can you post us the output of
> 
>   hostname -f
> 
> and
> 
>   whoami
> 
> ?
> 
> Since it seems you are using an Apple git can you also give us the
> output of
> 
>   git version
> 
> Since it seems that Apple is compiling its own git (and not publishing
> the changes they made conveniently via git). Have you tried
> installing a vanilla git via homebrew and seeing whether that also
> produces the issue?
> 
> In your bugreport you are talking about modifications you do to your
> system after which the issue occurred. I would suggest to exactly find
> out which step lead to git crashing (if it actually is the issue). First
> to identify an issue we need something that is reproduceable.
> 
> Cheers Heiko
> 

Re: [PATCH v3 0/3] handle multiline in-body headers

[Jeff King]

On Tue, Sep 20, 2016 at 10:17:50AM -0700, Jonathan Tan wrote:

> Changes since v2:
> o Removed utf8 translation before scissors line check in
>   check_inbody_header (I was thinking of support for encodings like
>   UTF-16, but I guess those don't work with the current reencode_string
>   anyway since it uses strlen internally)

Yeah, I'd be surprised if UTF-16 works very well with our code in
general. If we want to address that, though, the sanest thing is
probably to convert it internally to UTF-8 when we remove the transfer
encoding in handle_body().

-Peff

Re: What's cooking in git.git (Sep 2016, #05; Mon, 19)

[Johannes Schindelin]

Hi,

On Mon, 19 Sep 2016, Junio C Hamano wrote:

> * jk/rebase-i-drop-ident-check (2016-07-29) 1 commit
>   (merged to 'next' on 2016-08-14 at 6891bcd)
>  + rebase-interactive: drop early check for valid ident
> 
>  Even when "git pull --rebase=preserve" (and the underlying "git
>  rebase --preserve") can complete without creating any new commit
>  (i.e. fast-forwards), it still insisted on having a usable ident
>  information (read: user.email is set correctly), which was less
>  than nice.  As the underlying commands used inside "git rebase"
>  would fail with a more meaningful error message and advice text
>  when the bogus ident matters, this extra check was removed.
> 
>  Will hold to see if people scream.
>  cf. <20160729224944.ga23...@sigill.intra.peff.net>

Let's do this.

Ciao,
Dscho

Re: [PATCH v2] ls-files: add pathspec matching for submodules

[Brandon Williams]

>>> +
>>> + if (item->flags & PATHSPEC_ONESTAR) {
>>> + return WM_MATCH;
>>> + } else if (item->magic & PATHSPEC_GLOB) {
>>> + return wildmatch(pattern, string,
>>> +  WM_PATHNAME |
>>> +  (item->magic & PATHSPEC_ICASE ?
>>> +   WM_CASEFOLD : 0),
>>> +  NULL);
>>
>> Isn't this last one overly tight?  I am wondering about a scenario
>> where you have a submodule at "sub/" in the superproject, and "sub/"
>> has a "file" at the top of its working tree.  And you do:
>>
>> git ls-files --recurse-submodules ':(glob)??b/fi?e'
>>
>> at the top of the superproject.  The "pattern" would be '??b/fi?e"
>> while string would be 'sub', and wildmatch() would not like it, but
>> there is no way for this caller to append anything to 'sub' before
>> making this call, as it hasn't looked into what paths appear in the
>> submodule repository (and it should not want to).  And I think we
>> would want it to recurse to find sub/file.  IOW, this looks like a
>> false negative we must avoid in this function.  As we cannot afford
>> to check if anything that matches 'fi?e' is in the index file of the
>> submodule repository, we shouldn't try to match 'fi?e' portion of
>> the given pathspec pattern.
>
> good point.  Let me think about this some more.

On a similar but slightly different note.  In general do we want the
pathspec '??b' to
match against the sib/ directory and subsequently have ls-files print
all entries inside
of the sib/ directory?  (this is in the non-recursive case)

[PATCH v8 01/11] pkt-line: rename packet_write() to packet_write_fmt()

[larsxschneider]

From: Lars Schneider 

packet_write() should be called packet_write_fmt() as the string
parameter can be formatted.

Suggested-by: Junio C Hamano 
Signed-off-by: Lars Schneider 
---
 builtin/archive.c|  4 ++--
 builtin/receive-pack.c   |  4 ++--
 builtin/remote-ext.c |  4 ++--
 builtin/upload-archive.c |  4 ++--
 connect.c|  2 +-
 daemon.c |  2 +-
 http-backend.c   |  2 +-
 pkt-line.c   |  2 +-
 pkt-line.h   |  2 +-
 shallow.c|  2 +-
 upload-pack.c| 30 +++---
 11 files changed, 29 insertions(+), 29 deletions(-)

diff --git a/builtin/archive.c b/builtin/archive.c
index a1e3b94..49f4914 100644
--- a/builtin/archive.c
+++ b/builtin/archive.c
@@ -47,10 +47,10 @@ static int run_remote_archiver(int argc, const char **argv,
if (name_hint) {
const char *format = archive_format_from_filename(name_hint);
if (format)
-   packet_write(fd[1], "argument --format=%s\n", format);
+   packet_write_fmt(fd[1], "argument --format=%s\n", 
format);
}
for (i = 1; i < argc; i++)
-   packet_write(fd[1], "argument %s\n", argv[i]);
+   packet_write_fmt(fd[1], "argument %s\n", argv[i]);
packet_flush(fd[1]);
 
buf = packet_read_line(fd[0], NULL);
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index 011db00..1ce7682 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -218,7 +218,7 @@ static int receive_pack_config(const char *var, const char 
*value, void *cb)
 static void show_ref(const char *path, const unsigned char *sha1)
 {
if (sent_capabilities) {
-   packet_write(1, "%s %s\n", sha1_to_hex(sha1), path);
+   packet_write_fmt(1, "%s %s\n", sha1_to_hex(sha1), path);
} else {
struct strbuf cap = STRBUF_INIT;
 
@@ -233,7 +233,7 @@ static void show_ref(const char *path, const unsigned char 
*sha1)
if (advertise_push_options)
strbuf_addstr(, " push-options");
strbuf_addf(, " agent=%s", git_user_agent_sanitized());
-   packet_write(1, "%s %s%c%s\n",
+   packet_write_fmt(1, "%s %s%c%s\n",
 sha1_to_hex(sha1), path, 0, cap.buf);
strbuf_release();
sent_capabilities = 1;
diff --git a/builtin/remote-ext.c b/builtin/remote-ext.c
index 88eb8f9..11b48bf 100644
--- a/builtin/remote-ext.c
+++ b/builtin/remote-ext.c
@@ -128,9 +128,9 @@ static void send_git_request(int stdin_fd, const char 
*serv, const char *repo,
const char *vhost)
 {
if (!vhost)
-   packet_write(stdin_fd, "%s %s%c", serv, repo, 0);
+   packet_write_fmt(stdin_fd, "%s %s%c", serv, repo, 0);
else
-   packet_write(stdin_fd, "%s %s%chost=%s%c", serv, repo, 0,
+   packet_write_fmt(stdin_fd, "%s %s%chost=%s%c", serv, repo, 0,
 vhost, 0);
 }
 
diff --git a/builtin/upload-archive.c b/builtin/upload-archive.c
index 2caedf1..dc872f6 100644
--- a/builtin/upload-archive.c
+++ b/builtin/upload-archive.c
@@ -88,11 +88,11 @@ int cmd_upload_archive(int argc, const char **argv, const 
char *prefix)
writer.git_cmd = 1;
if (start_command()) {
int err = errno;
-   packet_write(1, "NACK unable to spawn subprocess\n");
+   packet_write_fmt(1, "NACK unable to spawn subprocess\n");
die("upload-archive: %s", strerror(err));
}
 
-   packet_write(1, "ACK\n");
+   packet_write_fmt(1, "ACK\n");
packet_flush(1);
 
while (1) {
diff --git a/connect.c b/connect.c
index 722dc3f..5330d9c 100644
--- a/connect.c
+++ b/connect.c
@@ -730,7 +730,7 @@ struct child_process *git_connect(int fd[2], const char 
*url,
 * Note: Do not add any other headers here!  Doing so
 * will cause older git-daemon servers to crash.
 */
-   packet_write(fd[1],
+   packet_write_fmt(fd[1],
 "%s %s%chost=%s%c",
 prog, path, 0,
 target_host, 0);
diff --git a/daemon.c b/daemon.c
index 425aad0..afce1b9 100644
--- a/daemon.c
+++ b/daemon.c
@@ -281,7 +281,7 @@ static int daemon_error(const char *dir, const char *msg)
 {
if (!informative_errors)
msg = "access denied or repository not exported";
-   packet_write(1, "ERR %s: %s", msg, dir);
+   packet_write_fmt(1, "ERR %s: %s", msg, dir);
return -1;
 }
 
diff --git a/http-backend.c b/http-backend.c
index adc8c8c..eef0a36 100644
--- a/http-backend.c
+++ b/http-backend.c
@@ -464,7 +464,7 @@ static void get_info_refs(struct strbuf *hdr, char *arg)
  

[PATCH v8 03/11] run-command: move check_pipe() from write_or_die to run_command

[larsxschneider]

From: Lars Schneider 

Move check_pipe() to run_command and make it public. This is necessary
to call the function from pkt-line in a subsequent patch.

Signed-off-by: Lars Schneider 
---
 run-command.c  | 13 +
 run-command.h  |  2 ++
 write_or_die.c | 13 -
 3 files changed, 15 insertions(+), 13 deletions(-)

diff --git a/run-command.c b/run-command.c
index 5a4dbb6..b72f6d1 100644
--- a/run-command.c
+++ b/run-command.c
@@ -6,6 +6,19 @@
 #include "thread-utils.h"
 #include "strbuf.h"
 
+void check_pipe(int err)
+{
+   if (err == EPIPE) {
+   if (in_async())
+   async_exit(141);
+
+   signal(SIGPIPE, SIG_DFL);
+   raise(SIGPIPE);
+   /* Should never happen, but just in case... */
+   exit(141);
+   }
+}
+
 void child_process_init(struct child_process *child)
 {
memset(child, 0, sizeof(*child));
diff --git a/run-command.h b/run-command.h
index 5066649..e7c5f71 100644
--- a/run-command.h
+++ b/run-command.h
@@ -54,6 +54,8 @@ int finish_command(struct child_process *);
 int finish_command_in_signal(struct child_process *);
 int run_command(struct child_process *);
 
+void check_pipe(int err);
+
 /*
  * Returns the path to the hook file, or NULL if the hook is missing
  * or disabled. Note that this points to static storage that will be
diff --git a/write_or_die.c b/write_or_die.c
index 0734432..eab8c8d 100644
--- a/write_or_die.c
+++ b/write_or_die.c
@@ -1,19 +1,6 @@
 #include "cache.h"
 #include "run-command.h"
 
-static void check_pipe(int err)
-{
-   if (err == EPIPE) {
-   if (in_async())
-   async_exit(141);
-
-   signal(SIGPIPE, SIG_DFL);
-   raise(SIGPIPE);
-   /* Should never happen, but just in case... */
-   exit(141);
-   }
-}
-
 /*
  * Some cases use stdio, but want to flush after the write
  * to get error handling (and to get better interactive
-- 
2.10.0

[PATCH v8 06/11] pkt-line: add packet_write_gently()

[larsxschneider]

From: Lars Schneider 

packet_write_fmt_gently() uses format_packet() which lets the caller
only send string data via "%s". That means it cannot be used for
arbitrary data that may contain NULs.

Add packet_write_gently() which writes arbitrary data and does not die
in case of an error. The function is used by other pkt-line functions in
a subsequent patch.

Signed-off-by: Lars Schneider 
---
 pkt-line.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/pkt-line.c b/pkt-line.c
index 19f0271..fc0ac12 100644
--- a/pkt-line.c
+++ b/pkt-line.c
@@ -171,6 +171,22 @@ int packet_write_fmt_gently(int fd, const char *fmt, ...)
return status;
 }
 
+static int packet_write_gently(const int fd_out, const char *buf, size_t size)
+{
+   static char packet_write_buffer[LARGE_PACKET_MAX];
+
+   if (size > sizeof(packet_write_buffer) - 4) {
+   return error("packet write failed - data exceeds max packet 
size");
+   }
+   packet_trace(buf, size, 1);
+   size += 4;
+   set_packet_header(packet_write_buffer, size);
+   memcpy(packet_write_buffer + 4, buf, size - 4);
+   if (write_in_full(fd_out, packet_write_buffer, size) == size)
+   return 0;
+   return error("packet write failed");
+}
+
 void packet_buf_write(struct strbuf *buf, const char *fmt, ...)
 {
va_list args;
-- 
2.10.0

Re: v2.9.3 and v2.10.0: `name-ref' HEAD gives wrong branch name

[Steffen Nurpmeso]

Hey.

Bryan Turner  wrote:
 |On Tue, Sep 20, 2016 at 9:23 AM, Steffen Nurpmeso  \
 |wrote:
 |> yah, sorry, i'm back again..
 |> I try to find a way to find the name of the current branch in an
 |> automated way, because i need to ensure that a commit happens on
 |> it and no other branch.  Now the problem arises that the commit
 |> ref at the time of that commit maybe shared in between several
 |> different branches, but no more thereafter, of course:
 |>
 |>   ?0[steffen@wales ]$ git branch|grep '^*'
 |>   * stable/v14.9
 |>   ?0[steffen@wales ]$ git name-rev --name-only HEAD
 |>   stable/v14.8
 |>
 |> Is there another way except looking into .git/HEAD or using sed(1)
 |> on the output of `branch' to find the right name?
 |
 |Have you tried "git symbolic-ref HEAD"?

Not until now.

 |$ git symbolic-ref HEAD
 |refs/heads/master

Works.

 |If you don't want the fully-qualified ref, you can add --short:
 |
 |$ git symbolic-ref --short HEAD
 |master

Yep, works even better.  Fantastic.  Thank you.  And that command
was already existing when i have learned to use git(1), it is even
in the progit-09.markdown as of 2011-09-22 that i have laying
around.  Five years, and anything forgotten.  That is what you get
from working with blinkers on.  Shame!

Thank you Bryan.

--steffen

Re: [PATCH tg/add-chmod+x-fix 1/2] t3700-add: create subdirectory gently

[Thomas Gummerer]

Hi Johannes,

On 09/20, Johannes Sixt wrote:
> The subdirectory 'sub' is created early in the test file. Later, a test
> case removes it during its clean-up actions. However, this test case is
> protected by POSIXPERM. Consequently, 'sub' remains when the POSIXPERM
> prerequisite is not satisfied. Later, a recently introduced test case
> creates 'sub' again. Use -p with mkdir so that it does not fail if 'sub'
> already exists.

Thanks for catching and fixing this.  Having a look at the tests shows
that this happens through a git reset --hard at the start of the tests
that require POSIXPERM, which makes me wonder whether we should do
such a cleanup somewhere unconditionally, or move the tests that do
require POSIXPERM to the end of the test file to possibly prevent
similar breakages in the future?

> Signed-off-by: Johannes Sixt 
> ---
>  t/t3700-add.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/t/t3700-add.sh b/t/t3700-add.sh
> index 0a962a6..16ab2da 100755
> --- a/t/t3700-add.sh
> +++ b/t/t3700-add.sh
> @@ -380,7 +380,7 @@ test_expect_success 'no file status change if no pathspec 
> is given' '
>  '
>  
>  test_expect_success 'no file status change if no pathspec is given in 
> subdir' '
> - mkdir sub &&
> + mkdir -p sub &&
>   (
>   cd sub &&
>   >sub-foo1 &&
> -- 
> 2.10.0.85.gea34e30
> 

-- 
Thomas

Re: [PATCH tg/add-chmod+x-fix 2/2] t3700-add: protect one --chmod=+x test with POSIXPERM

[Thomas Gummerer]

Hi Johannes,

On 09/20, Johannes Sixt wrote:
> A recently introduced test checks the result of 'git status' after
> setting the executable bit on a file. This check does not yield the
> expected result when the filesystem does not support the executable bit
> (and core.filemode is false). Skip the test case.

Thanks for cleaning up my mess.  The patch looks correct to me.

> Signed-off-by: Johannes Sixt 
> ---
>  I am surprised that add --chmod=+x changes only the index, but not
>  the file on disk!?!

I *think* --chmod is mainly thought of as a convenience for git users
on a filesystem that doesn't have an executable flag.  So it was
introduced this way as the permissions on the file system don't matter
in that case.  A change of that behaviour may make sense for this
though.

>  t/t3700-add.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/t/t3700-add.sh b/t/t3700-add.sh
> index 16ab2da..13e0dd2 100755
> --- a/t/t3700-add.sh
> +++ b/t/t3700-add.sh
> @@ -361,7 +361,7 @@ test_expect_success 'git add --chmod=[+-]x changes index 
> with already added file
>   test_mode_in_index 100644 xfoo3
>  '
>  
> -test_expect_success 'file status is changed after git add --chmod=+x' '
> +test_expect_success POSIXPERM 'file status is changed after git add 
> --chmod=+x' '
>   echo "AM foo4" >expected &&
>   echo foo >foo4 &&
>   git add foo4 &&
> -- 
> 2.10.0.85.gea34e30
> 

-- 
Thomas

Re: v2.9.3 and v2.10.0: `name-ref' HEAD gives wrong branch name

[Bryan Turner]

On Tue, Sep 20, 2016 at 9:23 AM, Steffen Nurpmeso  wrote:
> Hello again,
>
> yah, sorry, i'm back again..
> I try to find a way to find the name of the current branch in an
> automated way, because i need to ensure that a commit happens on
> it and no other branch.  Now the problem arises that the commit
> ref at the time of that commit maybe shared in between several
> different branches, but no more thereafter, of course:
>
>   ?0[steffen@wales ]$ git branch|grep '^*'
>   * stable/v14.9
>   ?0[steffen@wales ]$ git name-rev --name-only HEAD
>   stable/v14.8
>
> Is there another way except looking into .git/HEAD or using sed(1)
> on the output of `branch' to find the right name?

Have you tried "git symbolic-ref HEAD"?

$ git symbolic-ref HEAD
refs/heads/master

If you don't want the fully-qualified ref, you can add --short:

$ git symbolic-ref --short HEAD
master

> Thank you.
> Ciao!
>
> --steffen

[PATCH v8 09/11] convert: modernize tests

[larsxschneider]

From: Lars Schneider 

Use `test_config` to set the config, check that files are empty with
`test_must_be_empty`, compare files with `test_cmp`, and remove spaces
after ">" and "<".

Please note that the "rot13" filter configured in "setup" keeps using
`git config` instead of `test_config` because subsequent tests might
depend on it.

Reviewed-by: Stefan Beller 
Signed-off-by: Lars Schneider 
---
 t/t0021-conversion.sh | 58 +--
 1 file changed, 29 insertions(+), 29 deletions(-)

diff --git a/t/t0021-conversion.sh b/t/t0021-conversion.sh
index e799e59..dc50938 100755
--- a/t/t0021-conversion.sh
+++ b/t/t0021-conversion.sh
@@ -38,8 +38,8 @@ script='s/^\$Id: \([0-9a-f]*\) \$/\1/p'
 
 test_expect_success check '
 
-   cmp test.o test &&
-   cmp test.o test.t &&
+   test_cmp test.o test &&
+   test_cmp test.o test.t &&
 
# ident should be stripped in the repository
git diff --raw --exit-code :test :test.i &&
@@ -47,10 +47,10 @@ test_expect_success check '
embedded=$(sed -ne "$script" test.i) &&
test "z$id" = "z$embedded" &&
 
-   git cat-file blob :test.t > test.r &&
+   git cat-file blob :test.t >test.r &&
 
-   ./rot13.sh < test.o > test.t &&
-   cmp test.r test.t
+   ./rot13.sh test.t &&
+   test_cmp test.r test.t
 '
 
 # If an expanded ident ever gets into the repository, we want to make sure that
@@ -130,7 +130,7 @@ test_expect_success 'filter shell-escaped filenames' '
 
# delete the files and check them out again, using a smudge filter
# that will count the args and echo the command-line back to us
-   git config filter.argc.smudge "sh ./argc.sh %f" &&
+   test_config filter.argc.smudge "sh ./argc.sh %f" &&
rm "$normal" "$special" &&
git checkout -- "$normal" "$special" &&
 
@@ -141,7 +141,7 @@ test_expect_success 'filter shell-escaped filenames' '
test_cmp expect "$special" &&
 
# do the same thing, but with more args in the filter expression
-   git config filter.argc.smudge "sh ./argc.sh %f --my-extra-arg" &&
+   test_config filter.argc.smudge "sh ./argc.sh %f --my-extra-arg" &&
rm "$normal" "$special" &&
git checkout -- "$normal" "$special" &&
 
@@ -154,9 +154,9 @@ test_expect_success 'filter shell-escaped filenames' '
 '
 
 test_expect_success 'required filter should filter data' '
-   git config filter.required.smudge ./rot13.sh &&
-   git config filter.required.clean ./rot13.sh &&
-   git config filter.required.required true &&
+   test_config filter.required.smudge ./rot13.sh &&
+   test_config filter.required.clean ./rot13.sh &&
+   test_config filter.required.required true &&
 
echo "*.r filter=required" >.gitattributes &&
 
@@ -165,17 +165,17 @@ test_expect_success 'required filter should filter data' '
 
rm -f test.r &&
git checkout -- test.r &&
-   cmp test.o test.r &&
+   test_cmp test.o test.r &&
 
./rot13.sh expected &&
git cat-file blob :test.r >actual &&
-   cmp expected actual
+   test_cmp expected actual
 '
 
 test_expect_success 'required filter smudge failure' '
-   git config filter.failsmudge.smudge false &&
-   git config filter.failsmudge.clean cat &&
-   git config filter.failsmudge.required true &&
+   test_config filter.failsmudge.smudge false &&
+   test_config filter.failsmudge.clean cat &&
+   test_config filter.failsmudge.required true &&
 
echo "*.fs filter=failsmudge" >.gitattributes &&
 
@@ -186,9 +186,9 @@ test_expect_success 'required filter smudge failure' '
 '
 
 test_expect_success 'required filter clean failure' '
-   git config filter.failclean.smudge cat &&
-   git config filter.failclean.clean false &&
-   git config filter.failclean.required true &&
+   test_config filter.failclean.smudge cat &&
+   test_config filter.failclean.clean false &&
+   test_config filter.failclean.required true &&
 
echo "*.fc filter=failclean" >.gitattributes &&
 
@@ -197,8 +197,8 @@ test_expect_success 'required filter clean failure' '
 '
 
 test_expect_success 'filtering large input to small output should use little 
memory' '
-   git config filter.devnull.clean "cat >/dev/null" &&
-   git config filter.devnull.required true &&
+   test_config filter.devnull.clean "cat >/dev/null" &&
+   test_config filter.devnull.required true &&
for i in $(test_seq 1 30); do printf "%1048576d" 1; done >30MB &&
echo "30MB filter=devnull" >.gitattributes &&
GIT_MMAP_LIMIT=1m GIT_ALLOC_LIMIT=1m git add 30MB
@@ -207,7 +207,7 @@ test_expect_success 'filtering large input to small output 
should use little mem
 test_expect_success 'filter that does not read is fine' '
test-genrandom foo $((128 * 1024 + 1)) >big &&
echo "big 

[PATCH v8 11/11] convert: add filter..process option

[larsxschneider]

From: Lars Schneider 

Git's clean/smudge mechanism invokes an external filter process for
every single blob that is affected by a filter. If Git filters a lot of
blobs then the startup time of the external filter processes can become
a significant part of the overall Git execution time.

In a preliminary performance test this developer used a clean/smudge
filter written in golang to filter 12,000 files. This process took 364s
with the existing filter mechanism and 5s with the new mechanism. See
details here: https://github.com/github/git-lfs/pull/1382

This patch adds the `filter..process` string option which, if
used, keeps the external filter process running and processes all blobs
with the packet format (pkt-line) based protocol over standard input and
standard output. The full protocol is explained in detail in
`Documentation/gitattributes.txt`.

A few key decisions:

* The long running filter process is referred to as filter protocol
  version 2 because the existing single shot filter invocation is
  considered version 1.
* Git sends a welcome message and expects a response right after the
  external filter process has started. This ensures that Git will not
  hang if a version 1 filter is incorrectly used with the
  filter..process option for version 2 filters. In addition,
  Git can detect this kind of error and warn the user.
* The status of a filter operation (e.g. "success" or "error) is set
  before the actual response and (if necessary!) re-set after the
  response. The advantage of this two step status response is that if
  the filter detects an error early, then the filter can communicate
  this and Git does not even need to create structures to read the
  response.
* All status responses are pkt-line lists terminated with a flush
  packet. This allows us to send other status fields with the same
  protocol in the future.

Helped-by: Martin-Louis Bright 
Reviewed-by: Jakub Narebski 
Signed-off-by: Lars Schneider 
---
 Documentation/gitattributes.txt| 156 +-
 contrib/long-running-filter/example.pl | 123 +++
 convert.c  | 348 ---
 pkt-line.h |   1 +
 t/t0021-conversion.sh  | 365 -
 t/t0021/rot13-filter.pl| 191 +
 6 files changed, 1153 insertions(+), 31 deletions(-)
 create mode 100755 contrib/long-running-filter/example.pl
 create mode 100755 t/t0021/rot13-filter.pl

diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index 7aff940..946dcad 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -293,7 +293,13 @@ checkout, when the `smudge` command is specified, the 
command is
 fed the blob object from its standard input, and its standard
 output is used to update the worktree file.  Similarly, the
 `clean` command is used to convert the contents of worktree file
-upon checkin.
+upon checkin. By default these commands process only a single
+blob and terminate.  If a long running `process` filter is used
+in place of `clean` and/or `smudge` filters, then Git can process
+all blobs with a single filter command invocation for the entire
+life of a single Git command, for example `git add --all`.  See
+section below for the description of the protocol used to
+communicate with a `process` filter.
 
 One use of the content filtering is to massage the content into a shape
 that is more convenient for the platform, filesystem, and the user to use.
@@ -373,6 +379,154 @@ not exist, or may have different contents. So, smudge and 
clean commands
 should not try to access the file on disk, but only act as filters on the
 content provided to them on standard input.
 
+Long Running Filter Process
+^^^
+
+If the filter command (a string value) is defined via
+`filter..process` then Git can process all blobs with a
+single filter invocation for the entire life of a single Git
+command. This is achieved by using a packet format (pkt-line,
+see technical/protocol-common.txt) based protocol over standard
+input and standard output as follows. All packets are considered
+text and therefore are terminated by an LF. Exceptions are the
+"*CONTENT" packets and the flush packet.
+
+Git starts the filter when it encounters the first file
+that needs to be cleaned or smudged. After the filter started
+Git sends a welcome message ("git-filter-client"), a list of
+supported protocol version numbers, and a flush packet. Git expects
+to read a welcome response message ("git-filter-server") and exactly
+one protocol version number from the previously sent list. All further
+communication will be based on the selected version. The remaining
+protocol description below documents "version=2". Please note that
+"version=42" in the example below does not exist and is only 

[PATCH v8 10/11] convert: make apply_filter() adhere to standard Git error handling

[larsxschneider]

From: Lars Schneider 

apply_filter() returns a boolean that tells the caller if it
"did convert or did not convert". The variable `ret` was used throughout
the function to track errors whereas `1` denoted success and `0`
failure. This is unusual for the Git source where `0` denotes success.

Rename the variable and flip its value to make the function easier
readable for Git developers.

Signed-off-by: Lars Schneider 
---
 convert.c | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/convert.c b/convert.c
index 986c239..597f561 100644
--- a/convert.c
+++ b/convert.c
@@ -451,7 +451,7 @@ static int apply_filter(const char *path, const char *src, 
size_t len, int fd,
 *
 * (child --> cmd) --> us
 */
-   int ret = 1;
+   int err = 0;
struct strbuf nbuf = STRBUF_INIT;
struct async async;
struct filter_params params;
@@ -477,23 +477,20 @@ static int apply_filter(const char *path, const char 
*src, size_t len, int fd,
return 0;   /* error was already reported */
 
if (strbuf_read(, async.out, len) < 0) {
-   error("read from external filter '%s' failed", cmd);
-   ret = 0;
+   err = error("read from external filter '%s' failed", cmd);
}
if (close(async.out)) {
-   error("read from external filter '%s' failed", cmd);
-   ret = 0;
+   err = error("read from external filter '%s' failed", cmd);
}
if (finish_async()) {
-   error("external filter '%s' failed", cmd);
-   ret = 0;
+   err = error("external filter '%s' failed", cmd);
}
 
-   if (ret) {
+   if (!err) {
strbuf_swap(dst, );
}
strbuf_release();
-   return ret;
+   return !err;
 }
 
 static struct convert_driver {
-- 
2.10.0

[PATCH v8 07/11] pkt-line: add functions to read/write flush terminated packet streams

[larsxschneider]

From: Lars Schneider 

write_packetized_from_fd() and write_packetized_from_buf() write a
stream of packets. All content packets use the maximal packet size
except for the last one. After the last content packet a `flush` control
packet is written.

read_packetized_to_buf() reads arbitrary sized packets until it detects
a `flush` packet.

Signed-off-by: Lars Schneider 
---
 pkt-line.c | 68 ++
 pkt-line.h |  7 +++
 2 files changed, 75 insertions(+)

diff --git a/pkt-line.c b/pkt-line.c
index fc0ac12..a0a8543 100644
--- a/pkt-line.c
+++ b/pkt-line.c
@@ -196,6 +196,47 @@ void packet_buf_write(struct strbuf *buf, const char *fmt, 
...)
va_end(args);
 }
 
+int write_packetized_from_fd(int fd_in, int fd_out)
+{
+   static char buf[PKTLINE_DATA_MAXLEN];
+   int err = 0;
+   ssize_t bytes_to_write;
+
+   while (!err) {
+   bytes_to_write = xread(fd_in, buf, sizeof(buf));
+   if (bytes_to_write < 0)
+   return COPY_READ_ERROR;
+   if (bytes_to_write == 0)
+   break;
+   err = packet_write_gently(fd_out, buf, bytes_to_write);
+   }
+   if (!err)
+   err = packet_flush_gently(fd_out);
+   return err;
+}
+
+int write_packetized_from_buf(const char *src_in, size_t len, int fd_out)
+{
+   static char buf[PKTLINE_DATA_MAXLEN];
+   int err = 0;
+   size_t bytes_written = 0;
+   size_t bytes_to_write;
+
+   while (!err) {
+   if ((len - bytes_written) > sizeof(buf))
+   bytes_to_write = sizeof(buf);
+   else
+   bytes_to_write = len - bytes_written;
+   if (bytes_to_write == 0)
+   break;
+   err = packet_write_gently(fd_out, src_in + bytes_written, 
bytes_to_write);
+   bytes_written += bytes_to_write;
+   }
+   if (!err)
+   err = packet_flush_gently(fd_out);
+   return err;
+}
+
 static int get_packet_data(int fd, char **src_buf, size_t *src_size,
   void *dst, unsigned size, int options)
 {
@@ -305,3 +346,30 @@ char *packet_read_line_buf(char **src, size_t *src_len, 
int *dst_len)
 {
return packet_read_line_generic(-1, src, src_len, dst_len);
 }
+
+ssize_t read_packetized_to_buf(int fd_in, struct strbuf *sb_out)
+{
+   int paket_len;
+   int options = PACKET_READ_GENTLE_ON_EOF;
+
+   size_t oldlen = sb_out->len;
+   size_t oldalloc = sb_out->alloc;
+
+   for (;;) {
+   strbuf_grow(sb_out, PKTLINE_DATA_MAXLEN+1);
+   paket_len = packet_read(fd_in, NULL, NULL,
+   sb_out->buf + sb_out->len, PKTLINE_DATA_MAXLEN+1, 
options);
+   if (paket_len <= 0)
+   break;
+   sb_out->len += paket_len;
+   }
+
+   if (paket_len < 0) {
+   if (oldalloc == 0)
+   strbuf_release(sb_out);
+   else
+   strbuf_setlen(sb_out, oldlen);
+   return paket_len;
+   }
+   return sb_out->len - oldlen;
+}
diff --git a/pkt-line.h b/pkt-line.h
index 3fa0899..6df8449 100644
--- a/pkt-line.h
+++ b/pkt-line.h
@@ -25,6 +25,8 @@ void packet_buf_flush(struct strbuf *buf);
 void packet_buf_write(struct strbuf *buf, const char *fmt, ...) 
__attribute__((format (printf, 2, 3)));
 int packet_flush_gently(int fd);
 int packet_write_fmt_gently(int fd, const char *fmt, ...) 
__attribute__((format (printf, 2, 3)));
+int write_packetized_from_fd(int fd_in, int fd_out);
+int write_packetized_from_buf(const char *src_in, size_t len, int fd_out);
 
 /*
  * Read a packetized line into the buffer, which must be at least size bytes
@@ -77,6 +79,11 @@ char *packet_read_line(int fd, int *size);
  */
 char *packet_read_line_buf(char **src_buf, size_t *src_len, int *size);
 
+/*
+ * Reads a stream of variable sized packets until a flush packet is detected.
+ */
+ssize_t read_packetized_to_buf(int fd_in, struct strbuf *sb_out);
+
 #define DEFAULT_PACKET_MAX 1000
 #define LARGE_PACKET_MAX 65520
 extern char packet_buffer[LARGE_PACKET_MAX];
-- 
2.10.0

Re: [PATCH 1/6] i18n: commit: mark message for translation

[Jean-Noël AVILA]

Signed-off-by: Vasco Almeida 
Signed-off-by: Jean-Noel Avila 
---

Instead of distillating change requests, I'd better do it by myself. Here is 
the reworked version of the patch.

 diff.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/diff.c b/diff.c
index c6da383..494f723 100644
--- a/diff.c
+++ b/diff.c
@@ -55,6 +55,11 @@ static char diff_colors[][COLOR_MAXLEN] = {
GIT_COLOR_NORMAL,   /* FUNCINFO */
 };
 
+static NORETURN void die_want_option(const char *option_name)
+{
+   die(_("option '%s' requires a value"), option_name);
+}
+
 static int parse_diff_color_slot(const char *var)
 {
if (!strcasecmp(var, "context") || !strcasecmp(var, "plain"))
@@ -3325,7 +3330,7 @@ void diff_setup_done(struct diff_options *options)
if (options->output_format & DIFF_FORMAT_NO_OUTPUT)
count++;
if (count > 1)
-   die("--name-only, --name-status, --check and -s are mutually 
exclusive");
+   die(_("--name-only, --name-status, --check and -s are mutually 
exclusive"));
 
/*
 * Most of the time we can say "there are changes"
@@ -3521,7 +3526,7 @@ static int stat_opt(struct diff_options *options, const 
char **av)
if (*arg == '=')
width = strtoul(arg + 1, , 10);
else if (!*arg && !av[1])
-   die("Option '--stat-width' requires a value");
+   die_want_option("--stat-width");
else if (!*arg) {
width = strtoul(av[1], , 10);
argcount = 2;
@@ -3530,7 +3535,7 @@ static int stat_opt(struct diff_options *options, const 
char **av)
if (*arg == '=')
name_width = strtoul(arg + 1, , 10);
else if (!*arg && !av[1])
-   die("Option '--stat-name-width' requires a 
value");
+   die_want_option("--stat-name-width");
else if (!*arg) {
name_width = strtoul(av[1], , 10);
argcount = 2;
@@ -3539,7 +3544,7 @@ static int stat_opt(struct diff_options *options, const 
char **av)
if (*arg == '=')
graph_width = strtoul(arg + 1, , 10);
else if (!*arg && !av[1])
-   die("Option '--stat-graph-width' requires a 
value");
+   die_want_option("--stat-graph-width");
else if (!*arg) {
graph_width = strtoul(av[1], , 10);
argcount = 2;
@@ -3548,7 +3553,7 @@ static int stat_opt(struct diff_options *options, const 
char **av)
if (*arg == '=')
count = strtoul(arg + 1, , 10);
else if (!*arg && !av[1])
-   die("Option '--stat-count' requires a value");
+   die_want_option("--stat-count");
else if (!*arg) {
count = strtoul(av[1], , 10);
argcount = 2;
-- 
2.10.0

[PATCH v8 08/11] convert: quote filter names in error messages

[larsxschneider]

From: Lars Schneider 

Git filter driver commands with spaces (e.g. `filter.sh foo`) are hard
to read in error messages. Quote them to improve the readability.

Signed-off-by: Lars Schneider 
---
 convert.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/convert.c b/convert.c
index 077f5e6..986c239 100644
--- a/convert.c
+++ b/convert.c
@@ -412,7 +412,7 @@ static int filter_buffer_or_fd(int in, int out, void *data)
child_process.out = out;
 
if (start_command(_process))
-   return error("cannot fork to run external filter %s", 
params->cmd);
+   return error("cannot fork to run external filter '%s'", 
params->cmd);
 
sigchain_push(SIGPIPE, SIG_IGN);
 
@@ -430,13 +430,13 @@ static int filter_buffer_or_fd(int in, int out, void 
*data)
if (close(child_process.in))
write_err = 1;
if (write_err)
-   error("cannot feed the input to external filter %s", 
params->cmd);
+   error("cannot feed the input to external filter '%s'", 
params->cmd);
 
sigchain_pop(SIGPIPE);
 
status = finish_command(_process);
if (status)
-   error("external filter %s failed %d", params->cmd, status);
+   error("external filter '%s' failed %d", params->cmd, status);
 
strbuf_release();
return (write_err || status);
@@ -477,15 +477,15 @@ static int apply_filter(const char *path, const char 
*src, size_t len, int fd,
return 0;   /* error was already reported */
 
if (strbuf_read(, async.out, len) < 0) {
-   error("read from external filter %s failed", cmd);
+   error("read from external filter '%s' failed", cmd);
ret = 0;
}
if (close(async.out)) {
-   error("read from external filter %s failed", cmd);
+   error("read from external filter '%s' failed", cmd);
ret = 0;
}
if (finish_async()) {
-   error("external filter %s failed", cmd);
+   error("external filter '%s' failed", cmd);
ret = 0;
}
 
-- 
2.10.0

Re: Re: Homebrew and Git

[John Keeping]

On Tue, Sep 20, 2016 at 01:07:00PM +0200, Heiko Voigt wrote:
> On Tue, Sep 20, 2016 at 01:02:28PM +0200, Heiko Voigt wrote:
> > Hi,
> > 
> > On Sun, Sep 18, 2016 at 05:50:28PM +0200, Jonas Thiel wrote:
> > > A while ago I have described my problem with Homebrew at the following
> > > GitHub channel
> > > (https://github.com/Homebrew/homebrew-core/issues/2970). In the
> > > meanwhile, I believe that I my problem with Homebrew is based on an
> > > issues with my Git. I have found the attached Git Crash reports on my
> > > Mac and because I am not familiar with reading/analysing Crash
> > > Reports, it would be great if someone could give me some feedback on
> > > it.
> > >  
> > > If you have any question, please do not hesitate to contact me.
> > 
> > From your crash reports I see that git is apparently crashing in a
> > strchr() call from within ident_default_email() which is a function that
> > tries to assemble a name and email to put into your commits.
> 
> BTW, here is the callstack inlined from the crashreport:
> 
> bsystem_platform.dylib0x7fff840db41c 
> _platform_strchr$VARIANT$Haswell + 28
> 1   git   0x00010ba1d3f4 ident_default_email 
> + 801
> 2   git   0x00010ba1d68f fmt_ident + 66
> 3   git   0x00010ba4b495 files_log_ref_write 
> + 175
> 4   git   0x00010ba4b0a6 commit_ref_update + 
> 106
> 5   git   0x00010ba4c3a8 
> ref_transaction_commit + 468
> 6   git   0x00010b994dd8 s_update_ref + 271
> 7   git   0x00010b994556 fetch_refs + 1969
> 8   git   0x00010b9935f2 fetch_one + 1913
> 9   git   0x00010b992bc4 cmd_fetch + 549
> 10  git   0x00010b9666c4 handle_builtin + 478
> 11  git   0x00010b96602f main + 376
> 12  libdyld.dylib 0x7fff834ef5ad start + 1
> 
> Maybe someone else has an idea what might be causing this...

The only strchr I can see that could be called here is in
canonical_name(), where it's called with addrinfo::ai_canonname.

Searching for OS X and ai_canonname, leads me straight back to this
list, although 7 years ago!  I think ident.c needs a fix similar to
commit 3e8a00a (daemon.c: fix segfault on OS X, 2009-04-27); from the
commit message there:

On OS X (and maybe other unices), getaddrinfo(3) returns NULL
in the ai_canonname field if it's called with an IP address for
the hostname.

[PATCH v8 04/11] pkt-line: add packet_write_fmt_gently()

[larsxschneider]

From: Lars Schneider 

packet_write_fmt() would die in case of a write error even though for
some callers an error would be acceptable. Add packet_write_fmt_gently()
which writes a formatted pkt-line like packet_write_fmt() but does not
die in case of an error. The function is used in a subsequent patch.

Signed-off-by: Lars Schneider 
---
 pkt-line.c | 34 ++
 pkt-line.h |  1 +
 2 files changed, 31 insertions(+), 4 deletions(-)

diff --git a/pkt-line.c b/pkt-line.c
index e8adc0f..3b465fd 100644
--- a/pkt-line.c
+++ b/pkt-line.c
@@ -125,16 +125,42 @@ static void format_packet(struct strbuf *out, const char 
*fmt, va_list args)
packet_trace(out->buf + orig_len + 4, n - 4, 1);
 }
 
+static int packet_write_fmt_1(int fd, int gently,
+  const char *fmt, va_list args)
+{
+   struct strbuf buf = STRBUF_INIT;
+   size_t count;
+
+   format_packet(, fmt, args);
+   count = write_in_full(fd, buf.buf, buf.len);
+   if (count == buf.len)
+   return 0;
+
+   if (!gently) {
+   check_pipe(errno);
+   die_errno("packet write with format failed");
+   }
+   return error("packet write with format failed");
+}
+
 void packet_write_fmt(int fd, const char *fmt, ...)
 {
-   static struct strbuf buf = STRBUF_INIT;
va_list args;
 
-   strbuf_reset();
va_start(args, fmt);
-   format_packet(, fmt, args);
+   packet_write_fmt_1(fd, 0, fmt, args);
+   va_end(args);
+}
+
+int packet_write_fmt_gently(int fd, const char *fmt, ...)
+{
+   int status;
+   va_list args;
+
+   va_start(args, fmt);
+   status = packet_write_fmt_1(fd, 1, fmt, args);
va_end(args);
-   write_or_die(fd, buf.buf, buf.len);
+   return status;
 }
 
 void packet_buf_write(struct strbuf *buf, const char *fmt, ...)
diff --git a/pkt-line.h b/pkt-line.h
index 1902fb3..3caea77 100644
--- a/pkt-line.h
+++ b/pkt-line.h
@@ -23,6 +23,7 @@ void packet_flush(int fd);
 void packet_write_fmt(int fd, const char *fmt, ...) __attribute__((format 
(printf, 2, 3)));
 void packet_buf_flush(struct strbuf *buf);
 void packet_buf_write(struct strbuf *buf, const char *fmt, ...) 
__attribute__((format (printf, 2, 3)));
+int packet_write_fmt_gently(int fd, const char *fmt, ...) 
__attribute__((format (printf, 2, 3)));
 
 /*
  * Read a packetized line into the buffer, which must be at least size bytes
-- 
2.10.0

[PATCH v8 02/11] pkt-line: extract set_packet_header()

[larsxschneider]

From: Lars Schneider 

set_packet_header() converts an integer to a 4 byte hex string. Make
this function locally available so that other pkt-line functions can
use it.

Signed-off-by: Lars Schneider 
---
 pkt-line.c | 19 +--
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/pkt-line.c b/pkt-line.c
index 0a9b61c..e8adc0f 100644
--- a/pkt-line.c
+++ b/pkt-line.c
@@ -97,10 +97,20 @@ void packet_buf_flush(struct strbuf *buf)
strbuf_add(buf, "", 4);
 }
 
-#define hex(a) (hexchar[(a) & 15])
-static void format_packet(struct strbuf *out, const char *fmt, va_list args)
+static void set_packet_header(char *buf, const int size)
 {
static char hexchar[] = "0123456789abcdef";
+
+   #define hex(a) (hexchar[(a) & 15])
+   buf[0] = hex(size >> 12);
+   buf[1] = hex(size >> 8);
+   buf[2] = hex(size >> 4);
+   buf[3] = hex(size);
+   #undef hex
+}
+
+static void format_packet(struct strbuf *out, const char *fmt, va_list args)
+{
size_t orig_len, n;
 
orig_len = out->len;
@@ -111,10 +121,7 @@ static void format_packet(struct strbuf *out, const char 
*fmt, va_list args)
if (n > LARGE_PACKET_MAX)
die("protocol error: impossibly long line");
 
-   out->buf[orig_len + 0] = hex(n >> 12);
-   out->buf[orig_len + 1] = hex(n >> 8);
-   out->buf[orig_len + 2] = hex(n >> 4);
-   out->buf[orig_len + 3] = hex(n);
+   set_packet_header(>buf[orig_len], n);
packet_trace(out->buf + orig_len + 4, n - 4, 1);
 }
 
-- 
2.10.0

[PATCH v8 05/11] pkt-line: add packet_flush_gently()

[larsxschneider]

From: Lars Schneider 

packet_flush() would die in case of a write error even though for some
callers an error would be acceptable. Add packet_flush_gently() which
writes a pkt-line flush packet like packet_flush() but does not die in
case of an error. The function is used in a subsequent patch.

Signed-off-by: Lars Schneider 
---
 pkt-line.c | 8 
 pkt-line.h | 1 +
 2 files changed, 9 insertions(+)

diff --git a/pkt-line.c b/pkt-line.c
index 3b465fd..19f0271 100644
--- a/pkt-line.c
+++ b/pkt-line.c
@@ -91,6 +91,14 @@ void packet_flush(int fd)
write_or_die(fd, "", 4);
 }
 
+int packet_flush_gently(int fd)
+{
+   packet_trace("", 4, 1);
+   if (write_in_full(fd, "", 4) == 4)
+   return 0;
+   return error("flush packet write failed");
+}
+
 void packet_buf_flush(struct strbuf *buf)
 {
packet_trace("", 4, 1);
diff --git a/pkt-line.h b/pkt-line.h
index 3caea77..3fa0899 100644
--- a/pkt-line.h
+++ b/pkt-line.h
@@ -23,6 +23,7 @@ void packet_flush(int fd);
 void packet_write_fmt(int fd, const char *fmt, ...) __attribute__((format 
(printf, 2, 3)));
 void packet_buf_flush(struct strbuf *buf);
 void packet_buf_write(struct strbuf *buf, const char *fmt, ...) 
__attribute__((format (printf, 2, 3)));
+int packet_flush_gently(int fd);
 int packet_write_fmt_gently(int fd, const char *fmt, ...) 
__attribute__((format (printf, 2, 3)));
 
 /*
-- 
2.10.0

Re: [PATCH] gitweb: use highlight's shebang detection

[Jakub Narębski]

W dniu 06.09.2016 o 21:00, Ian Kelling pisze:

> The highlight binary can detect language by shebang when we can't tell
> the syntax type by the name of the file. 

Was it something always present among highlight[1] binary capabilities,
or is it something present only in new enough highlight app?  Or only
in some specific fork / specific binary?  I couldn't find language
detection in highlight[1] documentation...

[1]: http://www.andre-simon.de/doku/highlight/en/highlight.php

If this feature is available only for some version, or for some
highlighters, gitweb would have to provide an option to configure
it.  It might be an additional configuration variable, it might
be a special value in the %highlight_basename or %highlight_ext.

>  To use highlight's shebang
> detection, add highlight to the pipeline whenever highlight is enabled.

This describes what this patch does, but the sentence feels
a bit convoluted, as it is stated.

> 
> Document the shebang detection and add a test which exercises it in
> t/t9500-gitweb-standalone-no-errors.sh.

Nice!

> 
> Signed-off-by: Ian Kelling 
> ---
> 
> Notes:
> I wondered if adding highlight to the pipeline would make viewing a blob
> with no highlighting take longer but it did not on my computer. I found
> no noticeable impact on small files and strangely, on a 159k file, it
> took 7% less time averaged over several requests.

Strange.  I would guess that invoking separate binary and perl would always
add to the time (especially on operation systems where forking / running
command is expensive... though those are not often used with web servers,
isn't it).

> 
>  Documentation/gitweb.conf.txt  | 21 ++---
>  gitweb/gitweb.perl | 10 +-
>  t/t9500-gitweb-standalone-no-errors.sh | 18 +-
>  3 files changed, 32 insertions(+), 17 deletions(-)
> 
> diff --git a/Documentation/gitweb.conf.txt b/Documentation/gitweb.conf.txt
> index a79e350..e632089 100644
> --- a/Documentation/gitweb.conf.txt
> +++ b/Documentation/gitweb.conf.txt
> @@ -246,13 +246,20 @@ $highlight_bin::
>   Note that 'highlight' feature must be set for gitweb to actually
>   use syntax highlighting.
>  +
> -*NOTE*: if you want to add support for new file type (supported by
> -"highlight" but not used by gitweb), you need to modify `%highlight_ext`
> -or `%highlight_basename`, depending on whether you detect type of file
> -based on extension (for example "sh") or on its basename (for example
> -"Makefile").  The keys of these hashes are extension and basename,
> -respectively, and value for given key is name of syntax to be passed via
> -`--syntax ` to highlighter.
> +*NOTE*: for a file to be highlighted, its syntax type must be detected
> +and that syntax must be supported by "highlight".  The default syntax
> +detection is minimal, and there are many supported syntax types with no
> +detection by default.  There are three options for adding syntax
> +detection.  The first and second priority are `%highlight_basename` and
> +`%highlight_ext`, which detect based on basename (the full filename, for
> +example "Makefile") and extension (for example "sh").  The keys of these
> +hashes are the basename and extension, respectively, and the value for a
> +given key is the name of the syntax to be passed via `--syntax `
> +to "highlight".  The last priority is the "highlight" configuration of
> +`Shebang` regular expressions to detect the language based on the first
> +line in the file, (for example, matching the line "#!/bin/bash").  See
> +the highlight documentation and the default config at
> +/etc/highlight/filetypes.conf for more details.

All right; in addition to expanding the docs, it also improves them.

>  +
>  For example if repositories you are hosting use "phtml" extension for
>  PHP files, and you want to have correct syntax-highlighting for those
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 33d701d..a672181 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -3931,15 +3931,16 @@ sub guess_file_syntax {
>  # or return original FD if no highlighting
>  sub run_highlighter {
>   my ($fd, $highlight, $syntax) = @_;
> - return $fd unless ($highlight && defined $syntax);
> + return $fd unless ($highlight);

Here we would have check if we want / can invoke "highlight".

>  
>   close $fd;
> + my $syntax_arg = (defined $syntax) ? "--syntax $syntax" : "--force";
>   open $fd, quote_command(git_cmd(), "cat-file", "blob", $hash)." | ".
> quote_command($^X, '-CO', '-MEncode=decode,FB_DEFAULT', 
> '-pse',
>   '$_ = decode($fe, $_, FB_DEFAULT) if !utf8::decode($_);',
>   '--', "-fe=$fallback_encoding")." | ".
> quote_command($highlight_bin).
> -   " --replace-tabs=8 --fragment --syntax $syntax |"
> +   " --replace-tabs=8 

Re: 2.10.0: git log --oneline prints gpg signatures in 4 lines

[Jeff King]

On Tue, Sep 20, 2016 at 05:09:54PM +0200, Leandro Lucarella wrote:

> Hi, starting from 2.10.0 I noticed that when using git log --oneline,
> if commits are signed with GPG, now the signatures are printed too, and
> it takes 3 lines for the signature information + 1 line for the title
> of the commit, so suddenly --oneline became --fourline :)
> 
> Is this really intended?

I don't think anything has changed here in 2.10. Running "git log
--oneline --show-signature" has _always_ been horribly ugly. However,
2.10 did introduce the "log.showsignature" config, which makes "git log
--oneline" pretty unusable when it is enabled. Ditto for one-liner uses
of "--format".

I think we should probably ignore the config entirely when using any of
the one-liner formats (and I'd include --format, too, even though it can
sometimes be multi-line; it already has %GG to include that information
as appropriate).

Another option would be to somehow represent the signature information
in the --oneline output, but I think I'd rather leave that for people to
experiment with using "--format".

-Peff

(Loans)

[empd]

 Loan

A legitimate loan firm based in the US.With our technology we can approve a 
suitable loan in minutes.We lend from 50,000 Rs to 10,000,000 Rs at just 3% 
interest rate with Flexible repayment over 1 to 30 years

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

[Vasco Almeida]

Hi Junio Hamano,

I have sent some git-gui patches on May this year and I think it will
add value to accepted them at some point:

git-gui: i18n stuff and small fixes
<1462704778-4722-1-git-send-email-vascomalme...@sapo.pt>
http://www.mail-archive.com/git@vger.kernel.org/msg92780.html

git-gui: l10n: add Portuguese translation
<1462550802-20601-1-git-send-email-vascomalme...@sapo.pt>
http://www.mail-archive.com/git@vger.kernel.org/msg92611.html


There is the gitk Portuguese translation also, but that is out of the
topic. For reference:

gitk: Makefile: create install bin directory
<1462470392-19991-1-git-send-email-vascomalme...@sapo.pt>
http://www.mail-archive.com/git@vger.kernel.org/msg92474.html

gitk: Add Portuguese translation
<1462996893-24341-1-git-send-email-vascomalme...@sapo.pt>
http://www.mail-archive.com/git@vger.kernel.org/msg93176.html


Thank you.