[PATCH v2 2/2] builtin/config.c: prefer `--type=bool` over `--bool`, etc.

`git config` has long allowed the ability for callers to provide a 'type specifier', which instructs `git config` to (1) ensure that incoming values are satisfiable under that type, and (2) that outgoing values are canonicalized under that type. In another series, we propose to add extend this

[PATCH v2 1/2] builtin/config.c: treat type specifiers singularly

Internally, we represent `git config`'s type specifiers as a bitset using OPT_BIT. 'bool' is 1<<0, 'int' is 1<<1, and so on. This technique allows for the representation of multiple type specifiers in the `int types` field, but this multi-representation is left unused. In fact, `git config` will

Re: [PATCH] builtin/config.c: prefer `--type=bool` over `--bool`, etc.

On Thu, Mar 29, 2018 at 06:11:22PM -0400, Jeff King wrote: > > +Valid `[type]`'s include: > > ++ > > +- 'bool': canonicalize values as either "true" or "false". > > +- 'int': canonicalize values as simple decimla numbers. An optional > > suffix of > > + 'k', 'm', or 'g' will cause the value to

Re: [RFC/PATCH] upload-pack: disable object filtering when disabled by config

Junio C Hamano writes: > Jeff King writes: > >> I think I'd agree on it being a release blocker. Given that your fix is >> really a one-liner (3 of the lines are just changing the variable name, >> which I agree with), I'd be fine with applying it on top rather

Re: [PATCH v6 0/6] ref-filter: remove die() calls from formatting logic

On Thu, Mar 29, 2018 at 10:41 AM, Christian Couder wrote: > On Thu, Mar 29, 2018 at 2:52 PM, Оля Тележная > wrote: >> Move helper function from strbuf to ref-filter. >> Get rid of some memory leaks. > > The above seems to be the changes

Hello Dear.

Hello Dear I am Mrs Roseline Jacque 52 years old, from America (California), i am suffering from long time illness cancer for years, I and my husband was dealing on Gold Exportation in Burkina Faso till his sudden death the year 2008 then I took over the business till date. In fact, at this

Re: [RFC PATCH v2] git-submodule.sh:cmd_update: if submodule branch exists, fetch that instead of default

(+list) 2018-03-30 1:55 GMT+03:00 : > From: Eddy Petrișor > > There are projects such as llvm/clang which use several repositories, and they > might be forked for providing support for various features such as adding > Redox > awareness to the

Re: [PATCH] credential: ignore SIGPIPE when writing to credential helpers

Jeff King writes: > On Thu, Mar 29, 2018 at 11:00:56AM -0700, Erik E Brady wrote: > >> The credential subsystem can trigger SIGPIPE when writing to an >> external helper if that helper closes its stdin before reading the >> whole input. Normally this is rare, since helpers would

Re: [RFC/PATCH] upload-pack: disable object filtering when disabled by config

Jeff King writes: > I think I'd agree on it being a release blocker. Given that your fix is > really a one-liner (3 of the lines are just changing the variable name, > which I agree with), I'd be fine with applying it on top rather than > reverting the original, even if it means

Re: [PATCH] credential: ignore SIGPIPE when writing to credential helpers

On Thu, Mar 29, 2018 at 10:20:40PM +, Erik Brady -X (brady - ROBERT HALF INTERNATIONAL INC at Cisco) wrote: > I appreciate your time. Quick Q... is there a way to track the patch > through to release? If not I can just scan release notes/etc so no > worries. When the maintainer picks up

from Aziz Dake

Attn: Sir/Madam, I am Mr. Aziz Dake, a Minister confide on me to look for foreign partner who will assist him to invest the sum of Thirty Million Dollars ($30,000,000) in your country. He has investment interest in mining, exotic properties for commercial resident, development properties,

Re: [PATCH] credential: ignore SIGPIPE when writing to credential helpers

