* [PATCH 2/3] doc: gitk: add the upstream repo location
From: Philip Oakley @ 2017-01-12 21:32 UTC (permalink / raw)
To: GitList; +Cc: Junio C Hamano, Paul Mackerras
In-Reply-To: <20170112213240.7972-1-philipoakley@iee.org>
Match the 'git gui' information regarding the graphical browser
and its upstream location.
Signed-off-by: Philip Oakley <philipoakley@iee.org>
---
cc: Paul Mackerras <paulus@ozlabs.org>
---
Documentation/gitk.txt | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt
index 73c02b9..9244379 100644
--- a/Documentation/gitk.txt
+++ b/Documentation/gitk.txt
@@ -178,9 +178,15 @@ used by default. If '$XDG_CONFIG_HOME' is not set it defaults to
History
-------
Gitk was the first graphical repository browser. It's written in
-tcl/tk and started off in a separate repository but was later merged
-into the main Git repository.
+tcl/tk.
+'gitk' is actually maintained as an independent project, but stable
+versions are distributed as part of the Git suite for the convenience
+of end users.
+
+gitk-git/ comes from Paul Mackerras's gitk project:
+
+ git://ozlabs.org/~paulus/gitk
SEE ALSO
--------
--
2.9.0.windows.1.323.g0305acf
^ permalink raw reply related
* [PATCH 0/3] updates to gitk & git-gui doc now gitview has gone
From: Philip Oakley @ 2017-01-12 21:32 UTC (permalink / raw)
To: GitList; +Cc: Junio C Hamano
gitview was removed recently.
> Sent: Tuesday, January 10, 2017 11:48 PM
> Subject: What's cooking in git.git (Jan 2017, #01; Tue, 10)
> * sb/remove-gitview (2017-01-07) 1 commit
> (merged to 'next' on 2017-01-10 at dcb3abd146)
> + contrib: remove gitview
> Will merge to 'master'.
Lets remove the reference in the gitk man page, and do some other
fixups while in the area.
Philip Oakley (3):
doc: gitk: remove gitview reference
doc: gitk: add the upstream repo location
doc: git-gui browser does not default to HEAD
Documentation/git-gui.txt | 2 +-
Documentation/gitk.txt | 14 ++++++++------
2 files changed, 9 insertions(+), 7 deletions(-)
--
2.9.0.windows.1.323.g0305acf
^ permalink raw reply
* Re: Bug report: Git pull hang occasionally
From: Kai Zhang @ 2017-01-12 21:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqqy3yghtio.fsf@gitster.mtv.corp.google.com>
> On Jan 12, 2017, at 1:12 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> Kai Zhang <kai@netskope.com> writes:
>
>>> On Dec 21, 2016, at 1:32 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>>
>>> Junio C Hamano <gitster@pobox.com> writes:
>>> ...
>>>
>>> I wonder if the latter is solved by recent patch 296b847c0d
>>> ("remote-curl: don't hang when a server dies before any output",
>>> 2016-11-18) on the client side.
>>> ...
>
>> After apply this patch, hanging did not happen again.
>
> Thanks for confirming.
>
>> Would this patch go to release in near future?
>
> I see 296b847c0d in the message you are responding to (by the way,
> do not top-post to this list).
>
> Let's check it together.
>
> $ git log master..296b847c0d
> $ git merge-base master 296b847c0d
> 296b847c0d6de63353e236cfbf94163d24155529
>
> Yup, it already is in master.
>
> Using a third-party script "when-merged" [*1*], we can easily find
> that it was merged a few days ago to 'master', after cooking in
> 'next' for a handful of weeks:
>
> $ git when-merged 296b847c0d next
> refs/heads/next 3ea70d01afc6305b88d33b8585f1fc41c486a182
> $ git when-merged 296b847c0d master
> refs/heads/master d984592043aec3c9f5b1955560a133896ca115b5
> $ git show -s --format='%cI' 3ea70d01af d984592043
> 2016-12-05T11:38:03-08:00
> 2017-01-10T15:24:25-08:00
>
> Unless people find regressions caused by this change (in which case
> we may have to revert it), this will be included in the release at
> the end of this cycle. http://tinyurl.com/gitCal tells us that the
> current cycle is expected to complete early February.
>
>
> [Footnote]
>
> *1* git://github.com/mhagger/git-when-merged
Thank you for your help!
^ permalink raw reply
* Re: Bug report: Git pull hang occasionally
From: Junio C Hamano @ 2017-01-12 21:12 UTC (permalink / raw)
To: Kai Zhang; +Cc: git
In-Reply-To: <E9196161-995C-4575-9560-D7E7B9A6B43D@netskope.com>
Kai Zhang <kai@netskope.com> writes:
>> On Dec 21, 2016, at 1:32 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>
>> Junio C Hamano <gitster@pobox.com> writes:
>> ...
>>
>> I wonder if the latter is solved by recent patch 296b847c0d
>> ("remote-curl: don't hang when a server dies before any output",
>> 2016-11-18) on the client side.
>> ...
> After apply this patch, hanging did not happen again.
Thanks for confirming.
> Would this patch go to release in near future?
I see 296b847c0d in the message you are responding to (by the way,
do not top-post to this list).
Let's check it together.
$ git log master..296b847c0d
$ git merge-base master 296b847c0d
296b847c0d6de63353e236cfbf94163d24155529
Yup, it already is in master.
Using a third-party script "when-merged" [*1*], we can easily find
that it was merged a few days ago to 'master', after cooking in
'next' for a handful of weeks:
$ git when-merged 296b847c0d next
refs/heads/next 3ea70d01afc6305b88d33b8585f1fc41c486a182
$ git when-merged 296b847c0d master
refs/heads/master d984592043aec3c9f5b1955560a133896ca115b5
$ git show -s --format='%cI' 3ea70d01af d984592043
2016-12-05T11:38:03-08:00
2017-01-10T15:24:25-08:00
Unless people find regressions caused by this change (in which case
we may have to revert it), this will be included in the release at
the end of this cycle. http://tinyurl.com/gitCal tells us that the
current cycle is expected to complete early February.
[Footnote]
*1* git://github.com/mhagger/git-when-merged
^ permalink raw reply
* Re: [PATCH 2/2] Use 'env' to find perl instead of fixed path
From: Pat Pannuto @ 2017-01-12 21:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Johannes Sixt, git
In-Reply-To: <xmqqbmvcj9le.fsf@gitster.mtv.corp.google.com>
I'm happy to let this drop.
I've filed the missing perl library as a homebrew issue [1], so
hopefully this won't be an issue for folks in the future.
You may still want the 1/2 patch in this series, just to make things
internally consistent with "-w" vs "use warnings;" inside git's perl
scripts.
-Pat
[1] https://github.com/Homebrew/homebrew-core/issues/8783
On Thu, Jan 12, 2017 at 3:40 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> So if this patch would make it into upstream Git, I would *have* to revert
>> it in Git for Windows, adding to my already considerable maintenance burden.
>
> I do not think we want "#!/usr/bin/env $language" in the upstream,
> either.
>
^ permalink raw reply
* Re: [PATCH v2] diff: add interhunk context config option
From: Junio C Hamano @ 2017-01-12 20:56 UTC (permalink / raw)
To: Vegard Nossum; +Cc: git, René Scharfe, Pranit Bauva
In-Reply-To: <1484223671-5476-1-git-send-email-vegard.nossum@oracle.com>
Vegard Nossum <vegard.nossum@oracle.com> writes:
> diff --git a/Documentation/diff-config.txt b/Documentation/diff-config.txt
> index 58f4bd6..d8cd854 100644
> --- a/Documentation/diff-config.txt
> +++ b/Documentation/diff-config.txt
> @@ -60,6 +60,12 @@ diff.context::
> Generate diffs with <n> lines of context instead of the default
> of 3. This value is overridden by the -U option.
>
> +diff.interHunkContext::
> + Show the context between diff hunks, up to <n> lines, thereby
> + fusing the hunks that are close to each other. The default is 0,
> + meaning no fusing will occur. This value is overridden by the
> + --inter-hunk-context option.
This is good if it were a description for
"--inter-hunk-context=<n>", but the text needs to be adjusted if it
were to be used for "diff.interHunkContext". It is unclear how the
'<n>' the description refers to comes from.
I suspect that it would be sufficient to just revert the first
sentence to exactly match the way --inter-hunk-context=<lines> is
described.
> diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
> index e6215c3..a219aa2 100644
> --- a/Documentation/diff-options.txt
> +++ b/Documentation/diff-options.txt
> @@ -511,6 +511,8 @@ endif::git-format-patch[]
> --inter-hunk-context=<lines>::
> Show the context between diff hunks, up to the specified number
> of lines, thereby fusing hunks that are close to each other.
> + Defaults to `diff.interHunkContext` or 0 if the config option
> + is unset.
This one is good, but then "The default is 0, meaning no fusing will
occur." in "diff.interHunkContext" is misleading and unnecessary.
When "diff.interHunkContext" is not set, it simply is not set (as
opposed to having a default value of 0).
> diff --git a/t/t4032-diff-inter-hunk-context.sh b/t/t4032-diff-inter-hunk-context.sh
> index e4e3e28..d9ac9d1 100755
> --- a/t/t4032-diff-inter-hunk-context.sh
> +++ b/t/t4032-diff-inter-hunk-context.sh
> @@ -16,11 +16,15 @@ f() {
> }
>
> t() {
> + use_config=""
It is more customary to just say
use_config=
All of the above are micronits that I can locally touch-up. For
now, I'll queue the following.
-- >8 --
From: Vegard Nossum <vegard.nossum@oracle.com>
Date: Thu, 12 Jan 2017 13:21:11 +0100
Subject: [PATCH] diff: add interhunk context config option
The --inter-hunk-context= option was added in commit 6d0e674a5754
("diff: add option to show context between close hunks"). This patch
allows configuring a default for this option.
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/diff-config.txt | 6 ++++++
Documentation/diff-options.txt | 2 ++
diff.c | 8 ++++++++
t/t4032-diff-inter-hunk-context.sh | 27 ++++++++++++++++++++++++++-
4 files changed, 42 insertions(+), 1 deletion(-)
diff --git a/Documentation/diff-config.txt b/Documentation/diff-config.txt
index d8570f2a75..15521f5191 100644
--- a/Documentation/diff-config.txt
+++ b/Documentation/diff-config.txt
@@ -60,6 +60,12 @@ diff.context::
Generate diffs with <n> lines of context instead of the default
of 3. This value is overridden by the -U option.
+diff.interHunkContext::
+ Show the context between diff hunks, up to the specified number
+ of lines, thereby fusing the hunks that are close to each other.
+ This value serves as the default for the `--inter-hunk-context`
+ command line option.
+
diff.external::
If this config variable is set, diff generation is not
performed using the internal diff machinery, but using the
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index e6215c372c..a219aa2907 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -511,6 +511,8 @@ endif::git-format-patch[]
--inter-hunk-context=<lines>::
Show the context between diff hunks, up to the specified number
of lines, thereby fusing hunks that are close to each other.
+ Defaults to `diff.interHunkContext` or 0 if the config option
+ is unset.
-W::
--function-context::
diff --git a/diff.c b/diff.c
index e2eb6d66a9..f08cd8e033 100644
--- a/diff.c
+++ b/diff.c
@@ -32,6 +32,7 @@ static int diff_rename_limit_default = 400;
static int diff_suppress_blank_empty;
static int diff_use_color_default = -1;
static int diff_context_default = 3;
+static int diff_interhunk_context_default;
static const char *diff_word_regex_cfg;
static const char *external_diff_cmd_cfg;
static const char *diff_order_file_cfg;
@@ -239,6 +240,12 @@ int git_diff_ui_config(const char *var, const char *value, void *cb)
return -1;
return 0;
}
+ if (!strcmp(var, "diff.interhunkcontext")) {
+ diff_interhunk_context_default = git_config_int(var, value);
+ if (diff_interhunk_context_default < 0)
+ return -1;
+ return 0;
+ }
if (!strcmp(var, "diff.renames")) {
diff_detect_rename_default = git_config_rename(var, value);
return 0;
@@ -3362,6 +3369,7 @@ void diff_setup(struct diff_options *options)
options->rename_limit = -1;
options->dirstat_permille = diff_dirstat_permille_default;
options->context = diff_context_default;
+ options->interhunkcontext = diff_interhunk_context_default;
options->ws_error_highlight = ws_error_highlight_default;
DIFF_OPT_SET(options, RENAME_EMPTY);
diff --git a/t/t4032-diff-inter-hunk-context.sh b/t/t4032-diff-inter-hunk-context.sh
index e4e3e28fc7..bada0cbd32 100755
--- a/t/t4032-diff-inter-hunk-context.sh
+++ b/t/t4032-diff-inter-hunk-context.sh
@@ -16,11 +16,15 @@ f() {
}
t() {
+ use_config=
+ git config --unset diff.interHunkContext
+
case $# in
4) hunks=$4; cmd="diff -U$3";;
5) hunks=$5; cmd="diff -U$3 --inter-hunk-context=$4";;
+ 6) hunks=$5; cmd="diff -U$3"; git config diff.interHunkContext $4; use_config="(diff.interHunkContext=$4) ";;
esac
- label="$cmd, $1 common $2"
+ label="$use_config$cmd, $1 common $2"
file=f$1
expected=expected.$file.$3.$hunks
@@ -89,4 +93,25 @@ t 9 lines 3 2
t 9 lines 3 2 2
t 9 lines 3 3 1
+# use diff.interHunkContext?
+t 1 line 0 0 2 config
+t 1 line 0 1 1 config
+t 1 line 0 2 1 config
+t 9 lines 3 3 1 config
+t 2 lines 0 0 2 config
+t 2 lines 0 1 2 config
+t 2 lines 0 2 1 config
+t 3 lines 1 0 2 config
+t 3 lines 1 1 1 config
+t 3 lines 1 2 1 config
+t 9 lines 3 2 2 config
+t 9 lines 3 3 1 config
+
+test_expect_success 'diff.interHunkContext invalid' '
+ git config diff.interHunkContext asdf &&
+ test_must_fail git diff &&
+ git config diff.interHunkContext -1 &&
+ test_must_fail git diff
+'
+
test_done
--
2.11.0-559-ge2476dcca1
^ permalink raw reply related
* Re: git clone failing when used through bundler on Docker for Windows with a shared volume
From: Philip Oakley @ 2017-01-12 20:51 UTC (permalink / raw)
To: Omar Qureshi, git
In-Reply-To: <CA+-cb7TuPd-n-HZO-60cKAysmtTaVMcviC2W+bhxz7hikbY-RA@mail.gmail.com>
From: "Omar Qureshi" <omar@omarqureshi.net>
> Hi there, I'm not sure this is the best place for this, but, this
> seems to be an issue with Git when used through Docker on Windows when
> there is a shared volume.
>
> The issue is documented at
> https://github.com/bundler/bundler/issues/5322 and I've provided a git
I think this was
7814fbe ("normalize_path_copy(): fix pushing to //server/share/dir on
Windows", 2016-12-14)
I've added a longer comment to the github issue (didn't have email at the
time)
> repository that allows you to simulate the issue, for this the
> requirements are Docker for Windows with the Docker client installed
> on WSL as well as docker-compose installed via pip.
>
> Docker for Windows will need to be configured to have a shared drive
>
> Also, it makes no difference if a tag is provided or not
>
--
Philip
^ permalink raw reply
* Re: [PATCH 2/2] Use 'env' to find perl instead of fixed path
From: Junio C Hamano @ 2017-01-12 20:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Pat Pannuto, Johannes Sixt, git
In-Reply-To: <alpine.DEB.2.20.1701121118170.3469@virtualbox>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> So if this patch would make it into upstream Git, I would *have* to revert
> it in Git for Windows, adding to my already considerable maintenance burden.
I do not think we want "#!/usr/bin/env $language" in the upstream,
either.
^ permalink raw reply
* Re: [PATCH 2/2] mailinfo: Understand forwarded patches
From: Junio C Hamano @ 2017-01-12 20:18 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: git, Matthew Wilcox, Jonathan Tan
In-Reply-To: <1484212824-14108-2-git-send-email-mawilcox@linuxonhyperv.com>
Matthew Wilcox <mawilcox@linuxonhyperv.com> writes:
> From: Matthew Wilcox <mawilcox@microsoft.com>
>
> Extend the --scissors mechanism to strip off the preamble created by
> forwarding a patch. There are a couple of extra headers ("Sent" and
> "To") added by forwarding, but other than that, the --scissors option
> will now remove patches forwarded from Microsoft Outlook to a Linux
> email account.
>
> Signed-off-by: Matthew Wilcox <mawilcox@microsoft.com>
> ---
> mailinfo.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
To be quite honest, I am not enthused to even having to think about
this kind of change. There seems to be no standard way MUAs produce
"forwarded" messages, and this adds support for only one specific
MUA, that happens to say "Original Message". Why should such a thing
hardcoded in this codepath?
I think I am OK with a patch that lets users customize
is_scissors_line(), perhaps accepting a regexp that ought to match a
line to consider a scissors line. When such a regexp is given,
check for a match before doing the "do we have a line filled with
'-' with the scissors marker and is the mark long enough?" check.
Then you can do
mailinfo --scissors='^-{5}Original Message-{5}$'
or something like that. Perhaps allow multiple regexps, or even
allow them to come from a multi-valued configuration variable.
> diff --git a/mailinfo.c b/mailinfo.c
> index 2059704a8..fc1275532 100644
> --- a/mailinfo.c
> +++ b/mailinfo.c
> @@ -332,7 +332,7 @@ static void cleanup_subject(struct mailinfo *mi, struct strbuf *subject)
>
> #define MAX_HDR_PARSED 10
> static const char *header[MAX_HDR_PARSED] = {
> - "From","Subject","Date",
> + "From","Subject","Date","Sent","To",
> };
This array lists fields whose value we _care_ about. Do not put
random garbage whose value we do not use in it.
Even though I am not enthused to see support for messages forwarded
by Outlook bolted onto this codepath, I think it may make sense to
allow random garbage that looks like an e-mail header to appear
immediately after a scissors line (and ignore them). For that,
perhaps you would instead want to extend is_inbody_header() so that
after it decides that the given line is *NOT* one of the header
field we care about, return a value that is not 0 or 1. Its caller
currently expects to see 1 if it is a relevant in-body header line,
or 0 if the line signals the end of the in-body header block. You'd
be adding another class of lines that are not a header line with a
meaning but do not terminate the in-body header block.
> static inline int cmp_header(const struct strbuf *line, const char *hdr)
> @@ -685,6 +685,13 @@ static int is_scissors_line(const char *line)
> c++;
> continue;
> }
> + if (!memcmp(c, "Original Message", 16)) {
> + in_perforation = 1;
> + perforation += 16;
> + scissors += 16;
> + c += 15;
> + continue;
> + }
> in_perforation = 0;
> }
^ permalink raw reply
* RE: [PATCH 2/2] mailinfo: Understand forwarded patches
From: Matthew Wilcox @ 2017-01-12 19:35 UTC (permalink / raw)
To: Jonathan Tan, Matthew Wilcox, git@vger.kernel.org
In-Reply-To: <866bff14-ea25-c644-b8d2-1529f31e6461@google.com>
From: Jonathan Tan [mailto:jonathantanmy@google.com]
> On 01/12/2017 01:20 AM, Matthew Wilcox wrote:
> > From: Matthew Wilcox <mawilcox@microsoft.com>
> >
> > Extend the --scissors mechanism to strip off the preamble created by
> > forwarding a patch. There are a couple of extra headers ("Sent" and
> > "To") added by forwarding, but other than that, the --scissors option
> > will now remove patches forwarded from Microsoft Outlook to a Linux
> > email account.
> >
> > Signed-off-by: Matthew Wilcox <mawilcox@microsoft.com>
>
> Also add a test showing the kind of message that the current code
> doesn't handle, and that this commit addresses.
OK. For the sake of discussion, here's what the base64-decoded message looks like:
--- 8< ---
-----Original Message-----
From: Rehas Sachdeva [mailto:aquannie@gmail.com]
Sent: Wednesday, January 4, 2017 11:55 AM
To: Matthew Wilcox <mawilcox@microsoft.com>; riel@surriel.com
Subject: [PATCH v3] radix tree test suite: Dial down verbosity with -v
Make the output of radix tree test suite less verbose by default and add
-v and -vv command line options for increasing level of verbosity.
--- >8 ---
> > ---
> > mailinfo.c | 9 ++++++++-
> > 1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/mailinfo.c b/mailinfo.c
> > index 2059704a8..fc1275532 100644
> > --- a/mailinfo.c
> > +++ b/mailinfo.c
> > @@ -332,7 +332,7 @@ static void cleanup_subject(struct mailinfo *mi,
> struct strbuf *subject)
> >
> > #define MAX_HDR_PARSED 10
> > static const char *header[MAX_HDR_PARSED] = {
> > - "From","Subject","Date",
> > + "From","Subject","Date","Sent","To",
>
> Are these extra headers used in both the "real" e-mail headers and the
> in-body headers, or only one of them? (If the latter, they should
> probably be handled only in the relevant function - my previous patches
> to this file were in that direction too, if I remember correctly.) Also,
> I suspect that these will have to be handled differently to the other 3,
> but that will be clearer when you add the test with an example message.
Without this part of the patch, using --scissors means it stops parsing headers when it hits the 'Sent' line. So all I'm looking for is to have 'is_inbody_header()' return true. If there's a better way to achieve that, I'm all for it. Without this hunk of the patch, the commit looks like this:
Without any of this patch, the commit looks like this:
Author: Matthew Wilcox <mawilcox@microsoft.com>
Date: Sat Jan 7 18:33:43 2017 +0000
FW: [PATCH v3] radix tree test suite: Dial down verbosity with -v
-----Original Message-----
From: Rehas Sachdeva [mailto:aquannie@gmail.com]
Sent: Wednesday, January 4, 2017 11:55 AM
To: Matthew Wilcox <mawilcox@microsoft.com>; riel@surriel.com
Subject: [PATCH v3] radix tree test suite: Dial down verbosity with -v
Make the output of radix tree test suite less verbose by default and add
-v and -vv command line options for increasing level of verbosity.
Without this hunk of the patch, the commit looks like this:
Author: Rehas Sachdeva <[mailto:aquannie@gmail.com]>
Date: Sat Jan 7 18:33:43 2017 +0000
FW: [PATCH v3] radix tree test suite: Dial down verbosity with -v
Sent: Wednesday, January 4, 2017 11:55 AM
To: Matthew Wilcox <mawilcox@microsoft.com>; riel@surriel.com
Subject: [PATCH v3] radix tree test suite: Dial down verbosity with -v
Make the output of radix tree test suite less verbose by default and add
-v and -vv command line options for increasing level of verbosity.
And with this hunk, it turns into this:
Author: Rehas Sachdeva <[mailto:aquannie@gmail.com]>
Date: Sat Jan 7 18:33:43 2017 +0000
radix tree test suite: Dial down verbosity with -v
Make the output of radix tree test suite less verbose by default and add
-v and -vv command line options for increasing level of verbosity.
There's more work to do here, turning that silly <[mailto:]> into a proper email address, for example, and parsing Sent: like we parse Date:, but I thought it worth sending out patches 1 & 2 before writing patch 3.
> > @@ -685,6 +685,13 @@ static int is_scissors_line(const char *line)
> > c++;
> > continue;
> > }
> > + if (!memcmp(c, "Original Message", 16)) {
>
> 1) You can use starts_with or skip_prefix.
I was following the existing logic in this function that looks for 8< or >8 or ...
> 2) This seems vulnerable to false positives. If "Original Message"
> always follows a certain kind of line, it might be better to check for
> that. (Again, it will be clearer when we have an example message.)
I don't think it's terribly vulnerable to false positives. The logic at the end of the function tries to make sure that the scissor marks make up a substantial component of the line.
We could do this differently; I'm not sure if there's a regex library built into git, but we could even custom-write a separate matcher that looks only for ^-{3,}Original Message-{3,}$
Or we could use a different option; eg --forwarded that will trim off the extra gunk associated with forwarding messages, instead of overloading --scissors.
> > + in_perforation = 1;
> > + perforation += 16;
> > + scissors += 16;
> > + c += 15;
>
> Why 15? Also, can skip_prefix avoid these magic numbers?
Again, following the rest of the function. c has already been advanced by 1, now it needs to be advanced to the end of the 16 character string "Original Message".
^ permalink raw reply
* Re: [PATCH 1/2] asciidoctor: fix user-manual to be built by `asciidoctor`
From: Junio C Hamano @ 2017-01-12 19:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, git, 마누엘
In-Reply-To: <alpine.DEB.2.20.1701121130190.3469@virtualbox>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> And I tend to agree that the silliness you observed (like a t-o-c
>> for a one-section "chapter") is not quite welcome.
>>
>> For now I queued only 2/2 which looked good. I won't object if
>> somebody else rerolls 1/2 to appease AsciiDoctor, but let's take an
>> obviously good bit first.
>
> For fun, I just reverted the article->book patch and I was greeted with
> this:
> ...
> It still builds, funnily enough, but the result is definitely worse on the
> eyes. The page is *really* long, and structuring it into individual parts
> does help the readability.
> ...
> P.S.: I also tried to use [glossary] and [appendix] as appropriate, but it
> seems that AsciiDoc *insists* on level-2 sections in an appendix, while
> AsciiDoctor *insists* on level-3 sections.
So in short, what you are saying is that the support for articles in
AsciiDoctor is borked and totally unusable on an article that needs
to be taken correctly by AsciiDoc, and your conclusion is that the
only way to move forward (other than giving up using AsciiDoctor) is
to avoid writing documents as articles, and existing articles need
to be adjusted to read as books.
If that is the case, then I agree with the conclusion. As I already
said, I won't object to a reroll of 1/2 to make the document format
well with AsciiDoctor without breaking rendering by AsciiDoc too
badly, and your "for fun" experiment illustrated that such a reroll
still needs to avoid using article style. Perhaps 1/2 posted as-is
is the best we could do within that constraint.
Let's queue it on 'pu' and see if somebody else comes up with an
update that is more visually pleasing with both backends.
Thanks.
^ permalink raw reply
* RE: [PATCH 1/2] mailinfo: Add support for keep_cr
From: Matthew Wilcox @ 2017-01-12 19:06 UTC (permalink / raw)
To: Jonathan Tan, Matthew Wilcox, git@vger.kernel.org
In-Reply-To: <8f2be1e9-9199-44af-9d57-41763cb4d666@google.com>
From: Jonathan Tan [mailto:jonathantanmy@google.com]
> On 01/12/2017 01:20 AM, Matthew Wilcox wrote:
> A test exercising the new functionality would be nice.
Roger.
> Also, maybe a more descriptive title like "mailinfo: also respect
> keep_cr after base64 decode" (50 characters) is better.
No problem.
> > @@ -143,6 +144,7 @@ static void am_state_init(struct am_state *state,
> const char *dir)
> >
> > memset(state, 0, sizeof(*state));
> >
> > + state->keep_cr = -1;
>
> Maybe query the git config here (instead of later) so that we never have
> to worry about state->keep_cr being neither 0 nor 1? This function
> already queries the git config anyway.
I wondered why the existing code didn't do that, but I wanted to make a minimal change rather than clean up an older mistake. I'm happy to do it that way.
> > diff --git a/mailinfo.h b/mailinfo.h
> > index 04a25351d..9fddcf684 100644
> > --- a/mailinfo.h
> > +++ b/mailinfo.h
> > @@ -12,6 +12,7 @@ struct mailinfo {
> > struct strbuf email;
> > int keep_subject;
> > int keep_non_patch_brackets_in_subject;
> > + int keep_cr;
> > int add_message_id;
> > int use_scissors;
> > int use_inbody_headers;
>
> I personally would write "unsigned keep_cr : 1" to further emphasize
> that this can only be 0 or 1, but I don't know if it's better to keep
> with the style existing in the file (that is, using int).
Probably best to stick to the existing file ... someone can always do a cleanup patch later, and having this match the others will make that easier, not harder.
Thanks for the review.
^ permalink raw reply
* Re: [PATCH v3 06/38] sequencer (rebase -i): implement the 'edit' command
From: Junio C Hamano @ 2017-01-12 19:00 UTC (permalink / raw)
To: Johannes Schindelin
Cc: git, Kevin Daudt, Dennis Kaarsemaker, Stephan Beyer, Jeff King
In-Reply-To: <736f100f4c219ee5c81e1e7b664128785df80521.1483370556.git.johannes.schindelin@gmx.de>
Johannes Schindelin <johannes.schindelin@gmx.de> writes:
> +static int make_patch(struct commit *commit, struct replay_opts *opts)
> +{
> + struct strbuf buf = STRBUF_INIT;
> + struct rev_info log_tree_opt;
> + const char *subject, *p;
> + int res = 0;
> +
> + p = short_commit_name(commit);
> + if (write_message(p, strlen(p), rebase_path_stopped_sha(), 1) < 0)
> + return -1;
> +
> + strbuf_addf(&buf, "%s/patch", get_dir(opts));
> + memset(&log_tree_opt, 0, sizeof(log_tree_opt));
> + init_revisions(&log_tree_opt, NULL);
> + log_tree_opt.abbrev = 0;
> + log_tree_opt.diff = 1;
> + log_tree_opt.diffopt.output_format = DIFF_FORMAT_PATCH;
> + log_tree_opt.disable_stdin = 1;
> + log_tree_opt.no_commit_id = 1;
> + log_tree_opt.diffopt.file = fopen(buf.buf, "w");
> + log_tree_opt.diffopt.use_color = GIT_COLOR_NEVER;
> + if (!log_tree_opt.diffopt.file)
> + res |= error_errno(_("could not open '%s'"), buf.buf);
> + else {
> + res |= log_tree_commit(&log_tree_opt, commit);
> + fclose(log_tree_opt.diffopt.file);
> + }
> + strbuf_reset(&buf);
> +
> + strbuf_addf(&buf, "%s/message", get_dir(opts));
> + if (!file_exists(buf.buf)) {
> + const char *commit_buffer = get_commit_buffer(commit, NULL);
> + find_commit_subject(commit_buffer, &subject);
> + res |= write_message(subject, strlen(subject), buf.buf, 1);
> + unuse_commit_buffer(commit, commit_buffer);
> + }
> + strbuf_release(&buf);
> +
> + return res;
> +}
Unlike the scripted version, where a merge is shown with "diff --cc"
and a root commit is shown as "Root commit", this only deals with a
single-parent commit. Is this because this helper, at least in its
current form, will not be used by "rebase -m" and not with "--root"?
If that is the case, that is perfectly fine, perhaps that deserves a
mention in the log message and in-code comment before the function.
^ permalink raw reply
* Re: [PATCH v3 02/38] sequencer: move "else" keyword onto the same line as preceding brace
From: Junio C Hamano @ 2017-01-12 18:49 UTC (permalink / raw)
To: Johannes Schindelin
Cc: git, Kevin Daudt, Dennis Kaarsemaker, Stephan Beyer, Jeff King
In-Reply-To: <65e0dac0115713b6ae955acdbc5b7655aeb18e7c.1483370556.git.johannes.schindelin@gmx.de>
Johannes Schindelin <johannes.schindelin@gmx.de> writes:
> It is the current coding style of the Git project to write
>
> if (...) {
> ...
> } else {
> ...
> }
>
> instead of putting the closing brace and the "else" keyword on separate
> lines.
>
> Pointed out by Junio Hamano.
For a small thing like this, the attribution is mostly irrelevant,
but for the record, the credit should go to checkpatch.pl from the
kernel project ;-).
I'll try to squash the part that was touched by 01/38 into this
patch locally; even though I haven't finished going through the
individual patches, I expect that my conclusion would be what I
said in <xmqqinpnuaxl.fsf@gitster.mtv.corp.google.com>, i.e. the
changes in the series are mostly good and improved relative to the
previous round except for the parts reading and writing of
author-script (from the maintainability's point of view).
As I do not think we want to see another reroll of three-dozen
patches, I am leaning towards merging v3 (with minimum fixes like
squashing 01/ and 02/ into one) to 'next' and cook it there and
fix remaining issues incrementally while the series is in 'next'.
I may have to change my mind after I read through the remaining
patches (I've done with the first dozen or so at this moment), but I
do not expect that, judging from what I saw in the interdiff.
Thanks.
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
> sequencer.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/sequencer.c b/sequencer.c
> index 23793db08b..3eededcb98 100644
> --- a/sequencer.c
> +++ b/sequencer.c
> @@ -1070,8 +1070,7 @@ static int create_seq_dir(void)
> error(_("a cherry-pick or revert is already in progress"));
> advise(_("try \"git cherry-pick (--continue | --quit | --abort)\""));
> return -1;
> - }
> - else if (mkdir(git_path_seq_dir(), 0777) < 0)
> + } else if (mkdir(git_path_seq_dir(), 0777) < 0)
> return error_errno(_("could not create sequencer directory '%s'"),
> git_path_seq_dir());
> return 0;
^ permalink raw reply
* Re: [PATCH v3 03/38] sequencer: use a helper to find the commit message
From: Junio C Hamano @ 2017-01-12 18:36 UTC (permalink / raw)
To: Johannes Schindelin
Cc: git, Kevin Daudt, Dennis Kaarsemaker, Stephan Beyer, Jeff King
In-Reply-To: <780d71b5844b526a850ac9b76d36b764b2580efd.1483370556.git.johannes.schindelin@gmx.de>
Johannes Schindelin <johannes.schindelin@gmx.de> writes:
> It is actually not safe to look for a commit message by looking for the
> first empty line and skipping it.
>
> The find_commit_subject() function looks more carefully, so let's use
> it. Since we are interested in the entire commit message, we re-compute
> the string length after verifying that the commit subject is not empty
> (in which case the entire commit message would be empty, something that
> should not happen but that we want to handle gracefully).
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
Very sensible.
> sequencer.c | 11 +++--------
> 1 file changed, 3 insertions(+), 8 deletions(-)
>
> diff --git a/sequencer.c b/sequencer.c
> index 3eededcb98..720857beda 100644
> --- a/sequencer.c
> +++ b/sequencer.c
> @@ -703,14 +703,9 @@ static int do_pick_commit(enum todo_command command, struct commit *commit,
> next = commit;
> next_label = msg.label;
>
> - /*
> - * Append the commit log message to msgbuf; it starts
> - * after the tree, parent, author, committer
> - * information followed by "\n\n".
> - */
> - p = strstr(msg.message, "\n\n");
> - if (p)
> - strbuf_addstr(&msgbuf, skip_blank_lines(p + 2));
> + /* Append the commit log message to msgbuf. */
> + if (find_commit_subject(msg.message, &p))
> + strbuf_addstr(&msgbuf, p);
>
> if (opts->record_origin) {
> if (!has_conforming_footer(&msgbuf, NULL, 0))
^ permalink raw reply
* Re: [PATCH v3 01/38] sequencer: avoid unnecessary curly braces
From: Junio C Hamano @ 2017-01-12 18:35 UTC (permalink / raw)
To: Johannes Schindelin
Cc: git, Kevin Daudt, Dennis Kaarsemaker, Stephan Beyer, Jeff King
In-Reply-To: <bc1a6c21c9ab2f55882c363e802bfcf37e49d79f.1483370556.git.johannes.schindelin@gmx.de>
Johannes Schindelin <johannes.schindelin@gmx.de> writes:
>
> - if (!commit->parents) {
> + if (!commit->parents)
> parent = NULL;
> - }
> else if (commit->parents->next) {
> /* Reverting or cherry-picking a merge commit */
> int cnt;
The result becomes
if (...)
single statement;
else if (...) {
multiple;
statements;
}
which is not quite an improvement.
The preferred style is for all arms in if/elseif/else cascade to
either use or not use brace pairs, so I think a fix toward that goal
would be more like:
if (!commit->parents) {
parent = NULL;
- }
- else if (commit->parents->next) {
+ } else if (commit->parents->next) {
/* Reverting ...
^ permalink raw reply
* Re: Bug report: Git pull hang occasionally
From: Kai Zhang @ 2017-01-12 18:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqqshphge7o.fsf@gitster.mtv.corp.google.com>
Hi Junio,
After apply this patch, hanging did not happen again. Would this patch go to release in near future?
Thanks.
Regards,
Kai
> On Dec 21, 2016, at 1:32 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> Junio C Hamano <gitster@pobox.com> writes:
>
>> And the unexpected discrepancy is reported by find_symref() as
>> fatal. The server side dies, and somehow that fact is lost between
>> the upload-pack process and the client and somebody in the middle
>> (e.g. fastcgi interface or nginx webserver on the server side, or
>> the remote-curl helper on the client side) keeps the "git fetch"
>> process waiting.
>>
>> So there seem to be two issues.
>>
>> - Because of the unlocked read, find_symref() can observe an
>> inconsistent state. Perhaps it should be updated not to die but
>> to retry, expecting that transient inconsistency will go away.
>>
>> - A fatal error in upload-pack is not reported back to the client
>> to cause it exit is an obvious one, and even if we find a way to
>> make this fatal error in find_symref() not to trigger, fatal
>> errors in other places in the code can trigger the same symptom.
>
> I wonder if the latter is solved by recent patch 296b847c0d
> ("remote-curl: don't hang when a server dies before any output",
> 2016-11-18) on the client side.
>
> -- >8 --
> From: David Turner <dturner@twosigma.com>
> Date: Fri, 18 Nov 2016 15:30:49 -0500
> Subject: [PATCH] remote-curl: don't hang when a server dies before any output
>
> In the event that a HTTP server closes the connection after giving a
> 200 but before giving any packets, we don't want to hang forever
> waiting for a response that will never come. Instead, we should die
> immediately.
>
> One case where this happens is when attempting to fetch a dangling
> object by its object name. In this case, the server dies before
> sending any data. Prior to this patch, fetch-pack would wait for
> data from the server, and remote-curl would wait for fetch-pack,
> causing a deadlock.
>
> Despite this patch, there is other possible malformed input that could
> cause the same deadlock (e.g. a half-finished pktline, or a pktline but
> no trailing flush). There are a few possible solutions to this:
>
> 1. Allowing remote-curl to tell fetch-pack about the EOF (so that
> fetch-pack could know that no more data is coming until it says
> something else). This is tricky because an out-of-band signal would
> be required, or the http response would have to be re-framed inside
> another layer of pkt-line or something.
>
> 2. Make remote-curl understand some of the protocol. It turns out
> that in addition to understanding pkt-line, it would need to watch for
> ack/nak. This is somewhat fragile, as information about the protocol
> would end up in two places. Also, pkt-lines which are already at the
> length limit would need special handling.
>
> Both of these solutions would require a fair amount of work, whereas
> this hack is easy and solves at least some of the problem.
>
> Still to do: it would be good to give a better error message
> than "fatal: The remote end hung up unexpectedly".
>
> Signed-off-by: David Turner <dturner@twosigma.com>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> remote-curl.c | 8 ++++++++
> t/t5551-http-fetch-smart.sh | 30 ++++++++++++++++++++++++++++++
> 2 files changed, 38 insertions(+)
>
> diff --git a/remote-curl.c b/remote-curl.c
> index f14c41f4c0..ee4423659f 100644
> --- a/remote-curl.c
> +++ b/remote-curl.c
> @@ -400,6 +400,7 @@ struct rpc_state {
> size_t pos;
> int in;
> int out;
> + int any_written;
> struct strbuf result;
> unsigned gzip_request : 1;
> unsigned initial_buffer : 1;
> @@ -456,6 +457,8 @@ static size_t rpc_in(char *ptr, size_t eltsize,
> {
> size_t size = eltsize * nmemb;
> struct rpc_state *rpc = buffer_;
> + if (size)
> + rpc->any_written = 1;
> write_or_die(rpc->in, ptr, size);
> return size;
> }
> @@ -659,6 +662,8 @@ static int post_rpc(struct rpc_state *rpc)
> curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, rpc_in);
> curl_easy_setopt(slot->curl, CURLOPT_FILE, rpc);
>
> +
> + rpc->any_written = 0;
> err = run_slot(slot, NULL);
> if (err == HTTP_REAUTH && !large_request) {
> credential_fill(&http_auth);
> @@ -667,6 +672,9 @@ static int post_rpc(struct rpc_state *rpc)
> if (err != HTTP_OK)
> err = -1;
>
> + if (!rpc->any_written)
> + err = -1;
> +
> curl_slist_free_all(headers);
> free(gzip_body);
> return err;
> diff --git a/t/t5551-http-fetch-smart.sh b/t/t5551-http-fetch-smart.sh
> index 1ec5b2747a..43665ab4a8 100755
> --- a/t/t5551-http-fetch-smart.sh
> +++ b/t/t5551-http-fetch-smart.sh
> @@ -276,6 +276,36 @@ test_expect_success 'large fetch-pack requests can be split across POSTs' '
> test_line_count = 2 posts
> '
>
> +test_expect_success 'test allowreachablesha1inwant' '
> + test_when_finished "rm -rf test_reachable.git" &&
> + server="$HTTPD_DOCUMENT_ROOT_PATH/repo.git" &&
> + master_sha=$(git -C "$server" rev-parse refs/heads/master) &&
> + git -C "$server" config uploadpack.allowreachablesha1inwant 1 &&
> +
> + git init --bare test_reachable.git &&
> + git -C test_reachable.git remote add origin "$HTTPD_URL/smart/repo.git" &&
> + git -C test_reachable.git fetch origin "$master_sha"
> +'
> +
> +test_expect_success 'test allowreachablesha1inwant with unreachable' '
> + test_when_finished "rm -rf test_reachable.git; git reset --hard $(git rev-parse HEAD)" &&
> +
> + #create unreachable sha
> + echo content >file2 &&
> + git add file2 &&
> + git commit -m two &&
> + git push public HEAD:refs/heads/doomed &&
> + git push public :refs/heads/doomed &&
> +
> + server="$HTTPD_DOCUMENT_ROOT_PATH/repo.git" &&
> + master_sha=$(git -C "$server" rev-parse refs/heads/master) &&
> + git -C "$server" config uploadpack.allowreachablesha1inwant 1 &&
> +
> + git init --bare test_reachable.git &&
> + git -C test_reachable.git remote add origin "$HTTPD_URL/smart/repo.git" &&
> + test_must_fail git -C test_reachable.git fetch origin "$(git rev-parse HEAD)"
> +'
> +
> test_expect_success EXPENSIVE 'http can handle enormous ref negotiation' '
> (
> cd "$HTTPD_DOCUMENT_ROOT_PATH/repo.git" &&
> --
> 2.11.0-442-g0c85c54a77
^ permalink raw reply
* Re: [PATCH 2/2] mailinfo: Understand forwarded patches
From: Jonathan Tan @ 2017-01-12 18:17 UTC (permalink / raw)
To: Matthew Wilcox, git; +Cc: Matthew Wilcox
In-Reply-To: <1484212824-14108-2-git-send-email-mawilcox@linuxonhyperv.com>
On 01/12/2017 01:20 AM, Matthew Wilcox wrote:
> From: Matthew Wilcox <mawilcox@microsoft.com>
>
> Extend the --scissors mechanism to strip off the preamble created by
> forwarding a patch. There are a couple of extra headers ("Sent" and
> "To") added by forwarding, but other than that, the --scissors option
> will now remove patches forwarded from Microsoft Outlook to a Linux
> email account.
>
> Signed-off-by: Matthew Wilcox <mawilcox@microsoft.com>
Also add a test showing the kind of message that the current code
doesn't handle, and that this commit addresses.
> ---
> mailinfo.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/mailinfo.c b/mailinfo.c
> index 2059704a8..fc1275532 100644
> --- a/mailinfo.c
> +++ b/mailinfo.c
> @@ -332,7 +332,7 @@ static void cleanup_subject(struct mailinfo *mi, struct strbuf *subject)
>
> #define MAX_HDR_PARSED 10
> static const char *header[MAX_HDR_PARSED] = {
> - "From","Subject","Date",
> + "From","Subject","Date","Sent","To",
Are these extra headers used in both the "real" e-mail headers and the
in-body headers, or only one of them? (If the latter, they should
probably be handled only in the relevant function - my previous patches
to this file were in that direction too, if I remember correctly.) Also,
I suspect that these will have to be handled differently to the other 3,
but that will be clearer when you add the test with an example message.
> };
>
> static inline int cmp_header(const struct strbuf *line, const char *hdr)
> @@ -685,6 +685,13 @@ static int is_scissors_line(const char *line)
> c++;
> continue;
> }
> + if (!memcmp(c, "Original Message", 16)) {
1) You can use starts_with or skip_prefix.
2) This seems vulnerable to false positives. If "Original Message"
always follows a certain kind of line, it might be better to check for
that. (Again, it will be clearer when we have an example message.)
> + in_perforation = 1;
> + perforation += 16;
> + scissors += 16;
> + c += 15;
Why 15? Also, can skip_prefix avoid these magic numbers?
> + continue;
> + }
> in_perforation = 0;
> }
>
>
^ permalink raw reply
* Re: [PATCH 1/2] mailinfo: Add support for keep_cr
From: Jonathan Tan @ 2017-01-12 18:04 UTC (permalink / raw)
To: Matthew Wilcox, git; +Cc: Matthew Wilcox
In-Reply-To: <1484212824-14108-1-git-send-email-mawilcox@linuxonhyperv.com>
On 01/12/2017 01:20 AM, Matthew Wilcox wrote:
> From: Matthew Wilcox <mawilcox@microsoft.com>
>
> If you have a base-64 encoded patch with CRLF endings (as produced
> by forwarding a patch from Outlook to a Linux machine, for example),
> the keep_cr setting is not honoured because keep_cr is only passed
> to mailsplit, which does not look through the encoding. The keep_cr
> logic needs to be applied after the base64 decode. I copied that
> logic to handle_filter(), and rather than add a new keep_cr parameter
> to handle_filter, I opted to add keep_cr to struct mailinfo; it seemed
> appropriate given use_scissors was already there.
>
> Then I needed to initialise keep_cr in the struct mailinfo passed from
> git-am, and rather than thread a 'keep_cr' parameter all the way through
> to parse_mail(), I decided to add keep_cr to struct am_state, which let
> it be removed as a parameter from five other functions.
>
> Signed-off-by: Matthew Wilcox <mawilcox@microsoft.com>
A test exercising the new functionality would be nice.
Also, maybe a more descriptive title like "mailinfo: also respect
keep_cr after base64 decode" (50 characters) is better.
> @@ -143,6 +144,7 @@ static void am_state_init(struct am_state *state, const char *dir)
>
> memset(state, 0, sizeof(*state));
>
> + state->keep_cr = -1;
Maybe query the git config here (instead of later) so that we never have
to worry about state->keep_cr being neither 0 nor 1? This function
already queries the git config anyway.
> diff --git a/mailinfo.h b/mailinfo.h
> index 04a25351d..9fddcf684 100644
> --- a/mailinfo.h
> +++ b/mailinfo.h
> @@ -12,6 +12,7 @@ struct mailinfo {
> struct strbuf email;
> int keep_subject;
> int keep_non_patch_brackets_in_subject;
> + int keep_cr;
> int add_message_id;
> int use_scissors;
> int use_inbody_headers;
I personally would write "unsigned keep_cr : 1" to further emphasize
that this can only be 0 or 1, but I don't know if it's better to keep
with the style existing in the file (that is, using int).
^ permalink raw reply
* Re: [PATCH] imap-send.c: Avoid deprecated openssl 1.1.0 API
From: Jack Bates @ 2017-01-12 16:55 UTC (permalink / raw)
To: eroen, git
In-Reply-To: <20170112104219.563497-1-git-scm@occam.eroen.eu>
You might need the following, to still build with LibreSSL.
That was my experience anyway, when I recently prepared similar fixes
for OpenSSL 1.1 and Apache Traffic Server.
#if OPENSSL_VERSION_NUMBER < 0x10100000L || defined(LIBRESSL_VERSION_NUMBER)
On 12/01/17 03:42 AM, eroen wrote:
> Library initialization functions are deprecated in openssl 1.1.0 API, as
> initialization is handled by openssl internally.
>
> Symbols for deprecated functions are not exported if openssl is built with
> `--api=1.1 disable-deprecated`, so their use will cause a build failure.
>
> Reported-by: Lars Wendler (Polynomial-C)
>
> X-Gentoo-Bug: 592466
> X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=592466
> ---
> imap-send.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/imap-send.c b/imap-send.c
> index 5c7e27a89..98774360e 100644
> --- a/imap-send.c
> +++ b/imap-send.c
> @@ -284,8 +284,10 @@ static int ssl_socket_connect(struct imap_socket *sock, int use_tls_only, int ve
> int ret;
> X509 *cert;
>
> +#if OPENSSL_VERSION_NUMBER < 0x10100000L
> SSL_library_init();
> SSL_load_error_strings();
> +#endif
>
> meth = SSLv23_method();
> if (!meth) {
>
^ permalink raw reply
* Re: [PATCH] imap-send.c: Avoid deprecated openssl 1.1.0 API
From: Jack Bates @ 2017-01-12 16:53 UTC (permalink / raw)
To: git
In-Reply-To: <20170112104219.563497-1-git-scm@occam.eroen.eu>
You might need the following, to still build with LibreSSL.
That was my experience anyway, when I recently prepared similar fixes
for OpenSSL 1.1 and Apache Traffic Server.
#if OPENSSL_VERSION_NUMBER < 0x10100000L || defined(LIBRESSL_VERSION_NUMBER)
On 12/01/17 03:42 AM, eroen wrote:
> Library initialization functions are deprecated in openssl 1.1.0 API, as
> initialization is handled by openssl internally.
>
> Symbols for deprecated functions are not exported if openssl is built with
> `--api=1.1 disable-deprecated`, so their use will cause a build failure.
>
> Reported-by: Lars Wendler (Polynomial-C)
>
> X-Gentoo-Bug: 592466
> X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=592466
> ---
> imap-send.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/imap-send.c b/imap-send.c
> index 5c7e27a89..98774360e 100644
> --- a/imap-send.c
> +++ b/imap-send.c
> @@ -284,8 +284,10 @@ static int ssl_socket_connect(struct imap_socket *sock, int use_tls_only, int ve
> int ret;
> X509 *cert;
>
> +#if OPENSSL_VERSION_NUMBER < 0x10100000L
> SSL_library_init();
> SSL_load_error_strings();
> +#endif
>
> meth = SSLv23_method();
> if (!meth) {
>
^ permalink raw reply
* problem with insider build for windows and git
From: Michael Gooch @ 2017-01-12 16:21 UTC (permalink / raw)
To: git
when running commands like pull and clone I get the following message:
Cygwin WARNING:
Couldn't compute FAST_CWD pointer. This typically occurs if you're using
an older Cygwin version on a newer Windows. Please update to the latest
available Cygwin version from https://cygwin.com/. If the problem
persists,
please see https://cygwin.com/problems.html
Windows build is version 1607, OS BUILD 15002.1001
I assume they broke something that cygwin was depending on.
^ permalink raw reply
* Re: [PATCH 5/5] describe: teach describe negative pattern matches
From: Johannes Sixt @ 2017-01-12 13:45 UTC (permalink / raw)
To: Jacob Keller; +Cc: git, Jacob Keller
In-Reply-To: <20170112001721.2534-6-jacob.e.keller@intel.com>
Am 12.01.2017 um 01:17 schrieb Jacob Keller:
> From: Jacob Keller <jacob.keller@gmail.com>
>
> Teach git-describe the `--discard` option which will allow specifying
> a glob pattern of tags to ignore. This can be combined with the
> `--match` patterns to enable more flexibility in determining which tags
> to consider.
>
> For example, suppose you wish to find the first official release tag
> that contains a certain commit. If we assume that official release tags
> are of the form "v*" and pre-release candidates include "*rc*" in their
> name, we can now find the first tag that introduces commit abcdef via:
>
> git describe --contains --match="v*" --discard="*rc*"
I have a few dozen topic branches, many of them are work in progress and
named wip/something. To see the completed branches, I routinely say
gitk --exclude=wip/* --branches
these days.
It would be great if you could provide the same user interface here. The
example in the commit message would then look like this:
git describe --contains --exclude="*rc*" --match="v*"
(I'm not saying that you should add --branches, but that you should
prefer --exclude over --discard. Also, the order of --exclude and
--match would be important.)
-- Hannes
^ permalink raw reply
* [PATCH v2] diff: add interhunk context config option
From: Vegard Nossum @ 2017-01-12 12:21 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: Vegard Nossum, René Scharfe, Pranit Bauva
The --inter-hunk-context= option was added in commit 6d0e674a5754
("diff: add option to show context between close hunks"). This patch
allows configuring a default for this option.
Cc: René Scharfe <l.s.r@web.de>
Cc: Pranit Bauva <pranit.bauva@gmail.com>
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
---
v2:
- Update Documentation/diff-config.txt, suggested by Pranit Bauva.
- Add tests, suggested by Pranit Bauva.
- Don't initialize BSS variable to 0, suggested by Junio Hamano.
- Junio: if git_config_int() fails, you will get something like:
"fatal: bad config variable 'diff.interhunkcontext' in file '/home/vegard/.gitconfig' at line 5"
---
Documentation/diff-config.txt | 6 ++++++
Documentation/diff-options.txt | 2 ++
diff.c | 8 ++++++++
t/t4032-diff-inter-hunk-context.sh | 27 ++++++++++++++++++++++++++-
4 files changed, 42 insertions(+), 1 deletion(-)
diff --git a/Documentation/diff-config.txt b/Documentation/diff-config.txt
index 58f4bd6..d8cd854 100644
--- a/Documentation/diff-config.txt
+++ b/Documentation/diff-config.txt
@@ -60,6 +60,12 @@ diff.context::
Generate diffs with <n> lines of context instead of the default
of 3. This value is overridden by the -U option.
+diff.interHunkContext::
+ Show the context between diff hunks, up to <n> lines, thereby
+ fusing the hunks that are close to each other. The default is 0,
+ meaning no fusing will occur. This value is overridden by the
+ --inter-hunk-context option.
+
diff.external::
If this config variable is set, diff generation is not
performed using the internal diff machinery, but using the
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index e6215c3..a219aa2 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -511,6 +511,8 @@ endif::git-format-patch[]
--inter-hunk-context=<lines>::
Show the context between diff hunks, up to the specified number
of lines, thereby fusing hunks that are close to each other.
+ Defaults to `diff.interHunkContext` or 0 if the config option
+ is unset.
-W::
--function-context::
diff --git a/diff.c b/diff.c
index 84dba60..a92080c 100644
--- a/diff.c
+++ b/diff.c
@@ -33,6 +33,7 @@ static int diff_rename_limit_default = 400;
static int diff_suppress_blank_empty;
static int diff_use_color_default = -1;
static int diff_context_default = 3;
+static int diff_interhunk_context_default;
static const char *diff_word_regex_cfg;
static const char *external_diff_cmd_cfg;
static const char *diff_order_file_cfg;
@@ -248,6 +249,12 @@ int git_diff_ui_config(const char *var, const char *value, void *cb)
return -1;
return 0;
}
+ if (!strcmp(var, "diff.interhunkcontext")) {
+ diff_interhunk_context_default = git_config_int(var, value);
+ if (diff_interhunk_context_default < 0)
+ return -1;
+ return 0;
+ }
if (!strcmp(var, "diff.renames")) {
diff_detect_rename_default = git_config_rename(var, value);
return 0;
@@ -3371,6 +3378,7 @@ void diff_setup(struct diff_options *options)
options->rename_limit = -1;
options->dirstat_permille = diff_dirstat_permille_default;
options->context = diff_context_default;
+ options->interhunkcontext = diff_interhunk_context_default;
options->ws_error_highlight = ws_error_highlight_default;
DIFF_OPT_SET(options, RENAME_EMPTY);
diff --git a/t/t4032-diff-inter-hunk-context.sh b/t/t4032-diff-inter-hunk-context.sh
index e4e3e28..d9ac9d1 100755
--- a/t/t4032-diff-inter-hunk-context.sh
+++ b/t/t4032-diff-inter-hunk-context.sh
@@ -16,11 +16,15 @@ f() {
}
t() {
+ use_config=""
+ git config --unset diff.interHunkContext
+
case $# in
4) hunks=$4; cmd="diff -U$3";;
5) hunks=$5; cmd="diff -U$3 --inter-hunk-context=$4";;
+ 6) hunks=$5; cmd="diff -U$3"; git config diff.interHunkContext $4; use_config="(diff.interHunkContext=$4) ";;
esac
- label="$cmd, $1 common $2"
+ label="$use_config$cmd, $1 common $2"
file=f$1
expected=expected.$file.$3.$hunks
@@ -89,4 +93,25 @@ t 9 lines 3 2
t 9 lines 3 2 2
t 9 lines 3 3 1
+# use diff.interHunkContext?
+t 1 line 0 0 2 config
+t 1 line 0 1 1 config
+t 1 line 0 2 1 config
+t 9 lines 3 3 1 config
+t 2 lines 0 0 2 config
+t 2 lines 0 1 2 config
+t 2 lines 0 2 1 config
+t 3 lines 1 0 2 config
+t 3 lines 1 1 1 config
+t 3 lines 1 2 1 config
+t 9 lines 3 2 2 config
+t 9 lines 3 3 1 config
+
+test_expect_success 'diff.interHunkContext invalid' '
+ git config diff.interHunkContext asdf &&
+ test_must_fail git diff &&
+ git config diff.interHunkContext -1 &&
+ test_must_fail git diff
+'
+
test_done
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v4] log --graph: customize the graph lines with config log.graphColors
From: Duy Nguyen @ 2017-01-12 12:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King
In-Reply-To: <xmqqh958uoot.fsf@gitster.mtv.corp.google.com>
Just FYI. The broken internet cables in Vietnam seem to hit my ISP
really hard. It's nearly impossible to make a TCP connection. So I'm
basically off the grid, hopefully not longer than two weeks.
On 1/10/17, Junio C Hamano <gitster@pobox.com> wrote:
> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>
>> + end = string + strlen(string);
>> + while (start < end) {
>> + const char *comma = strchrnul(start, ',');
>> + char color[COLOR_MAXLEN];
>> +
>> + while (start < comma && isspace(*start))
>> + start++;
>> + if (start == comma) {
>> + start = comma + 1;
>> + continue;
>> + }
>> +
>> + if (!color_parse_mem(start, comma - start, color))
>
> So you skip the leading blanks but let color_parse_mem() trim the
> trailing blanks? It would work once the control reaches the loop,
> but wouldn't that miss
>
> git -c log.graphColors=' reset , blue, red' log --graph
>
> as "reset" is not
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox