On Tue, May 29, 2018 at 11:59:07PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > I'm not sure what testing this buys us. [...]
>
> Half of what I'm trying to do here is clarifying the v2.17.1 release
> notes. The initial version Junio had & my proposed amendment on
> git-security was:
I think
On Wednesday 30 May 2018 08:22 AM, Junio C Hamano wrote:
Jeff King writes:
Right, what I meant by "gentler" is that we continue to perform the same
behavior as the old version, alongside the warning. It's arguable here
because running "git branch -l" has _always_ been wrong. It's just wrong
On Wed, May 30, 2018 at 11:52:19AM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > Right, what I meant by "gentler" is that we continue to perform the same
> > behavior as the old version, alongside the warning. It's arguable here
> > because running "git branch -l" has _always_ been
On Wed, May 30, 2018 at 11:48:32AM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> >> - if (list) {
> >> - warning("the '-l' option is an alias for
> >> '--create-reflog' and");
> >> - warning("has no effect in list mode. This option will
> >>
On Wed, May 30, 2018 at 11:20:40AM +0300, Kevin Bracey wrote:
> On 30/05/2018 00:04, Jeff King wrote:
> >
> > Do we even need to do the parent rewriting here? By definition those
> > parents aren't interesting, and we're TREESAME to whatever is in
> > treesame_parents. So conceptually it seems
On Wed, May 30, 2018 at 09:06:41PM +, Ævar Arnfjörð Bjarmason wrote:
> A co-worker of mine who was using UNIX systems when dinosaurs roamed
> the earth was lamenting that kids these days were using tools like
> "git" that thought they knew better than isatty(3) when deciding
> whether or not
On Wed, May 30, 2018 at 09:06:39PM +, Ævar Arnfjörð Bjarmason wrote:
> Change the documentation added when color.ui=auto was made the default
> in 4c7f1819b3 ("make color.ui default to 'auto'", 2013-06-10) to
> describe "auto" as kicking in when writing to the terminal or a pager,
> not just
On Wed, May 30, 2018 at 09:06:38PM +, Ævar Arnfjörð Bjarmason wrote:
> Ever since b982592d66 ("git-status: document colorization config
> options", 2006-09-11) we've slowly been accumulating more and more
> color.* options, where the documentation for each new one has
> seemingly been
On Wed, May 30, 2018 at 10:03:00AM -0700, Stefan Beller wrote:
> diff --git a/refs/packed-backend.c b/refs/packed-backend.c
> index cec3fb9e00f..d447a731da0 100644
> --- a/refs/packed-backend.c
> +++ b/refs/packed-backend.c
> @@ -499,6 +499,7 @@ static int load_contents(struct snapshot *snapshot)
On 30/5/18 6:45 pm, Eric Sunshine wrote:
>> diff --git a/Documentation/git-blame.txt b/Documentation/git-blame.txt
>> @@ -152,6 +152,16 @@ Also you can use a regular expression to specify the
>> line range:
>> which limits the annotation to the body of the `hello` subroutine.
>>
>> +A range that
From: Isabella Stephens
If the -L option is used to specify a line range in git log, and the end
of the range is past the end of the file, git will fail with a fatal
error. This commit prevents such behaviour - instead we perform the log
for existing lines within the specified range.
This
From: Isabella Stephens
If the -L option is used to specify a line range in git blame, and the
end of the range is past the end of the file, git will fail with a fatal
error. This commit prevents such behavior - instead we display the blame
for existing lines within the specified range. Tests
In the 2.18 cycle, directory rename detection was merged, then reverted,
then reworked in such a way to fix another prominent bug in addition to
the original problem causing it to be reverted. When the reworked series
was merged, we ended up with two nearly duplicate release notes. Remove
the
Jonathan Nieder wrote:
> Brandon Williams wrote:
>> When using protocol v2 a client constructs a list of ref-prefixes which
>> are sent across the wire so that the server can do server-side filtering
>> of the ref-advertisement. The logic that does this exists for both
>> fetch and push (even
Hi,
Brandon Williams wrote:
> When using protocol v2 a client constructs a list of ref-prefixes which
> are sent across the wire so that the server can do server-side filtering
> of the ref-advertisement. The logic that does this exists for both
> fetch and push (even though no push support for
On Wed, May 30, 2018 at 09:52:55PM +0100, Thomas Gummerer wrote:
> Add a mention of the security mailing list to the README, and to
> Documentation/SubmittingPatches.. 2caa7b8d27 ("git manpage: note
> git-secur...@googlegroups.com", 2018-03-08) already added it to the
> man page, but for
On Wed, May 30, 2018 at 09:14:06AM -0700, Stefan Beller wrote:
> Good point. I remember my initial reaction to the file names was expecting
> some hungarian notation, which totally didn't make sense, so I refrained from
> commenting. Searching the web for the algorithm, maybe 'lapjv.c' is
When running the Announce script in a terminal, the git shortlog will
open a pager, which is confusing as it leads to omission of the rest
of the message inside the pager. Do not page the output to avoid confusion.
While at it, add a basic usage example to the header, which illustrates
how it is
Ævar Arnfjörð Bjarmason writes:
> Before this change git will die on any unknown color.ui values:
>
> $ git -c color.ui=doesnotexist show
> fatal: bad numeric config value 'doesnotexist' for 'color.ui': invalid
> unit
I do not think "unit" is correct, so there may be some room for
Ævar Arnfjörð Bjarmason writes:
> A co-worker of mine who was using UNIX systems when dinosaurs roamed
> the earth was lamenting that kids these days were using tools like
> "git" that thought they knew better than isatty(3) when deciding
> whether or not something was a terminal, and the state
On Wed, May 30, 2018 at 2:06 PM, Ævar Arnfjörð Bjarmason
wrote:
> Before this change git will die on any unknown color.ui values:
>
> $ git -c color.ui=doesnotexist show
> fatal: bad numeric config value 'doesnotexist' for 'color.ui': invalid
> unit
>
> This makes the failure mode of
Derrick Stolee writes:
> The 'verify' subcommand must compare the commit content parsed from the
> commit-graph and compare it against the content in the object database.
You have "compare" twice in the above sentence.
> Use lookup_commit() and parse_commit_in_graph_one() to parse the commits
On Wed, May 30, 2018 at 11:54:27AM +0200, Johannes Schindelin wrote:
> > + git checkout -b third B &&
> > + test_tick &&
> > + test_commit I &&
>
> The test_tick before test_commit is unnecessary.
You're right, it is. Will fix.
> > + third=$(git rev-parse HEAD) &&
> > + git checkout
Hi Derrick,
> I went through the whole series and didn't find any issue with the code. The
> commit messages reference coccinelle scripts that I never saw, so those
> should be struck from the messages.
I fixed this locally. I'll wait for more reviews to resend though.
>
> If anyone else plans
On Wed, May 30, 2018 at 5:03 PM, Stefan Beller wrote:
> On Wed, May 30, 2018 at 1:44 PM, Eric Sunshine
> wrote:
>>> Unrelated to this patch: how does this series cope with range diffs
>>> that are not in commit-ish but patches on the file system?
>>
>> I'm not following. Can you provide a
Change the documentation added when color.ui=auto was made the default
in 4c7f1819b3 ("make color.ui default to 'auto'", 2013-06-10) to
describe "auto" as kicking in when writing to the terminal or a pager,
not just to the terminal.
I had someone ask me why it was that git was writing colors with
Ever since b982592d66 ("git-status: document colorization config
options", 2006-09-11) we've slowly been accumulating more and more
color.* options, where the documentation for each new one has
seemingly been copy/pasted with minor adjustments from the last.
This has resulted in documentation
Before this change git will die on any unknown color.ui values:
$ git -c color.ui=doesnotexist show
fatal: bad numeric config value 'doesnotexist' for 'color.ui': invalid unit
This makes the failure mode of introducing any new values in the
future really bad, as explained in the
A co-worker of mine who was using UNIX systems when dinosaurs roamed
the earth was lamenting that kids these days were using tools like
"git" that thought they knew better than isatty(3) when deciding
whether or not something was a terminal, and the state of the
documentation fixed earlier in this
I started writing this for the reasons explained in 4/4, but the
justification there is a bit of a stretch. Where we'd realistically
like to diverge color.ui=auto and color.pager=false, but since I wrote
it already maybe some people will come out of the woodworks telling me
that this is what
On Wed, May 30, 2018 at 1:44 PM, Eric Sunshine wrote:
>> Unrelated to this patch: how does this series cope with range diffs
>> that are not in commit-ish but patches on the file system?
>
> I'm not following. Can you provide a concrete example to get me up to speed?
I was just wondering if
Use names instead of numbers for the AsciiDoc attributes that are used
for the footnotes. We will add more footnotes in subsequent commits,
and attributes should ideally all be unique. Having named attributes
will help ensure uniqueness, and we won't have to re-number the
attributes if we add a
Add a mention of the security mailing list to the README, and to
Documentation/SubmittingPatches.. 2caa7b8d27 ("git manpage: note
git-secur...@googlegroups.com", 2018-03-08) already added it to the
man page, but for developers either the README, or the documentation
on how to contribute
On Wed, May 30, 2018 at 3:03 PM, Stefan Beller wrote:
> On Wed, May 30, 2018 at 1:03 AM, Eric Sunshine
> wrote:
>> The --range-diff option introduces the embedded range-diff generically
>> as "Changes since previous version:", however, we can do better when
>> --reroll-count is specified by
On Wed, May 30, 2018 at 2:58 PM, Stefan Beller wrote:
> On Wed, May 30, 2018 at 1:03 AM, Eric Sunshine
> wrote:
>> When submitting a revised a patch series, the --range-diff option embeds
>> a range-diff in the cover letter showing changes since the previous
>> version of the patch series. The
On Wed, May 30, 2018 at 12:48 PM, John Meyer wrote:
> Ran the installer, selected the option to not modify the path & the path was
> modified anyway... it removed git from the path (it was there from a prior
> install). I should NOT have to manually fix my path after an update, even
> the
Ran the installer, selected the option to not modify the path & the path was
modified anyway... it removed git from the path (it was there from a prior
install). I should NOT have to manually fix my path after an update, even the
option to add git to the path should be smart enough to
Derrick Stolee writes:
> In the 'verify' subcommand, load commits directly from the object
> database to ensure they exist. Parse by skipping the commit-graph.
All right, before we check that the commit data matches, we need to
check that all the commits in cache (in the serialized commit
On 5/29/2018 11:18 PM, Stefan Beller wrote:
On Tue, May 29, 2018 at 6:05 PM, Derrick Stolee wrote:
On 5/29/2018 8:47 PM, Stefan Beller wrote:
This applies on the merge of nd/commit-util-to-slab and
sb/object-store-grafts,
and is available at http://github.com/stefanbeller/ as branch
On Wed, May 30, 2018 at 1:03 AM, Eric Sunshine wrote:
> The --range-diff option introduces the embedded range-diff generically
> as "Changes since previous version:", however, we can do better when
> --reroll-count is specified by emitting "Changes since v{n}:" instead.
A very similar option
On 5/29/2018 8:48 PM, Stefan Beller wrote:
The realloc counter is declared outside the struct for the given slabname,
which makes it harder for a follow up patch to move the declaration of the
struct around as then the counter variable would need special treatment.
As the reallocation counter
On Wed, May 30, 2018 at 1:03 AM, Eric Sunshine wrote:
> When submitting a revised a patch series, the --range-diff option embeds
> a range-diff in the cover letter showing changes since the previous
> version of the patch series. The argument to --range-diff is a simple
> revision naming the tip
On Wed, May 30, 2018 at 7:32 PM, Stefan Beller wrote:
> * the setup code for commands that do not have the
> NEED_WORK_TREE flag in git.c
Unless it's very urgent, I can fix it later (and hopefully soon-ish).
The problem is definitely not with setting core.worktree but with too
eagerly chdir()
On 5/29/2018 8:47 PM, Stefan Beller wrote:
Add a repository argument to allow the callers of lookup_blob
to be more specific about which repository to act on. This is a small
mechanical change; it doesn't change the implementation to handle
repositories other than the_repository yet.
As with
On 5/29/2018 8:47 PM, Stefan Beller wrote:
Add a repository argument to allow the callers of parse_object_buffer
to be more specific about which repository to act on. This is a small
mechanical change; it doesn't change the implementation to handle
repositories other than the_repository yet.
As
On 5/29/2018 8:47 PM, Stefan Beller wrote:
From: Jonathan Nieder
Add a repository argument to allow callers of lookup_unknown_object to
be more specific about which repository to handle. This is a small
mechanical change; it doesn't change the implementation to handle
repositories other than
On Wed, May 30, 2018 at 1:12 AM, mana vortex wrote:
> Hello git folks,
> I’m writing about something that annoys me since forever: The reference
> handling is not consistent between commands. For example, I do
>
> git checkout origin master
$ git checkout origin master
error: pathspec
On Wed, 30 May 2018, Stefan Beller wrote:
> On Wed, May 30, 2018 at 4:39 AM, Robert P. J. Day
> wrote:
> >
> > willing to submit some patches to standardize the syntax of man
> > pages in terms of rendering "optional" and/or "replaceable"
> > content, and it seems like "man git-config" would
On Wed, May 30, 2018 at 4:39 AM, Robert P. J. Day wrote:
>
> willing to submit some patches to standardize the syntax of man
> pages in terms of rendering "optional" and/or "replaceable" content,
> and it seems like "man git-config" would be a good place to start:
>
> SYNOPSIS
>git
On Wed, May 30, 2018 at 10:16 AM, David Turner wrote:
> I am doing a funny thing where I do git -C .git/modules/morx push
> fleem:fleem.
I can do that, too. :)
> This is failing in the case where I have a sparse
> checkout and the worktree directory "morx" (which is where
>
I am doing a funny thing where I do git -C .git/modules/morx push
fleem:fleem. This is failing in the case where I have a sparse
checkout and the worktree directory "morx" (which is where
.git/modules/morx/config's core.worktree points) doesn't exist.
I don't know why git push cares about the
'item->dst' has not been assigned if '!rhs' is true. As the caller is allowed
to pass in uninitialized
memory (we don't assume 'item' was zeroed out before calling), this fixes an
access to
uninitialized memory.
Signed-off-by: Stefan Beller
---
applies on bw/refspec-api
refspec.c | 2 +-
1
Signed-off-by: Stefan Beller
---
This was an oversight in 01caf20d57a (load_contents(): don't try to mmap an
empty file, 2018-01-24).
This and the following 2 patches apply on master.
refs/packed-backend.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/refs/packed-backend.c
Signed-off-by: Stefan Beller
---
This was a deliberate oversight in f241ff0d0a9 (prepare the builtins for a
libified merge_recursive(), 2016-07-26)
sequencer.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/sequencer.c b/sequencer.c
index 72b4d8ecae3..5c93586cc1c 100644
Signed-off-by: Stefan Beller
---
builtin/submodule--helper.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c
index 7c3cd9dbeba..96024fee1b1 100644
--- a/builtin/submodule--helper.c
+++ b/builtin/submodule--helper.c
@@ -63,6 +63,7 @@
On Wed, May 30, 2018 at 9:27 AM, Duy Nguyen wrote:
> On Wed, May 30, 2018 at 8:38 AM, Junio C Hamano wrote:
>> * sb/object-store-alloc (2018-05-16) 13 commits
>> - alloc: allow arbitrary repositories for alloc functions
>> - object: allow create_object to handle arbitrary repositories
>> -
On Wed, May 30, 2018 at 8:38 AM, Junio C Hamano wrote:
> * sb/object-store-alloc (2018-05-16) 13 commits
> - alloc: allow arbitrary repositories for alloc functions
> - object: allow create_object to handle arbitrary repositories
> - object: allow grow_object_hash to handle arbitrary
On 5/30/2018 9:34 AM, Jakub Narebski wrote:
Derrick Stolee writes:
In the commit-graph file, the OID fanout chunk provides an index into
the OID lookup. The 'verify' subcommand should find incorrect values
in the fanout.
Similarly, the 'verify' subcommand should find out-of-order values in
On Wed, May 30, 2018 at 6:55 AM, SZEDER Gábor wrote:
>> The Jonker-Volgenant algorithm was implemented to answer questions such
>> as: given two different versions of a topic branch (or iterations of a
>> patch series), what is the best pairing of commits/patches between the
>> different
On Wed, May 30, 2018 at 09:09:08AM -0700, Taylor Blau wrote:
> [...]
>
> I have these patches mostly updated on my copy (available at
> https://github.com/ttaylorr/git/compare/tb/grep-column) but am out of
> the office for the next week, so I will polish and send these on June
> 8th.
Ack, that
On Wed, May 30, 2018 at 03:38:09PM +0900, Junio C Hamano wrote:
> * tb/grep-column (2018-05-14) 7 commits
> - contrib/git-jump/git-jump: jump to match column in addition to line
> - grep.c: add configuration variables to show matched option
> - builtin/grep.c: add '--column' option to
On 5/27/2018 6:55 PM, Jakub Narebski wrote:
Derrick Stolee writes:
If the commit-graph file becomes corrupt, we need a way to verify
that its contents match the object database. In the manner of
'git fsck' we will implement a 'git commit-graph verify' subcommand
to report all issues with the
On Fri, May 25, 2018 at 12:48:42PM +0200, Łukasz Stelmach wrote:
> "git remote update" accepts both groups and single remotes.
>
> Signed-off-by: Łukasz Stelmach
> ---
> contrib/completion/git-completion.bash | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
> The Jonker-Volgenant algorithm was implemented to answer questions such
> as: given two different versions of a topic branch (or iterations of a
> patch series), what is the best pairing of commits/patches between the
> different versions?
>
> Signed-off-by: Johannes Schindelin
> ---
>
Derrick Stolee writes:
> In the commit-graph file, the OID fanout chunk provides an index into
> the OID lookup. The 'verify' subcommand should find incorrect values
> in the fanout.
>
> Similarly, the 'verify' subcommand should find out-of-order values in
> the OID lookup.
O.K., the OID Lookup
For consistency, use backquotes when referring to environment
variables, as is done in other man pages.
Signed-off-by: Robert P. J. Day
---
diff --git a/Documentation/git-p4.txt b/Documentation/git-p4.txt
index b0abe2cb0..004944b3c 100644
--- a/Documentation/git-p4.txt
+++
> diff --git a/commit-graph.c b/commit-graph.c
> index d2b291aca2..a33600c584 100644
> --- a/commit-graph.c
> +++ b/commit-graph.c
> @@ -841,6 +841,7 @@ void write_commit_graph(const char *obj_dir,
> oids.nr =3D 0;
> }
> =20
> +#define VERIFY_COMMIT_GRAPH_ERROR_HASH 2
> static int
Signed-off-by: Robert P. J. Day
---
i am simply assuming that that really should say "inconsistent"; if
it's actually correct, just toss this, of course.
diff --git a/builtin/config.c b/builtin/config.c
index 1e31aa9f8..11c9c501d 100644
--- a/builtin/config.c
+++ b/builtin/config.c
@@
willing to submit some patches to standardize the syntax of man
pages in terms of rendering "optional" and/or "replaceable" content,
and it seems like "man git-config" would be a good place to start:
SYNOPSIS
git config [] [type] [--show-origin] [-z|--null] name
[value [value_regex]]
On Wed, May 30 2018, Robert P. J. Day wrote:
> just want to clarify a few things about hooks to make sure i'm not
> missing anything when i write my own hooks tutorial.
>
> first, for any hook to be active, it *must* be marked as executable
> -- that much seems clear from the man page.
just want to clarify a few things about hooks to make sure i'm not
missing anything when i write my own hooks tutorial.
first, for any hook to be active, it *must* be marked as executable
-- that much seems clear from the man page.
next, "core.hooksPath" aside, the hooks related to any
On 30 May 2018 at 08:00, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Jeff King writes:
>>
>>> But most importantly, it means we could eventually colorize errors, too,
>>> where we are not allowed to allocate.
>>>
>>> So perhaps:
>>>
>>> void report_lines(FILE *out,
>>>
On 29 May 2018 at 23:32, Jeff King wrote:
> On Mon, May 28, 2018 at 06:25:18PM +0900, Junio C Hamano wrote:
>
>> This shows the typical effect of this series, which (I subjectively
>> think) gives us a more pleasant end-user experience.
>
> Heh, that is one of the cases that I found most ugly
On 29 May 2018 at 17:50, Duy Nguyen wrote:
> On Tue, May 29, 2018 at 6:49 AM, Martin Ågren wrote:
>> On 28 May 2018 at 23:45, Junio C Hamano wrote:
>>> Duy Nguyen writes:
>>>
>> +error: sub/added
>> +error: sub/addedtoo
>> +error: Please move or remove them before you
Hi Brian,
On Tue, 29 May 2018, brian m. carlson wrote:
> When writing the todo script for --rebase-merges, we try to find a label
> for certain commits. If the label ends up being a valid object ID, such
> as when we merge a detached commit, we want to rewrite it so it is no
> longer a valid
On Wed, May 30 2018, Eric Sunshine wrote:
> * The final name for the 'tbdiff' replacement has not yet been nailed
> down. The name git-branch-diff is moribund[2]; Dscho favors merging
> the functionality into git-branch as a new --diff option[3]; others
> prefer a standalone command named
On Tue, May 29, 2018 at 1:30 AM, wrote:
> If the -L option is used to specify a line range in git log, and the end
> of the range is past the end of the file, git will fail with a fatal
> error. This commit prevents such behaviour - instead we perform the log
> for existing lines within the
On Tue, May 29, 2018 at 1:30 AM, wrote:
> If the -L option is used to specify a line range in git blame, and the
> end of the range is past the end of the file, git will fail with a fatal
> error. This commit prevents such behavior - instead we display the blame
> for existing lines within the
On 30/05/2018 00:04, Jeff King wrote:
Do we even need to do the parent rewriting here? By definition those
parents aren't interesting, and we're TREESAME to whatever is in
treesame_parents. So conceptually it seems like we just need a flag "I
found a treesame parent", but we only convert that
Hello git folks,
I’m writing about something that annoys me since forever: The
reference handling is not consistent between commands. For example, I do
git checkout origin master
but I do
git reset —hard origin/master
I always get it wrong the first time.
Is there a convenience option that
When submitting a revised version of a patch series, it can be helpful
(to reviewers) to include a summary of changes since the previous
attempt in the form of an interdiff or range-diff, however, doing so
involves manually copy/pasting the diff into the cover letter.
Add a --range-diff option to
When generating a range-diff, matching up commits between two version of
a patch series involves heuristics, thus may give unexpected results.
git-branch-diff allows tweaking the heuristic via --creation-weight.
Follow suit by accepting --creation-weight in combination with
--range-diff when
The --range-diff option introduces the embedded range-diff generically
as "Changes since previous version:", however, we can do better when
--reroll-count is specified by emitting "Changes since v{n}:" instead.
Signed-off-by: Eric Sunshine
---
builtin/log.c | 6 +-
1 file changed, 5
When submitting a revised a patch series, the --range-diff option embeds
a range-diff in the cover letter showing changes since the previous
version of the patch series. The argument to --range-diff is a simple
revision naming the tip of the previous series, which works fine if the
previous and
make_cover_letter() returns early when it lacks sufficient state to emit
a diffstat, which makes it difficult to extend the function to reliably
emit additional generated content. Work around this shortcoming by
factoring diffstat-printing logic out to its own function and calling it
as needed
Dscho recently implemented a 'tbdiff' replacement as a Git builtin named
git-branch-diff[1] which computes differences between two versions of a
patch series. Such a diff can be a useful aid for reviewers when
inserted into a cover letter. However, doing so requires manual
generation (invoking
Hi, Eduardo
On 05/29, Eduardo Habkost wrote:
>Hi,
>
>I'm trying to use git-format-patch --base to generate the list of
>prerequisite patches for a series, but the behavior of git
>doesn't seem to match the documentation:
>
>When using a commit count (e.g.: "-2"), git-format-patch generates the
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
The recent fixes in v2.17.1 and
Junio C Hamano writes:
> Jeff King writes:
>
>> But most importantly, it means we could eventually colorize errors, too,
>> where we are not allowed to allocate.
>>
>> So perhaps:
>>
>> void report_lines(FILE *out,
>> const char *color, const char *color_reset,
>>
89 matches
Mail list logo