Thanks Jeff. I appreciate your time. Quick Q... is there a way to track the patch through to release? If not I can just scan release notes/etc so no worries. Cheers, Erik On 3/29/18, 2:51 PM, "Jeff King" wrote: On Thu, Mar 29, 2018 at 11:00:56AM -0700, Erik E Brady

Re: [RFC/PATCH] upload-pack: disable object filtering when disabled by config

On Thu, Mar 29, 2018 at 03:03:54PM -0700, Jonathan Nieder wrote: > Jeff King wrote: > > On Wed, Mar 28, 2018 at 01:33:03PM -0700, Jonathan Nieder wrote: > > >> When upload-pack gained partial clone support (v2.17.0-rc0~132^2~12, > >> 2017-12-08), it was guarded by the uploadpack.allowFilter

Re: [PATCH] builtin/config.c: prefer `--type=bool` over `--bool`, etc.

On Wed, Mar 28, 2018 at 04:47:19PM -0700, Taylor Blau wrote: > `git config` has long allowed the ability for callers to provide a 'type > specifier', which instructs `git config` to (1) ensure that incoming > values are satisfiable under that type, and (2) that outgoing values are > canonicalized

Re: [RFC/PATCH] upload-pack: disable object filtering when disabled by config

Jeff King wrote: > On Wed, Mar 28, 2018 at 01:33:03PM -0700, Jonathan Nieder wrote: >> When upload-pack gained partial clone support (v2.17.0-rc0~132^2~12, >> 2017-12-08), it was guarded by the uploadpack.allowFilter config item >> to allow server operators to control when they start supporting

Re: [RFC/PATCH] upload-pack: disable object filtering when disabled by config

On Wed, Mar 28, 2018 at 01:33:03PM -0700, Jonathan Nieder wrote: > When upload-pack gained partial clone support (v2.17.0-rc0~132^2~12, > 2017-12-08), it was guarded by the uploadpack.allowFilter config item > to allow server operators to control when they start supporting it. > > That config

Re: [PATCH] credential: ignore SIGPIPE when writing to credential helpers

On Thu, Mar 29, 2018 at 11:00:56AM -0700, Erik E Brady wrote: > The credential subsystem can trigger SIGPIPE when writing to an > external helper if that helper closes its stdin before reading the > whole input. Normally this is rare, since helpers would need to read > that input to make a

Re: [PATCH 9/9] git_config_set: reuse empty sections

On Thu, Mar 29, 2018 at 05:19:09PM +0200, Johannes Schindelin wrote: > It can happen quite easily that the last setting in a config section is > removed, and to avoid confusion when there are comments in the config > about that section, we keep a lone section header, i.e. an empty > section. > >

Re: [PATCH 8/9] git_config_set: use do_config_from_file() directly

On Thu, Mar 29, 2018 at 05:19:04PM +0200, Johannes Schindelin wrote: > Technically, it is the git_config_set_multivar_in_file_gently() > function that we modify here (but the oneline would get too long if we > were that precise). > > This change prepares the git_config_set machinery to allow

Re: [PATCH 7/9] git config --unset: remove empty sections (in normal situations)

On Thu, Mar 29, 2018 at 05:19:00PM +0200, Johannes Schindelin wrote: > Let's generalize this observation to this conservative strategy: if we > are removing the last entry from a section, and there are no comments > inside that section nor surrounding it, then remove the entire section. >

Fwd: [RFC PATCH] git-submodule.sh:cmd_update: if submodule branch exists, fetch that instead of default

