Re: [PATCH] gitk: don't highlight submodule diff lines outside submodule diffs

2018-11-06 Thread Роман Донченко
06.11.2018 23:06, Stefan Beller пишет: On Tue, Nov 6, 2018 at 12:03 PM Роман Донченко wrote: A line that starts with " <" or " >" is not necessarily a submodule diff line. It might just be a context line in a normal diff, representing a line starting with " &l

[PATCH] gitk: don't highlight submodule diff lines outside submodule diffs

2018-11-06 Thread Роман Донченко
er we are currently inside a submodule diff and only highlight these lines if we are. Signed-off-by: Роман Донченко --- gitk | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/gitk b/gitk index a14d7a1..6bb6dc6 100755 --- a/gitk +++ b/gitk @@ -8109,6 +8109,8 @@ proc parseblob

[PATCH v2 1/2] send-email: align RFC 2047 decoding more closely with the spec

2014-12-14 Thread Роман Донченко
quot; to identify the encoding. * Allow lowercase hexadecimal digits in the "Q" encoding. And, more on the cosmetic side: * Change the "encoded-text" regex to exclude rather than include characters, for clarity and consistency with "token". Signed-off-by: Роман

[PATCH v2 2/2] send-email: handle adjacent RFC 2047-encoded words properly

2014-12-14 Thread Роман Донченко
The RFC says that they are to be concatenated after decoding (i.e. the intervening whitespace is ignored). Signed-off-by: Роман Донченко Acked-by: Jeff King --- git-send-email.perl | 26 -- t/t9001-send-email.sh | 7 +++ 2 files changed, 23 insertions(+), 10

Re: [PATCH v2 2/2] send-email: handle adjacent RFC 2047-encoded words properly

2014-12-07 Thread Роман Донченко
Philip Oakley писал в своём письме Sun, 07 Dec 2014 20:48:05 +0300: From: "Роман Донченко" Jeff King писал в своём письме Sun, 07 Dec 2014 12:18:59 +0300: On Sat, Dec 06, 2014 at 10:36:23PM +0300, Роман Донченко wrote: One final note on this bit of code: if there are multip

Re: [PATCH v2 2/2] send-email: handle adjacent RFC 2047-encoded words properly

2014-12-07 Thread Роман Донченко
Jeff King писал в своём письме Sun, 07 Dec 2014 12:18:59 +0300: On Sat, Dec 06, 2014 at 10:36:23PM +0300, Роман Донченко wrote: The RFC says that they are to be concatenated after decoding (i.e. the intervening whitespace is ignored). Thanks. Both patches look good to me, and I'

[PATCH v2 1/2] send-email: align RFC 2047 decoding more closely with the spec

2014-12-06 Thread Роман Донченко
quot; to identify the encoding. * Allow lowercase hexadecimal digits in the "Q" encoding. And, more on the cosmetic side: * Change the "encoded-text" regex to exclude rather than include characters, for clarity and consistency with "token".

[PATCH v2 2/2] send-email: handle adjacent RFC 2047-encoded words properly

2014-12-06 Thread Роман Донченко
The RFC says that they are to be concatenated after decoding (i.e. the intervening whitespace is ignored). --- git-send-email.perl | 26 -- t/t9001-send-email.sh | 7 +++ 2 files changed, 23 insertions(+), 10 deletions(-) diff --git a/git-send-email.perl b/git-send-

Re: [PATCH] send-email: handle adjacent RFC 2047-encoded words properly

2014-11-24 Thread Роман Донченко
Jeff King писал в своём письме Mon, 24 Nov 2014 18:36:09 +0300: On Mon, Nov 24, 2014 at 02:50:04AM +0300, Роман Донченко wrote: The RFC says that they are to be concatenated after decoding (i.e. the intervening whitespace is ignored). I change the sender's name to an all-Cyrillic s

Re: [PATCH] send-email: handle adjacent RFC 2047-encoded words properly

2014-11-24 Thread Роман Донченко
Junio C Hamano писал в своём письме Mon, 24 Nov 2014 10:27:51 +0300: On Sun, Nov 23, 2014 at 3:50 PM, Роман Донченко wrote: The RFC says that they are to be concatenated after decoding (i.e. the intervening whitespace is ignored). I change the sender's name to an all-Cyrillic stri

[PATCH] send-email: handle adjacent RFC 2047-encoded words properly

2014-11-23 Thread Роман Донченко
coded words. Since I have to modify the regular expression for an encoded word anyway, I take the opportunity to bring it closer to the spec, most notably disallowing embedded spaces and making it case-insensitive (thus allowing the encoding to be specified as both "q" and "Q"