When a commit is reverted (or cherry-picked with -x) we add an English
sentence recording that commit id in the new commit message. Make
these real trailer lines instead so that they are more friendly to
parsers (especially "git interpret-trailers").
A reverted commit will have a new trailer
Add a dedicated signing subkey to the key identified as 'Eris
Discordia', and update tests appropriately. GnuPG will now sign commits
using the dedicated signing subkey, changing the value of %GK and %GF,
and effectively creating a test case for %GF!=%GP.
Signed-off-by: Michał Górny
---
Test %GP in addition to %GF in custom format checks. With current
keyring, both have the same value.
Signed-off-by: Michał Górny
---
t/t7510-signed-commit.sh | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/t/t7510-signed-commit.sh
On Sun, Nov 4, 2018 at 7:27 AM Eric Sunshine wrote:
>
> On Sat, Nov 3, 2018 at 8:25 PM Eric Sunshine wrote:
> > On Sat, Nov 3, 2018 at 11:31 AM Nguyễn Thái Ngọc Duy
> > wrote:
> > > +test_expect_success 't_e_i() exclude case #8' '
> > > + git init case8 &&
> > > + (
> > > +
On Sat, Nov 3, 2018 at 8:25 PM Eric Sunshine wrote:
> On Sat, Nov 3, 2018 at 11:31 AM Nguyễn Thái Ngọc Duy
> wrote:
> > +test_expect_success 't_e_i() exclude case #8' '
> > + git init case8 &&
> > + (
> > + cd case8 &&
> > + echo file >file1 &&
> > +
On Wed, Oct 31, 2018 at 9:53 PM Ben Peart wrote:
> >> +core.virtualFilesystem::
> >> + If set, the value of this variable is used as a command which
> >> + will identify all files and directories that are present in
> >> + the working directory. Git will only track and update
Michał Górny writes:
> I've just did a little research and came to the following results:
Wonderful.
> 1. modifying the 'C. O. Mitter' key would require changes to 4 tests,
>
> 2. modifying the 'Eris Discordia' key would require changes to 2 tests
>(both in 7510).
>
> Do you think 2. would
There are no users of OPT_DATE except for test-parse-options; its
only caller went away in 27ec394a97 (prune: introduce OPT_EXPIRY_DATE()
and use it, 2013-04-25).
It also has a bug: it does not specify PARSE_OPT_NONEG, but its callback
does not respect the "unset" flag, and will feed NULL to
The option callback for "apply --whitespace" exits with status "1" on
error. It makes more sense for it to just return an error to
parse-options. That code will exit, too, but it will use status "129"
that is customary for option errors.
The exit() dates back to aaf6c447aa (builtin/apply: make
The options callback for --batch and --batch-check detects when the two
mutually incompatible options are used. But it simply returns an error
code to parse-options, meaning the program will quit without any kind of
message to the user.
Instead, let's use error() to print something and return -1.
We do not allow "--no-message" to work now, as the option callback
returns "-1" when it sees a NULL arg. However, that will cause
parse-options to exit(129) without printing anything further, leaving
the user confused about what happened.
Instead, let's explicitly mark it as PARSE_OPT_NONEG,
Running "git show-branch --no-reflog" will behave as if "--reflog" was
given with no options, which makes no sense.
In theory this option might be used to cancel an earlier "--reflog"
option, but the semantics are not clear. Let's punt on it and just
disallow the broken option.
Signed-off-by:
Jeff King writes:
> The options callback for "git apply --no-include" is not ready to handle
> the "unset" parameter, and as a result will segfault when it adds a NULL
> argument to the include list (likewise for "--no-exclude").
>
> In theory this might be used to clear the list, but since both
Jeff King writes:
> Running "git am --no-patch-format" will currently segfault, since it
> tries to parse a NULL argument. Instead, let's have it cancel any
> previous --patch-format option.
Makes perfect sense.
>
> Signed-off-by: Jeff King
> ---
> builtin/am.c | 4 +++-
> 1 file changed, 3
Eric Sunshine writes:
> If "key" is for including particular trailers, intuition might lead
> people to think that "nokey" is for excluding certain trailers.
> Perhaps a different name for "nokey", such as "valueonly" or
> "stripkey", would be better.
Good point. I guess "valueonly" would be
On Sun, Nov 04 2018, brian m. carlson wrote:
> The transition plan anticipates us using a syntax such as "^{sha1}" for
> disambiguation. Since this is a syntax some people will be typing a
> lot, it makes sense to provide a short, easy-to-type syntax. Omitting
> the dash doesn't create any
Junio C Hamano writes:
> Stefan Beller writes:
>
>>
>> -static int parse_color_moved_ws(const char *arg)
>> +static unsigned parse_color_moved_ws(const char *arg)
>> {
>> int ret = 0;
>> struct string_list l = STRING_LIST_INIT_DUP;
>> @@ -312,15 +312,19 @@ static int
Running "cat-file --no-batch" will behave as if "--batch" was given,
since the option callback does not handle the "unset" flag (likewise for
"--no-batch-check").
In theory this might be used to cancel an earlier --batch, but it's not
immediately obvious how that would interact with
Running "git pack-objects --no-index-version" will segfault, since the
callback is not prepared to handle the "unset" flag.
In theory this might be used to counteract an earlier "--index-version",
or override a pack.indexversion config setting. But the semantics aren't
immediately obvious, and
We have separate parse-options entries for "numbered" and "no-numbered",
which means that we accept "--no-no-numbered". It does not behave
sensibly, though (it ignores the "unset" flag and acts like
"--no-numbered").
We could fix that, but obviously this is silly and unintentional. Let's
just
If you run "git status --no-find-renames", it will behave the same as
"--find-renames", because we ignore the "unset" parameter (we see a NULL
"arg", but since the score argument is optional, we just think that the
user did not provide a score).
We already have a separate "--no-renames" to
On Mon, Nov 05, 2018 at 07:24:42AM +0100, Matthias Urlichs wrote:
> Hi,
> > "git checkout " is a feature to overwrite local
> > changes. It is what you use when you make a mess editing the files
> > and want to go back to a known state. Why should that feature be
> > destroyed?
>
> Not
Am 05.11.18 um 00:26 schrieb Junio C Hamano:
OK, thanks. It seems that the relative silence after this message
is a sign that the resulting patch after squashing is what everybody
is happey with?
I'm not 100% happy. I'll resend a squashed patch, but it has to wait as
I have to catch a train
Continuing my exploration of what -Wunused-parameters can show us, here
are some bug-fixes related to parse-options callbacks.
This is the last of the actual bug-fixes I've found. After this, I have
about 60 patches worth of cleanups (i.e., dropping the unused
parameters), and then I have a
When we define a parse-options callback, the flags we put in the option
struct must match what the callback expects. For example, a callback
which does not handle the "unset" parameter should only be used with
PARSE_OPT_NONEG. But since the callback and the option struct are not
defined next to
Hi,
> "git checkout " is a feature to overwrite local
> changes. It is what you use when you make a mess editing the files
> and want to go back to a known state. Why should that feature be
> destroyed?
Not destroyed, but optionally made finger-fumble-save – like "alias rm
rm -i".
--
--
Running "git ls-files --no-exclude" will currently segfault, as its
option callback does not handle the "unset" parameter.
In theory this could be used to clear the exclude list, but it is not
clear how that would interact with the other exclude options, nor is the
current code capable of
The options callback for "git apply --no-include" is not ready to handle
the "unset" parameter, and as a result will segfault when it adds a NULL
argument to the include list (likewise for "--no-exclude").
In theory this might be used to clear the list, but since both
"--include" and "--exclude"
Running "git am --no-patch-format" will currently segfault, since it
tries to parse a NULL argument. Instead, let's have it cancel any
previous --patch-format option.
Signed-off-by: Jeff King
---
builtin/am.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/builtin/am.c
On Fri, Nov 02, 2018 at 03:30:17AM +0100, Adrián Gimeno Balaguer wrote:
> I’m attempting to perform fixups via git-rebase of UTF-16 LE files
> (the project I’m working on requires that exact encoding on certain
> files). When the rebase is complete, Git changes that file’s encoding
> to UTF-16 BE.
On Fri, Nov 02, 2018 at 03:30:17AM +0100, Adrián Gimeno Balaguer wrote:
> I’m attempting to perform fixups via git-rebase of UTF-16 LE files
> (the project I’m working on requires that exact encoding on certain
> files). When the rebase is complete, Git changes that file’s encoding
> to UTF-16 BE.
Adds a new "key=X" option to "%(trailers)" which will cause it to only
print trailers lines which matches the specified key.
Signed-off-by: Anders Waldenborg
---
Documentation/pretty-formats.txt | 13 +
pretty.c | 15 ++-
t/t4205-log-pretty-formats.sh
No functional change intended
Signed-off-by: Anders Waldenborg
---
pretty.c | 37 ++---
1 file changed, 26 insertions(+), 11 deletions(-)
diff --git a/pretty.c b/pretty.c
index f87ba4f18..9fdddce9d 100644
--- a/pretty.c
+++ b/pretty.c
@@ -1074,6 +1074,27 @@
With the new "key=" option to %trailers it often makes little sense to
show the key, as it by definition already is know which trailer is
printed there. This new "nokey" option makes it omit key trailer key
when printing trailers.
E.g.:
$ git show -s
By default trailer lines are terminated by linebreaks ('\n'). By
specifying the new 'separator' option they will instead be separated by
user provided string and have separator semantics rather than terminator
semantics. The separator string can contain the fundamental formatting
codes %n and %xNN
On 04/11/2018 07:22, Nguyễn Thái Ngọc Duy wrote:
When a commit is reverted (or cherry-picked with -x) we add an English
sentence recording that commit id in the new commit message. Make
these real trailer lines instead so that they are more friendly to
parsers (especially "git
El dom., 4 nov. 2018 a las 16:48, brian m. carlson
() escribió:
> Do things work for you if you write this as "UTF-16LE"? When you use
> working-tree-encoding, the file is stored internally as UTF-8, but it's
> serialized to the specified encoding when written out.
When I use UTF-16LE or
On Sun, Nov 04, 2018 at 10:47:10AM +0100, Michał Górny wrote:
> diff --git a/t/t7510-signed-commit.sh b/t/t7510-signed-commit.sh
> index e8377286d..86d3f93fa 100755
> --- a/t/t7510-signed-commit.sh
> +++ b/t/t7510-signed-commit.sh
> @@ -197,9 +197,9 @@ test_expect_success GPG 'show bad signature
No functional change intended.
This change may not seem useful on its own, but upcoming commits will do
memory allocation in there, and a single return path makes deallocation
easier.
Signed-off-by: Anders Waldenborg
---
pretty.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff
This adds support for three new options to %(trailers):
* key -- show only trailers with specified key
* nokey -- don't show key part of trailers
* separator -- allow specifying custom separator between trailers
Anders Waldenborg (5):
pretty: single return path in %(trailers) handling
On Sun, 2018-11-04 at 15:10 +, brian m. carlson wrote:
> On Sun, Nov 04, 2018 at 10:47:10AM +0100, Michał Górny wrote:
> > diff --git a/t/t7510-signed-commit.sh b/t/t7510-signed-commit.sh
> > index e8377286d..86d3f93fa 100755
> > --- a/t/t7510-signed-commit.sh
> > +++
On Sun, Nov 4, 2018 at 10:23 AM Anders Waldenborg wrote:
> This adds support for three new options to %(trailers):
> * key -- show only trailers with specified key
> * nokey -- don't show key part of trailers
> * separator -- allow specifying custom separator between trailers
If "key" is for
On Sun, Nov 4, 2018 at 5:45 PM Phillip Wood wrote:
>
> On 04/11/2018 07:22, Nguyễn Thái Ngọc Duy wrote:
> > When a commit is reverted (or cherry-picked with -x) we add an English
> > sentence recording that commit id in the new commit message. Make
> > these real trailer lines instead so that
PREAMBLE [START] - please feel free to skip this first section
Forgive me for asking this question on a mailing list.
stackoverflow would probably kill such a question before the bits were fully
saved to a server drive.
Let me explain why i am asking and why i am not being a troll.
[a] i'm
On Sun, Nov 04, 2018 at 05:37:09PM +0100, Adrián Gimeno Balaguer wrote:
> I wrote a "counterpart" easy fix which instead only prohibites BOM for
> the opposite endianness (for example if
> working-tree-encoding=UTF-16LE, then finding an UTF-16BE BOM in the
> file would cause Git to signal the
When a commit is reverted (or cherry-picked with -x) we add an English
sentence recording that commit id in the new commit message. Make
these real trailer lines instead so that they are more friendly to
parsers (especially "git interpret-trailers").
A reverted commit will have a new trailer
On Sun, Nov 4, 2018 at 10:24 AM Anders Waldenborg wrote:
> Adds a new "key=X" option to "%(trailers)" which will cause it to only
> print trailers lines which matches the specified key.
>
> Signed-off-by: Anders Waldenborg
> ---
> diff --git a/Documentation/pretty-formats.txt
>
Hi,
the problem: suppose I decide that a local file should no longer be
controlled by git. Thus I add it to .gitignore and then "git rm
--cached" it. So far so good.
However, if I subsequently modify that file and then go back to a commit
that still contains it, my local changes will be
Hi,
A recent discussion on LWN https://lwn.net/Articles/770642/ noted that
"git checkout " does not warn if one if the files has
been modified locally, nor is there an option to do so.
IMHO that should be fixed, preferably by somebody who knows git's
internals well enough to do so in half an
Hello
I’m Laura Stevens of Federal clearance credit department, we discovered Payment
that was approved for an Italian business man living in the USA, Presently, I
was asked to raise a Bank Draft for $41million Dollars in his name and have it
mailed to his bank. I put up a telephone call and
Nguyễn Thái Ngọc Duy writes:
> tree_entry_interesting() is used for matching pathspec on a tree. The
> interesting thing about this function is that, because the tree
> entries are known to be sorted, this function can return more than
> just "yes, matched" and "no, not matched". It can also
Eric Sunshine writes:
> Junio labeled the "-2" trick "cute", and while it is optimal in that
> it only traverses the key/value list once, it also increases cognitive
> load since the reader has to spend a good deal more brain cycles
> understanding what is going on than would be the case with
Anders Waldenborg writes:
> No functional change intended
>
> Signed-off-by: Anders Waldenborg
> ---
> pretty.c | 37 ++---
> 1 file changed, 26 insertions(+), 11 deletions(-)
I do not think "fundamental" is the best name for this, but I agree
that it would be
Anders Waldenborg writes:
> @@ -1352,6 +1353,17 @@ static size_t format_commit_one(struct strbuf *sb, /*
> in UTF-8 */
> arg++;
>
> opts.only_trailers = 1;
> + } else if
"brian m. carlson" writes:
> I'm currently working on getting Git to support multiple hash algorithms
> in the same binary (SHA-1 and SHA-256). In order to have a fully
> functional binary, we'll need to have some way of indicating to certain
> commands (such as init and show-index) that they
"brian m. carlson" writes:
> This series provides a functional SHA-256 implementation and wires it
> up, along with some housekeeping patches to make it suitable for
> testing.
>
> Changes from v4:
> * Downcase hex constants for consistency.
> * Remove needless parentheses in return statement.
>
We have in the past had some unfortunate endianness issues with some
SHA-1 implementations we ship, especially on big-endian machines. Add
an explicit test using the test helper to catch these issues and point
them out prominently. This test can also be used as a staging ground
for people
In 183a638b7d ("hashcmp: assert constant hash size", 2018-08-23), we
modified hashcmp to assert that the hash size was always 20 to help it
optimize and inline calls to memcmp. In a future series, we replaced
many calls to hashcmp and oidcmp with calls to hasheq and oideq to
improve inlining
This series provides a functional SHA-256 implementation and wires it
up, along with some housekeeping patches to make it suitable for
testing.
Changes from v4:
* Downcase hex constants for consistency.
* Remove needless parentheses in return statement.
* Remove braces for single statement loops.
Currently, we have functions that turn an arbitrary SHA-1 value or an
object ID into hex format, either using a static buffer or with a
user-provided buffer. Add variants of these functions that can handle
an arbitrary hash algorithm, specified by constant. Update the
documentation as well.
On November 4, 2018 6:26 PM, Junio C Hamano, wrote:
> Johannes Sixt writes:
>
> > Am 03.11.18 um 09:14 schrieb Carlo Arenas:
> >> On Fri, Nov 2, 2018 at 9:44 AM Johannes Sixt wrote:
> >>>
> >>> + timeout = elapsed >= orig_timeout ? 0 : (int)(orig_timeout -
> >>> + elapsed);
> >>
> >>
There is one place we need the hash algorithm block size: the HMAC code
for push certs. Expose this constant in struct git_hash_algo and expose
values for SHA-1 and for the largest value of any hash.
Signed-off-by: brian m. carlson
---
cache.h | 4
hash.h | 3 +++
sha1-file.c | 2
The transition plan anticipates us using a syntax such as "^{sha1}" for
disambiguation. Since this is a syntax some people will be typing a
lot, it makes sense to provide a short, easy-to-type syntax. Omitting
the dash doesn't create any ambiguity; however, it does make the syntax
shorter and
Since we're going to have multiple hash algorithms to test, it makes
sense to share as much of the test code as possible. Convert the sha1
helper for the test-tool to be generic and move it out into its own
module. This will allow us to share most of this code with our NewHash
implementation.
There are several ways we might refer to a hash algorithm: by name, such
as in the config file; by format ID, such as in a pack; or internally,
by a pointer to the hash_algos array. Provide functions to look up hash
algorithms based on these various forms and return the internal constant
used for
Instead of using hard-coded constants for object sizes, use
the_hash_algo to look them up. In addition, use a function call to look
up the object ID version and produce the correct value. For now, we use
version 1, which means to use the default algorithm used in the rest of
the repository.
We already have OpenSSL routines available for SHA-1, so add routines
for SHA-256 as well.
On a Core i7-6600U, this SHA-256 implementation compares favorably to
the SHA1DC SHA-1 implementation:
SHA-1: 157 MiB/s (64 byte chunks); 337 MiB/s (16 KiB chunks)
SHA-256: 165 MiB/s (64 byte chunks); 408
Generally, one gets better performance out of cryptographic routines
written in assembly than C, and this is also true for SHA-256. In
addition, most Linux distributions cannot distribute Git linked against
OpenSSL for licensing reasons.
Most systems with GnuPG will also have libgcrypt, since it
SHA-1 is weak and we need to transition to a new hash function. For
some time, we have referred to this new function as NewHash. Recently,
we decided to pick SHA-256 as NewHash. The reasons behind the choice of
SHA-256 are outlined in the thread starting at [1] and in the commit
history for the
Add a utility (which is less for the testsuite and more for developers)
that can compute hash speeds for whatever hash algorithms are
implemented. This allows developers to test their personal systems to
determine the performance characteristics of various algorithms.
Signed-off-by: brian m.
Ben Peart writes:
>>> + if (*dtype == DT_UNKNOWN)
>>> + *dtype = get_dtype(NULL, istate, pathname, pathlen);
>>
>> We try to defer paying cost to determine unknown *dtype as late as
>> possible by having this call in last_exclude_matching_from_list(),
>> and not here. If we are
Ævar Arnfjörð Bjarmason writes:
> I.e. you seemingly have no interest in using "git commit" to produce
> empty commits, but are just trying to cherry-pick something and it's
> failing because it (presumably, or am I missing something) cherry picks
> an existing commit content ends up not
Mikkel Kjeldsen writes:
> Add --new-branch as a long-form synonym of -b. I occasionally encounter
> some confusion in new users having interpreted "checkout -b" to mean
> "checkout branch", or internalized it as "the way to create a new
> branch" rather than merely a convenience for "branch &&
Nguyễn Thái Ngọc Duy writes:
> A reverted commit will have a new trailer
>
> Revert:
Please don't, unless you are keeping the current "the effect of
commit X relative to its parent Y was reverted" writtein in prose,
which is meant to be followed up with a manually written "because
..."
I'm currently working on getting Git to support multiple hash algorithms
in the same binary (SHA-1 and SHA-256). In order to have a fully
functional binary, we'll need to have some way of indicating to certain
commands (such as init and show-index) that they should assume a certain
hash
Michał Górny writes:
>> It's my understanding that GnuPG will use the most recent subkey
>> suitable for a particular purpose, and I think the test relies on that
>> behavior. However, I'm not sure that's documented. Do we want to rely
>> on that behavior or be more explicit? (This is a
Matthias Urlichs writes:
> A recent discussion on LWN https://lwn.net/Articles/770642/ noted that
> "git checkout " does not warn if one if the files has
> been modified locally, nor is there an option to do so.
>
> IMHO that should be fixed, preferably by somebody who knows git's
> internals
Nguyễn Thái Ngọc Duy writes:
> Noticed-by: SZEDER Gábor
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> On top of nd/per-worktree-ref-iteration
Thanks.
>
> Documentation/git-worktree.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/git-worktree.txt
James Knight writes:
> Changes v1 -> v2:
> - Improved support for detecting curl linker flags when not using a
> configure-based build (mentioned by Junio C Hamano).
> - Adding a description on how to explicitly use the CURL_LDFLAGS
> define when not using configure (suggested by Junio
Nguyễn Thái Ngọc Duy writes:
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> On top of ag/rebase-i-in-c
Thanks.
On Sun, Nov 04, 2018 at 07:34:01AM +0100, Duy Nguyen wrote:
> On Wed, Oct 31, 2018 at 9:53 PM Ben Peart wrote:
> > It's more than a dynamic sparse-checkout because the same list is also
> > used to exclude any file/folder not listed. That means any file not
> > listed won't ever be updated by
Hi Duy
On 04/11/2018 17:41, Duy Nguyen wrote:
On Sun, Nov 4, 2018 at 5:45 PM Phillip Wood wrote:
On 04/11/2018 07:22, Nguyễn Thái Ngọc Duy wrote:
When a commit is reverted (or cherry-picked with -x) we add an English
sentence recording that commit id in the new commit message. Make
these
On Sun, Nov 04, 2018 at 07:10:26PM +0100, Nguyễn Thái Ngọc Duy wrote:
> When a commit is reverted (or cherry-picked with -x) we add an English
> sentence recording that commit id in the new commit message. Make
> these real trailer lines instead so that they are more friendly to
> parsers
Johannes Sixt writes:
> Am 03.11.18 um 09:14 schrieb Carlo Arenas:
>> On Fri, Nov 2, 2018 at 9:44 AM Johannes Sixt wrote:
>>>
>>> + timeout = elapsed >= orig_timeout ? 0 : (int)(orig_timeout -
>>> elapsed);
>>
>> nitpick: cast to DWORD instead of int
>
> No; timeout is of type int; after
On Sun, Nov 4, 2018 at 6:26 PM Junio C Hamano wrote:
> OK, thanks. It seems that the relative silence after this message
> is a sign that the resulting patch after squashing is what everybody
> is happey with?
>
> -- >8 --
> From: Steve Hoelzer
>
> Signed-off-by: Johannes Sixt
> Acked-by:
Eric Sunshine writes:
> Does the user have to include the colon when specifying of
> 'key='? I can see from peeking at the implementation that the
> colon must not be used, but this should be documented. Should the code
> tolerate a trailing colon? (Genuine question; it's easy to do and
> would
On Sun, Nov 4, 2018 at 10:48 PM Junio C Hamano wrote:
> Eric Sunshine writes:
> > Does the user have to include the colon when specifying of
> > 'key='?
> > Does 'key=', do a full or partial match on trailers?
> > What happens if 'key=...' is specified multiple times?
> > Thinking further on
Eric Sunshine writes:
> On Sun, Nov 4, 2018 at 6:26 PM Junio C Hamano wrote:
>> OK, thanks. It seems that the relative silence after this message
>> is a sign that the resulting patch after squashing is what everybody
>> is happey with?
>>
>> -- >8 --
>> From: Steve Hoelzer
>>
>>
On Mon, 2018-11-05 at 10:08 +0900, Junio C Hamano wrote:
> Michał Górny writes:
>
> > > It's my understanding that GnuPG will use the most recent subkey
> > > suitable for a particular purpose, and I think the test relies on that
> > > behavior. However, I'm not sure that's documented. Do we
El dom., 4 nov. 2018 a las 18:07, Torsten Bögershausen
() escribió:
>
> Thanks for the report.
> I have tried to follow the problem from your verbal descriptions
> (and the PR) but I need to admit that I don't fully understand the
> problem (yet).
I have created a PR in the Git's repository. You
Anders Waldenborg writes:
> + else if (skip_prefix(arg, "key=", )) {
> + const char *end = arg + strcspn(arg,
> ",)");
> +
> + if (opts.filter_key)
> +
Anders Waldenborg writes:
> + if (opts->separator && first_printed)
> + strbuf_addbuf(out, opts->separator);
> if (opts->no_key)
> - strbuf_addf(out, "%s\n",
92 matches
Mail list logo