mar., 27 mar. 2018, 02:07 Stefan Beller a scris: > > [snipped the cc list as well] > > On Tue, Mar 6, 2018 at 12:06 PM Eddy Petrișor > wrote: > > > Signed-off-by: Eddy Petrișor > > --- > > Did this go anywhere? > (I just came

Re: [PATCH 4/9] t1300: remove unreasonable expectation from TODO

Jeff King writes: > An obvious question is whether we should preserve the original > unrealistic parts by splitting it: the realistic parts into one > expect_failure (that we'd switch to expect_success by the end of this > series), and then an unrealistic one to serve as a

Re: [PATCH v4] Allow use of TLS 1.3

Loganaden Velvindron writes: > diff --git a/http.c b/http.c > index a5bd5d62c..f84b18551 100644 > --- a/http.c > +++ b/http.c > @@ -62,6 +62,9 @@ static struct { > { "tlsv1.1", CURL_SSLVERSION_TLSv1_1 }, > { "tlsv1.2", CURL_SSLVERSION_TLSv1_2 }, > #endif > +#if

Re: [PATCH] builtin/config.c: prefer `--type=bool` over `--bool`, etc.

Taylor Blau writes: > `git config` has long allowed the ability for callers to provide a 'type > specifier', which instructs `git config` to (1) ensure that incoming > values are satisfiable under that type, and (2) that outgoing values are > canonicalized under that type. > >

Re: [PATCH v4 2/5] stash: convert apply to builtin

Joel Teichroeb writes: > +static int get_stash_info(struct stash_info *info, int argc, const char > **argv) > +{ So, this roughly corresponds to parse_flags_and_rev function, it seems. > + struct strbuf w_commit_rev = STRBUF_INIT; > + struct strbuf b_commit_rev =

Re: [PATCH 5/9] t1300: `--unset-all` can leave an empty section behind (bug)

On Thu, Mar 29, 2018 at 05:18:53PM +0200, Johannes Schindelin wrote: > We already have a test demonstrating that removing the last entry from a > config section fails to remove the section header of the now-empty > section. > > The same can happen, of course, if we remove the last entries in one

Re: [PATCH 4/9] t1300: remove unreasonable expectation from TODO

On Thu, Mar 29, 2018 at 05:18:50PM +0200, Johannes Schindelin wrote: > In https://public-inbox.org/git/7vvc8alzat@alter.siamese.dyndns.org/ > a reasonable patch was made quite a bit less so by changing a test case > demonstrating a bug to a test case that demonstrates that we ask for too >

Re: [PATCH 3/9] t1300: avoid relying on a bug

On Thu, Mar 29, 2018 at 05:18:45PM +0200, Johannes Schindelin wrote: > The test case 'unset with cont. lines' relied on a bug that is about to > be fixed: it tests *explicitly* that removing the last entry from a > config section leaves an *empty* section behind. > > Let's fix this test case not

Re: [PATCH 2/9] t1300: rename it to reflect that `repo-config` was deprecated

On Thu, Mar 29, 2018 at 05:18:40PM +0200, Johannes Schindelin wrote: > Signed-off-by: Johannes Schindelin > --- > t/{t1300-repo-config.sh => t1300-config.sh} | 0 > 1 file changed, 0 insertions(+), 0 deletions(-) > rename t/{t1300-repo-config.sh => t1300-config.sh}

Re: [PATCH 1/9] git_config_set: fix off-by-two

On Thu, Mar 29, 2018 at 11:15:33AM -0700, Stefan Beller wrote: > > When calling `git config --unset abc.a` on this file, it leaves this > > (invalid) config behind: > > > > [ > > [xyz] > > key = value > > > > The reason is that we try to search for the beginning of

Re: [PATCH v4 1/5] stash: improve option parsing test coverage

Joel Teichroeb writes: > In preparation for converting the stash command incrementally to > a builtin command, this patch improves test coverage of the option > parsing. Both for having too many paramerters, or too few. > > Signed-off-by: Joel Teichroeb >

Re: [PATCH 0/9] Assorted fixes for `git config` (including the "empty sections" bug)

On Thu, Mar 29, 2018 at 05:18:30PM +0200, Johannes Schindelin wrote: > Little did I know that this would turn not only into a full patch to fix this > issue, but into a full-blown series of nine patches. It's amazing how often that happens. :) > The first patch is somewhat of a "while at it"

Re: [PATCH v12 00/10] convert: add support for different encodings

lars.schnei...@autodesk.com writes: > From: Lars Schneider > > Patches 1-6,9 are preparation and helper functions. Patch 4 is new. > Patch 7,8,10 are the actual change. > > This series depends on Torsten's 8462ff43e4 (convert_to_git(): > safe_crlf/checksafe becomes int

Re: [PATCH v3 0/3] add -p: select individual hunk lines

Phillip Wood writes: > From: Phillip Wood > > Since v2 I've updated the patches to use '-' instead of '^' to invert > the selection to match the rest of add -i and clean -i. > > These patches build on top of the recount fixes in [1]. The

Re: [PATCH 2/3] rebase -i --keep-empty: don't prune empty commits

Johannes Schindelin writes: >> But I wonder if this is even easier to follow. It makes it even >> more clear that patchsame commits that are not empty are discarded >> unconditionally. >> >> while ((commit = get_revision())) { >> int is_empty =

Re: [PATCH 1/9] git_config_set: fix off-by-two

On Thu, Mar 29, 2018 at 8:18 AM, Johannes Schindelin wrote: > Currently, we are slightly overzealous When removing an entry from a > config file of this form: > > [abc]a > [xyz] > key = value > > When calling `git config --unset abc.a`

Re: [PATCH 2/4] add chdir-notify API

On Thu, Mar 29, 2018 at 7:48 PM, Jeff King wrote: > On Thu, Mar 29, 2018 at 04:53:42PM +0200, Duy Nguyen wrote: > >> On Wed, Mar 28, 2018 at 7:40 PM, Jeff King wrote: >> > +static void reparent_cb(const char *old_cwd, >> > + const char

Re: [PATCH 3/4] set_work_tree: use chdir_notify

On Thu, Mar 29, 2018 at 7:50 PM, Jeff King wrote: > On Thu, Mar 29, 2018 at 07:02:21PM +0200, Duy Nguyen wrote: > >> On Wed, Mar 28, 2018 at 7:42 PM, Jeff King wrote: >> > When we change to the top of the working tree, we manually >> > re-adjust $GIT_DIR and call

[PATCH] credential: ignore SIGPIPE when writing to credential helpers

The credential subsystem can trigger SIGPIPE when writing to an external helper if that helper closes its stdin before reading the whole input. Normally this is rare, since helpers would need to read that input to make a decision about how to respond, but: 1. It's reasonable to configure a helper

Re: [PATCH 0/9] Assorted fixes for `git config` (including the "empty sections" bug)

On Thu, Mar 29, 2018 at 8:18 AM, Johannes Schindelin wrote: > So what is the argument against this extra care to detect comments? Well, if > you have something like this: > > [section] > ; Here we comment about the variable called snarf >

Re: [PATCH] credential: cred helper fast exit can cause SIGPIPE, crash

On Thu, Mar 29, 2018 at 05:25:04PM +, Erik Brady -X (brady - ROBERT HALF INTERNATIONAL INC at Cisco) wrote: > OK, will retry on the comment. I guess I misunderstood the guidelines > a bit on the signoff as well (ie: non-optional), apologies. Will > resubmit via 'git send-email' after

Re: [PATCH 3/4] set_work_tree: use chdir_notify

On Thu, Mar 29, 2018 at 07:23:17PM +0200, Duy Nguyen wrote: > On Thu, Mar 29, 2018 at 7:02 PM, Duy Nguyen wrote: > > ... > > > > It's less code this way, but it uses up more of your (or my) time > > because even though the first set_git_dir() call actually happens at 8 > >

Re: [PATCH 3/4] set_work_tree: use chdir_notify

On Thu, Mar 29, 2018 at 07:02:21PM +0200, Duy Nguyen wrote: > On Wed, Mar 28, 2018 at 7:42 PM, Jeff King wrote: > > When we change to the top of the working tree, we manually > > re-adjust $GIT_DIR and call set_git_dir() again, in order to > > update any relative git-dir we'd

Re: [PATCH 2/4] add chdir-notify API

On Thu, Mar 29, 2018 at 04:53:42PM +0200, Duy Nguyen wrote: > On Wed, Mar 28, 2018 at 7:40 PM, Jeff King wrote: > > +static void reparent_cb(const char *old_cwd, > > + const char *new_cwd, > > + void *data) > > +{ > > + char **path

Re: [PATCH] credential: cred helper fast exit can cause SIGPIPE, crash

Thanks Jeff. OK, will retry on the comment. I guess I misunderstood the guidelines a bit on the signoff as well (ie: non-optional), apologies. Will resubmit via 'git send-email' after adjusting the comment and recommitting with the -s option. First time for everything I suppose, doh. As to

Re: [PATCH 3/4] set_work_tree: use chdir_notify

On Thu, Mar 29, 2018 at 7:02 PM, Duy Nguyen wrote: > ... > > It's less code this way, but it uses up more of your (or my) time > because even though the first set_git_dir() call actually happens at 8 > places. Is it worth trying ? Never mind. I took a stab anyway. The setup

Re: [PATCH 3/4] set_work_tree: use chdir_notify

On Wed, Mar 28, 2018 at 7:42 PM, Jeff King wrote: > When we change to the top of the working tree, we manually > re-adjust $GIT_DIR and call set_git_dir() again, in order to > update any relative git-dir we'd compute earlier. Another way to approach this problem is not delaying

[PATCH 7/9] git config --unset: remove empty sections (in normal situations)

The original reasoning for not removing section headers upon removal of the last entry went like this: the user could have added comments about the section, or about the entries therein, and if there were other comments there, we would not know whether we should remove them. In particular, a

[PATCH 3/9] t1300: avoid relying on a bug

The test case 'unset with cont. lines' relied on a bug that is about to be fixed: it tests *explicitly* that removing the last entry from a config section leaves an *empty* section behind. Let's fix this test case not to rely on that behavior, simply by preventing the section from becoming empty.

[PATCH 5/9] t1300: `--unset-all` can leave an empty section behind (bug)

We already have a test demonstrating that removing the last entry from a config section fails to remove the section header of the now-empty section. The same can happen, of course, if we remove the last entries in one fell swoop. This is *also* a bug, and should be fixed at the same time.

[PATCH 6/9] git_config_set: simplify the way the section name is remembered

This not only reduces the number of lines, but also opens the door for reusing the section name later (which the upcoming patch to remove now-empty sections will do). Signed-off-by: Johannes Schindelin --- config.c | 10 -- 1 file changed, 4 insertions(+), 6

[PATCH 4/9] t1300: remove unreasonable expectation from TODO

In https://public-inbox.org/git/7vvc8alzat@alter.siamese.dyndns.org/ a reasonable patch was made quite a bit less so by changing a test case demonstrating a bug to a test case that demonstrates that we ask for too much: the test case 'unsetting the last key in a section removes header' now

[PATCH 8/9] git_config_set: use do_config_from_file() directly

Technically, it is the git_config_set_multivar_in_file_gently() function that we modify here (but the oneline would get too long if we were that precise). This change prepares the git_config_set machinery to allow reusing empty sections, by using the file-local function do_config_from_file()

[PATCH 9/9] git_config_set: reuse empty sections

It can happen quite easily that the last setting in a config section is removed, and to avoid confusion when there are comments in the config about that section, we keep a lone section header, i.e. an empty section. The code to add new entries in the config tries to be cute by reusing the parsing

[PATCH 2/9] t1300: rename it to reflect that `repo-config` was deprecated

Signed-off-by: Johannes Schindelin --- t/{t1300-repo-config.sh => t1300-config.sh} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename t/{t1300-repo-config.sh => t1300-config.sh} (100%) diff --git a/t/t1300-repo-config.sh b/t/t1300-config.sh similarity index

[PATCH 1/9] git_config_set: fix off-by-two

Currently, we are slightly overzealous When removing an entry from a config file of this form: [abc]a [xyz] key = value When calling `git config --unset abc.a` on this file, it leaves this (invalid) config behind: [ [xyz] key =

[PATCH 0/9] Assorted fixes for `git config` (including the "empty sections" bug)

This patch series started out as a single patch trying to figure out what it takes to fix that annoying bug that has been reported several times over the years, where `git config --unset` would leave empty sections behind, and `git config --add` would not reuse them. Little did I know that this

[PATCH v3 0/3] Enable more compiler warnings for devs

v3 fixes the fallthru warnings in connect.c, and with json-writer series rerolled, 'pu' should build cleanly now. -Wno-maybe-uninitialized is removed, thanks to Ramsay. v3 also adds an experimental patch that adds EAGER_DEVELOPER=1. These developers will have all warnings enabled (nothing is

[PATCH v3 2/3] Makefile: detect compiler and enable more warnings in DEVELOPER=1

The set of extra warnings we enable when DEVELOPER has to be conservative because we can't assume any compiler version the developer may use. Detect the compiler version so we know when it's safe to enable -Wextra and maybe more. These warning settings are mostly from my custom config.mak a long

[PATCH v3 3/3] Makefile: add EAGER_DEVELOPER mode

This mode is for developers who want to keep the code base clean. There are warning classes that are currently suppressed because we have too many of them in the code base. This mode will stop the suppression, let the developer see and decide how to fix them. Signed-off-by: Nguyễn Thái Ngọc Duy

Re: [PATCH v4] Allow use of TLS 1.3

Hi Logan, On Thu, 29 Mar 2018, Loganaden Velvindron wrote: > Add a tlsv1.3 option to http.sslVersion in addition to the existing > tlsv1.[012] options. libcurl has supported this since 7.52.0. > > This requires OpenSSL 1.1.1 with TLS 1.3 enabled or curl built with > recent versions of NSS or

[PATCH v3 1/3] connect.c: mark die_initial_contact() NORETURN

There is a series running in parallel with this one that adds code like this switch (...) { case ...: die_initial_contact(); case ...: There is nothing wrong with this. There is no actual falling through. But since gcc is not that smart and gcc 7.x introduces

Re: [PATCH 0/8] Re: git complains packed-refs is not a directory when used with GIT_DIR and GIT_WORK_TREE envvars.

On Wed, Mar 28, 2018 at 02:19:32PM -0400, Jeff King wrote: > > > I will probably rework on top of your chdir-notify instead (and let > > yours to be merged earlier) > > Thanks. I like some of the related changes you made, like including this > in the tracing output. That should be easy to do on

Re: [PATCH 0/2] Add Windows support to the new RUNTIME_PREFIX design

Hi Junio, On Wed, 28 Mar 2018, Junio C Hamano wrote: > Daniel Jacques writes: > > > A simple grep suggests that the current test suite doesn't seem to have any > > RUNTIME_PREFIX-specific tests. When I've been running the test suites, I've > > been doing it with a "config.mak"

Re: [PATCH 2/4] add chdir-notify API

On Wed, Mar 28, 2018 at 7:40 PM, Jeff King wrote: > +static void reparent_cb(const char *old_cwd, > + const char *new_cwd, > + void *data) > +{ > + char **path = data; Maybe check data == NULL and return early. This is just for

Re: [PATCH v6 0/6] ref-filter: remove die() calls from formatting logic

On Thu, Mar 29, 2018 at 2:52 PM, Оля Тележная wrote: > Move helper function from strbuf to ref-filter. > Get rid of some memory leaks. The above seems to be the changes since v5. Usually in a cover letter (patch 0/X) there is both information about the goal of the patch

Re: [PATCH v3 3/3] Move reusable parts of memory pool into its own file

Thank you for the thorough and detailed review - I very much appreciate it. > I > am OK if the structure of this series is to make that change after > these three steps we see here.  I will add (back) the accounting of large memory blocks in a future patch series, taking into account your

Re: [PATCH 00/10] Hash-independent tests (part 1)

Hi Junio, On Wed, 28 Mar 2018, Junio C Hamano wrote: > Johannes Schindelin writes: > > >> Ideally, the existing one be annotated with prereq SHA1, and also > >> duplicated with a tweak to cause the same kind of (half-)collision > >> under the NewHash and be

Re: [RFC/PATCH] upload-pack: disable object filtering when disabled by config

On 3/28/2018 6:12 PM, Junio C Hamano wrote: Jonathan Nieder writes: When upload-pack gained partial clone support (v2.17.0-rc0~132^2~12, 2017-12-08), it was guarded by the uploadpack.allowFilter config item to allow server operators to control when they start supporting

[PATCH v6 0/6] ref-filter: remove die() calls from formatting logic

Move helper function from strbuf to ref-filter. Get rid of some memory leaks. Thanks to everyone! Olga

[PATCH v6 1/6] ref-filter: add shortcut to work with strbufs

Add function strbuf_addf_ret() that helps to save a few lines of code. Function expands fmt with placeholders, append resulting message to strbuf *sb, and return error code ret. Signed-off-by: Olga Telezhnaia --- ref-filter.c | 13 + 1 file changed, 13

[PATCH v6 4/6] ref-filter: change parsing function error handling

Continue removing die() calls from ref-filter formatting logic, so that it could be used by other commands. Change the signature of parse_ref_filter_atom() by adding strbuf parameter for error message. The function returns the position in the used_atom[] array (as before) for the given atom, or

[PATCH v6 2/6] ref-filter: start adding strbufs with errors

This is a first step in removing die() calls from ref-filter formatting logic, so that it could be used by other commands that do not want to die during formatting process. die() calls related to bugs in code will not be touched in this patch. Everything would be the same for

[PATCH v6 3/6] ref-filter: add return value && strbuf to handlers

Continue removing die() calls from ref-filter formatting logic, so that it could be used by other commands. Change the signature of handlers by adding return value and strbuf parameter for errors. Return value equals 0 upon success and -1 upon failure. Upon failure, error message is appended to

[PATCH v6 6/6] ref-filter: libify get_ref_atom_value()

Finish removing die() calls from ref-filter formatting logic, so that it could be used by other commands. Change the signature of get_ref_atom_value() and underlying functions by adding return value and strbuf parameter for error message. Return value equals 0 upon success and -1 upon failure.

[PATCH v6 5/6] ref-filter: add return value to parsers

Continue removing die() calls from ref-filter formatting logic, so that it could be used by other commands. Change the signature of parsers by adding return value and strbuf parameter for error message. Return value equals 0 upon success and -1 upon failure. Upon failure, error message is

Re: [PATCH] credential: cred helper fast exit can cause SIGPIPE, crash

On Wed, Mar 28, 2018 at 03:20:51PM -0700, Erik E Brady wrote: > Subject: Re: [PATCH] credential: cred helper fast exit can cause SIGPIPE, > crash Thanks for sending this. The patch itself looks good to me, but I have a few nits with your commit message. We usually write commit messages in the

[PATCH v4] Allow use of TLS 1.3

Add a tlsv1.3 option to http.sslVersion in addition to the existing tlsv1.[012] options. libcurl has supported this since 7.52.0. This requires OpenSSL 1.1.1 with TLS 1.3 enabled or curl built with recent versions of NSS or BoringSSL as the TLS backend. Signed-off-by: Loganaden Velvindron

Re: [PATCH v4 1/5] stash: improve option parsing test coverage

On Wed, Mar 28, 2018 at 6:21 PM, Joel Teichroeb wrote: > In preparation for converting the stash command incrementally to > a builtin command, this patch improves test coverage of the option > parsing. Both for having too many paramerters, or too few.

Re: M.Williams Chambers and Associates.

Good Day and congratulations . My Client Mrs. Marilyn Boldon has made a donation 3.5m euros to you, contact her through her private email: marilynbol...@gmail.com for more detail on how to receive this donation. Barrister. Omar Gamez Vargas. Esq. M.Williams Chambers and Associates.