Re: enhancement: support for author.email and author.name in "git config"

Hi William, On Thu, 6 Dec 2018 at 19:18, William Hubbs wrote: > We are in a situation where we would like to use author information that is > different from committer information when we commit to certain > repositories. [...] > [...] I would like to propose the addition of author.email and >

[PATCH v2 2/3] RelNotes 2.20: clarify sentence

I had to read this sentence a few times to understand it. Let's try to clarify it. Signed-off-by: Martin Ågren --- Documentation/RelNotes/2.20.0.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/RelNotes/2.20.0.txt b/Documentation/RelNotes/2.20.0.txt index

[PATCH v2 3/3] RelNotes 2.20: drop spurious double quote

We have three double-quote characters, which is one too many or too few. Dropping the last one seems to match the original intention best. Signed-off-by: Martin Ågren --- Documentation/RelNotes/2.20.0.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/RelNotes

[PATCH v2 1/3] RelNotes 2.20: move some items between sections

Some items that should be in "Performance, Internal Implementation, Development Support etc." have ended up in "UI, Workflows & Features". Move them, and do s/uses/use/ while at it. Signed-off-by: Martin Ågren --- Documentation/RelNotes/2.20.0.txt | 10 +- 1 fi

Re: [PATCH 1/3] RelNotes 2.20: move some items between sections

On Tue, 4 Dec 2018 at 03:23, Junio C Hamano wrote: > > Martin Ågren writes: > > > Some items that should be in "Performance, Internal Implementation, > > Development Support etc." have ended up in "UI, Workflows & Features" > > and "

Re: [PATCH v3] range-diff: always pass at least minimal diff options

On Mon, 3 Dec 2018 at 22:21, Eric Sunshine wrote: > [es: retain diff coloring when going to stdout] > > Signed-off-by: Martin Ågren > Signed-off-by: Eric Sunshine > --- > > This is a re-roll of Martin's v2[1]. The only difference from v2 is that > it retain

Re: [PATCH] rebase docs: fix incorrect format of the section Behavioral Differences

On Mon, 3 Dec 2018 at 18:35, Johannes Sixt wrote: > I actually did not test the result, because I don't have the > infrastructure. I've tested with asciidoc and Asciidoctor, html and man-page. Looks good. Martin

[PATCH 1/3] RelNotes 2.20: move some items between sections

Some items that should be in "Performance, Internal Implementation, Development Support etc." have ended up in "UI, Workflows & Features" and "Fixes since v2.19". Move them, and do s/uses/use/ while at it. Signed-off-by: Martin Ågren --- Docu

[PATCH 2/3] RelNotes 2.20: clarify sentence

I had to read this sentence a few times to understand it. Let's try to clarify it. Signed-off-by: Martin Ågren --- Documentation/RelNotes/2.20.0.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/RelNotes/2.20.0.txt b/Documentation/RelNotes/2.20.0.txt index

[PATCH 0/3] Re: [ANNOUNCE] Git v2.20.0-rc2

. Nothing critical. Martin Martin Ågren (3): RelNotes 2.20: move some items between sections RelNotes 2.20: clarify sentence RelNotes 2.20: drop spurious double quote Documentation/RelNotes/2.20.0.txt | 30 +++--- 1 file changed, 15 insertions(+), 15 deletions(-) -- 2.2

[PATCH 3/3] RelNotes 2.20: drop spurious double quote

We have three double-quote characters, which is one too many or too few. Dropping the last one seems to match the original intention best. Signed-off-by: Martin Ågren --- Documentation/RelNotes/2.20.0.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/RelNotes

[PATCH v2] range-diff: always pass at least minimal diff options

sn't actually dead and we've broken 2.20, just leave it for now. Signed-off-by: Martin Ågren --- Here's another attempt at fixing this recent regression. t/t3206-range-diff.sh | 20 +--- builtin/log.c | 13 - log-tree.c| 13 - 3 file

Re: [PATCH] format-patch: do not let its diff-options affect --range-diff (was Re: [PATCH 2/2] format-patch: allow for independent diff & range-diff options)

as part of this commit, or separately, once we've cut 2.20. * The range-diff is written colored regardless of destination, i.e., when written to a file, it contains garbage. Signed-off-by: Martin Ågren --- builtin/log.c | 12 +++- log-tree.c| 12 +++- 2 files chang

Re: [PATCH 1/2] git-reset.txt: render tables correctly under Asciidoctor

On Wed, 28 Nov 2018 at 20:45, Ævar Arnfjörð Bjarmason wrote: > On Wed, Nov 28 2018, Martin Ågren wrote: > > > Asciidoctor removes the indentation of each line in these tables, so the > > last lines of each table have a completely broken alignment. > > Earlier I was trying

[PATCH 1/2] git-reset.txt: render tables correctly under Asciidoctor

his commit, both for git-reset.1 and git-reset.html. Reported-by: Paweł Samoraj Signed-off-by: Martin Ågren --- Documentation/git-reset.txt | 140 1 file changed, 78 insertions(+), 62 deletions(-) diff --git a/Documentation/git-reset.txt b/Documentation/git

[PATCH 0/2] Re: Broken alignment in git-reset docs

On Wed, 28 Nov 2018 at 13:02, Martin Ågren wrote: > > On Wed, 28 Nov 2018 at 12:42, Paweł Samoraj wrote: > > > > The git-reset documentation page section which is accessible via URL > > https://git-scm.com/docs/git-reset#_discussion is not looking good. > &g

[PATCH 2/2] git-reset.txt: render literal examples as monospace

Large parts of this document do not use `backticks` around literal examples such as branch names (`topic/wip`), git usages, `HEAD` and `` so they render as ordinary text. Fix that. Signed-off-by: Martin Ågren --- Documentation/git-reset.txt | 131 ++-- 1 file

Re: Broken alignment in git-reset docs

On Wed, 28 Nov 2018 at 12:42, Paweł Samoraj wrote: > > Hi! > The git-reset documentation page section which is accessible via URL > https://git-scm.com/docs/git-reset#_discussion is not looking good. > [snip] > > The web archive has got a snapshot from 2014-06-28 when it was ok >

Re: [PATCH v16 Part II 2/8] bisect--helper: `bisect_write` shell function in C

On Fri, 23 Nov 2018 at 11:13, Johannes Schindelin wrote: > On Mon, 30 Oct 2017, Pranit Bauva wrote: > > > On Fri, Oct 27, 2017 at 10:58 PM, Martin Ågren > > wrote: > > > On 27 October 2017 at 17:06, Pranit Bauva wrote: > > >> +static voi

Re: [PATCH v2 1/1] bundle: cleanup lock files on error

On Wed, 14 Nov 2018 at 16:26, Gaël Lhez via GitGitGadget wrote: > However, the `.lock` file was still open and on Windows that means > that it could not be deleted properly. This patch fixes that issue. Hmmm, doesn't the tempfile machinery remove the lock file when we die? > ref_count =

Re: [PATCH] coccicheck: introduce 'pending' semantic patches

On Sat, 10 Nov 2018 at 01:10, Stefan Beller wrote: > I dialed back on the workflow, as we may want to explore it first > before writing it down. Makes sense. FWIW, this iteration looks good to me. Martin

Re: [PATCH] Makefile: add pending semantic patches

On Thu, 8 Nov 2018 at 21:53, Stefan Beller wrote: > > From: SZEDER Gábor > I haven't followed the original discussion too carefully, so I'll read this like someone new to the topic probably would. A nit, perhaps, but I was genuinely confused at first. The subject is "Makefile: add pending

Re: [PATCH v3 1/2] range-diff doc: add a section about output stability

On Wed, 7 Nov 2018 at 13:22, Ævar Arnfjörð Bjarmason wrote: > + > +This is particularly true when passing in diff options. Currently some > +options like `--stat` can as an emergent effect produce output that's > +quite useless in the context of `range-diff`. Future versions of > +`range-diff`

Re: [PATCH v2] sequencer: break out of loop explicitly

On Wed, 31 Oct 2018 at 18:28, Eric Sunshine wrote: > > On Wed, Oct 31, 2018 at 10:54 AM Johannes Schindelin > wrote: > > ACK. Thanks for cleaning up after me, > > Looks good to me, as well. Thanks for working on it. Thanks, both of you. Martin

[PATCH v2] sequencer: break out of loop explicitly

`i`. [1] https://public-inbox.org/git/CAPig+cQbG2s-LrAo9+7C7=dXifbWFJ3SzuNa-QePHDk7egK=j...@mail.gmail.com/ [2] https://public-inbox.org/git/capig+crju6nixpt2frdwz0x1hmgf1ojvzj3uk2qxege-s7i...@mail.gmail.com/ Helped-by: Eric Sunshine Signed-off-by: Martin Ågren --- Thanks for the comments on

Re: [PATCH] sequencer: clarify intention to break out of loop

On Sun, 28 Oct 2018 at 20:01, Eric Sunshine wrote: > > On Sun, Oct 28, 2018 at 11:32 AM Martin Ågren wrote: > > [...] > > Let's be explicit about breaking out of the loop. This helps the > > compiler grok our intention. As a bonus, it might make it (even) more >

[PATCH] sequencer: clarify intention to break out of loop

`INT_MAX` before that step, which it can't have had. Let's be explicit about breaking out of the loop. This helps the compiler grok our intention. As a bonus, it might make it (even) more obvious to human readers that the loop stops at the first space. While at it, reduce the scope of

[PATCH v2 2/3] builtin/commit-graph.c: UNLEAK variables

in situations like this. But since we are about to exit, let's just UNLEAK the whole string list instead. UNLEAK `graph` in `graph_verify`. While at it, and for consistency, UNLEAK in `graph_read()` as well, and remove an unnecessary UNLEAK just before dying. Signed-off-by: Martin Ågren Signed-off

Re: [PATCH 0/2] commit-graph: more leak fixes

On Wed, 3 Oct 2018 at 18:19, Derrick Stolee wrote: > I'm fine with squashing it in with both our sign-offs. It is the same > idea, it just requires a different set of arguments to hit it. I'll > adjust the commit message as necessary. > I'll add your PATCH 2/2 to my v2. Thanks! Cool, thanks a

[PATCH 0/2] commit-graph: more leak fixes

of this posting, I'll follow through as appropriate. Martin Martin Ågren (2): commit-graph: free `struct packed_git` after closing it builtin/commit-graph.c: UNLEAK variables builtin/commit-graph.c | 11 ++- commit-graph.c | 1 + 2 files changed, 7 insertions(+), 5 deletions

[PATCH 2/2] builtin/commit-graph.c: UNLEAK variables

to exit, let's just UNLEAK the whole string list instead. UNLEAK `graph` in `graph_verify`. While at it, and for consistency, UNLEAK in `graph_read()` as well, and remove an unnecessary UNLEAK just before dying. Signed-off-by: Martin Ågren --- builtin/commit-graph.c | 11 ++- 1 file

[PATCH 1/2] commit-graph: free `struct packed_git` after closing it

`close_pack(p)` does not free the memory which `p` points to, so follow up with a call to `free(p)`. All other users of `close_pack()` look ok. Signed-off-by: Martin Ågren --- commit-graph.c | 1 + 1 file changed, 1 insertion(+) diff --git a/commit-graph.c b/commit-graph.c index 3d644fddc0

Re: [PATCH 3/5] diff --color-moved-ws: fix a memory leak

On Tue, 2 Oct 2018 at 20:04, Phillip Wood wrote: > const struct emitted_diff_symbol *longer = a->len > b->len ? a : b; > const struct emitted_diff_symbol *shorter = a->len > b->len ? b : a; > int d = longer->len - shorter->len; > + int ret = !strncmp(longer->line +

Re: [PATCH 1/2] commit-graph: clean up leaked memory during write

On Tue, 2 Oct 2018 at 19:59, Stefan Beller wrote: > > > + > > > + string_list_clear(, 0); > > > } > > > > Nit: The blank line adds some asymmetry, IMVHO. > > I think these blank lines are super common, as in: > > { > declarations; > > multiple; > lines(of); >

Re: [PATCH 1/2] commit-graph: clean up leaked memory during write

itizer and valgrind, I don't need this hunk to be leak-free. Generally speaking, it seems impossible to UNLEAK when dying, since we don't know what we have allocated higher up in the call-stack. Without this hunk, this patch can have my Reviewed-by: Martin Ågren as I've verified the leaks before and a

Re: [PATCH] Documentation/CodingGuidelines: How to document new APIs

On Fri, 28 Sep 2018 at 18:51, Junio C Hamano wrote: > We recommend documenting in the header over documenting near the > implementation to encourage people to write the docs that are > readable without peeking at the implemention. s/implemention/implementation/ > - - When you come up with an

[PATCH] t1400: drop debug `echo` to actually execute `test`

Instead of running `test "foo" = "$(bar)"`, we prefix the whole thing with `echo`. Comparing to nearby tests makes it clear that this is just debug leftover. This line has actually been modified four times since it was introduced in e52290428b (General ref log reading improvements., 2006-05-19)

Re: [PATCH v2 0/4] git-commit-graph.txt: various cleanups

Hi Derrick On Thu, 27 Sep 2018 at 21:16, Derrick Stolee wrote: > Thanks! This version satisfies my concerns and looks good to me. > > Reviewed-by: Derrick Stolee Thanks for the spectacularly snappy review. I don't expect commit graphs to help my use cases a lot, but I still wanted to try them

[PATCH v2 1/4] git-commit-graph.txt: fix bullet lists

We have a couple of bullet items which span multiple lines, and where we have prefixed each line with a `*`. (This might be the result of a text editor trying to help.) This results in each line being typeset as a separate bullet item. Drop the extra `*`. Signed-off-by: Martin Ågren

[PATCH v2 4/4] Doc: refer to the "commit-graph file" with dash

them. Do not change the references to the "commit graph" (without "... file") as a data structure. Signed-off-by: Martin Ågren --- Documentation/git-commit-graph.txt | 12 ++-- Documentation/technical/commit-graph.txt | 8 2 files changed, 10 insertions(+), 10

[PATCH v2 2/4] git-commit-graph.txt: typeset more in monospace

While we're here, fix an instance of "folder" to be "directory". Signed-off-by: Martin Ågren --- Documentation/git-commit-graph.txt | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/Documentation/git-commit-graph.txt b/Documentation/git-co

[PATCH v2 0/4] git-commit-graph.txt: various cleanups

This v2 starts with the same two patches as v1 did, then goes on to change "[commit] graph file" to "commit-graph file" with a dash, to match other instances as well as Derrick's feedback. Martin Ågren (4): git-commit-graph.txt: fix bullet lists git-commit-graph.txt: types

[PATCH v2 3/4] git-commit-graph.txt: refer to "*commit*-graph file"

graph files. Let's just write out the full name everywhere. The full name, by the way, is not the dash-less "commit graph file". Use the dashed form. (The next commit will fix the remaining few instances of the "commit graph file" in this document.) Signed-off-by: Martin Ågren

Re: [PATCH v2] git.txt: mention mailing list archive

Hey On Thu, 27 Sep 2018 at 08:37, Jonathan Nieder wrote: > Martin Ågren wrote: > > > --- a/Documentation/git.txt > > +++ b/Documentation/git.txt > > @@ -859,6 +859,9 @@ Reporting Bugs > > Report bugs to the Git mailing list where the > > development and ma

[PATCH v2] git.txt: mention mailing list archive

hits first. Searching for some keyword about a bug or regression should pretty easily reveal whether it has been recently reported. Helped-by: Junio C Hamano Signed-off-by: Martin Ågren --- Thanks Junio and Taylor for thoughts on this. I agree we do not want to scare anyone away. I hope this does

[PATCH] t7005-editor: quote filename to fix whitespace-issue

s redirect". More details can be found in [1], thanks to SZEDER Gábor. Make sure that the editor script quotes "$1" to remove the ambiguity. [1] https://public-inbox.org/git/20180926121107.GH27036@localhost/ Signed-off-by: Alexander Pyhalov Commit-message-by: Martin Ågren Signed-o

Re: t7005-editor.sh failure

On Wed, 26 Sep 2018 at 13:59, Eric Sunshine wrote: > This description of the behavior is misleading (actually, actively > wrong). Hmm, that's bad, my apologies. > echo foo bar >cow > echo >cow foo bar > echo foo >cow bar > > That is, they all create a file named "cow" with content

Re: t7005-editor.sh failure

On Wed, 26 Sep 2018 at 11:00, Alexander Pyhalov wrote: > As for sign-off, do I understand correctly that you just want to know > that I'm the original author of the code? Yes, it's so. Right. Plus that you agree that the code (the commit) may be redistributed basically forever. > I see this on

Re: [PATCH] git.txt: mention mailing list archive

On Thu, 20 Sep 2018 at 21:07, Junio C Hamano wrote: > > Martin Ågren writes: > > > In the "Reporting Bugs" section of git(1), we refer to the mailing list, > > but we do not give any hint about where the archives might be found. > > And why is it a good idea

Re: t7005-editor.sh failure

Hi Alexander, Welcome to the list! On Wed, 26 Sep 2018 at 08:54, Alexander Pyhalov wrote: > On updating git to 2.19 we've suddenly got t7005-editor.sh test failures. > The issue seems to be that generated "e space.sh" file can't handle > files with spaces. > Instead of 'echo space >$1' it

Re: [PATCH 3/4] git-commit-graph.txt: refer to "*commit* graph file"

On Thu, 20 Sep 2018 at 14:50, Derrick Stolee wrote: > > On 9/19/2018 12:30 PM, Martin Ågren wrote: > > The full name, by the way, is not the "commit-graph file" with a dash, > > cf. the synopsis. Use the dashless form. (The next commit will fix the > > remaining

Re: [PATCH 1/9] Makefile: add a hdr-check target

On Wed, 19 Sep 2018 at 22:15, Ramsay Jones wrote: > On 19/09/18 18:49, Martin Ågren wrote: > > On Wed, 19 Sep 2018 at 02:07, Ramsay Jones > > wrote: > >> +GEN_HDRS := command-list.h unicode-width.h > > > > Most of the things happening around here are ob

Re: [PATCH] gc: fix regression in 7b0f229222 impacting --quiet

On Wed, 19 Sep 2018 at 23:04, Ævar Arnfjörð Bjarmason wrote: > Fix a regression in my recent 7b0f229222 ("commit-graph write: add > progress output", 2018-09-17), the newly added progress output for > "commit-graph write" didn't check the --quiet option. s/, t/. T/, perhaps. Maybe also

Re: [PATCH] pack-objects: handle island check for "external" delta base

On Wed, 19 Sep 2018 at 05:49, Jeff King wrote: > This is tricky to do inside a single "if" statement. And > after the merge in f3504ea3dd (Merge branch > 'cc/delta-islands', 2018-09-17), that "if" condition is > already getting pretty unwieldy. So this patch moves the > logic into a helper

Re: [PATCH 2/2] git-config.txt: fix 'see: above' note

Hi Taylor, On Wed, 19 Sep 2018 at 19:21, Taylor Blau wrote: > I could take or leave 2/2, since I usually write ", (see: above)", but > I'm not sure if that's grammatically correct or not. Well, I sure ain't no grammar expert too... This is not a patch I feel strongly about, so I'll be happy to

Re: [PATCH 1/9] Makefile: add a hdr-check target

Hi Ramsay, On Wed, 19 Sep 2018 at 02:07, Ramsay Jones wrote: > @@ -2675,6 +2676,17 @@ $(SP_OBJ): %.sp: %.c GIT-CFLAGS FORCE > .PHONY: sparse $(SP_OBJ) > sparse: $(SP_OBJ) > > +GEN_HDRS := command-list.h unicode-width.h Most of the things happening around here are obvious steps towards the

[PATCH] git.txt: mention mailing list archive

Signed-off-by: Martin Ågren --- Documentation/git.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/git.txt b/Documentation/git.txt index 74a9d7edb4..40eaccafb2 100644 --- a/Documentation/git.txt +++ b/Documentation/git.txt @@ -858,7 +858,9 @@ Reporting Bugs

[PATCH 2/2] git-config.txt: fix 'see: above' note

Rather than saying "(see: above)", drop the colon. Also drop the comma before this note. Signed-off-by: Martin Ågren --- Documentation/git-config.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/git-config.txt b/Documentation/git-config

[PATCH 1/2] Doc: use `--type=bool` instead of `--bool`

ready seem to be gone except for in that list of historical options. Tweak the grammar a little in config.txt while we are there. Signed-off-by: Martin Ågren --- Documentation/config.txt | 2 +- Documentation/git-config.txt | 4 ++-- Documentation/git.txt| 2 +- 3 files changed, 4

[PATCH 4/4] git-commit-graph.txt: refer to the "commit graph file" without dash

The command is `git commit-graph`, but the file it processes is the "commit graph file" without a dash. We have a few references to the "commit-graph file", though. Fix them. Signed-off-by: Martin Ågren --- Documentation/git-commit-graph.txt | 6 +++--- 1 file changed

[PATCH 3/4] git-commit-graph.txt: refer to "*commit* graph file"

graph files. Let's just write out the full name everywhere. The full name, by the way, is not the "commit-graph file" with a dash, cf. the synopsis. Use the dashless form. (The next commit will fix the remaining few instances of the "commit-graph file" in this document.) Signed-

[PATCH 1/4] git-commit-graph.txt: fix bullet lists

We have a couple of bullet items which span multiple lines, and where we have prefixed each line with a `*`. (This might be the result of a text editor trying to help.) This results in each line being typeset as a separate bullet item. Drop the extra `*`. Signed-off-by: Martin Ågren

[PATCH 2/4] git-commit-graph.txt: typeset more in monospace

While we're here, fix an instance of "folder" to be "directory". Signed-off-by: Martin Ågren --- Documentation/git-commit-graph.txt | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/Documentation/git-commit-graph.txt b/Documentation/git-co

[PATCH 0/4] git-commit-graph.txt: various cleanups

to be made in other parts of git.git. If the dash should actually be there, I could do these changes in the other direction. Or maybe dash-vs-no-dash is not an actual problem at all... Martin Martin Ågren (4): git-commit-graph.txt: fix bullet lists git-commit-graph.txt: typeset more in monos

Re: git silently ignores include directive with single quotes

Hi Stas On Sat, 8 Sep 2018 at 21:00, Stas Bekman wrote: > [include] > path = '../.gitconfig' > > Notice the single quotes around the filename. When this is the case git > silently (!) ignores the custom configuration, which is clearly a bug. Thanks for reporting and describing out your

Re: [PATCH v3 2/4] eoie: add End of Index Entry (EOIE) extension

On Sat, 8 Sep 2018 at 16:04, Ben Peart wrote: > On 9/8/2018 2:29 AM, Martin Ågren wrote: > > Maybe it all works out, e.g., so that when someone (brian) merges a > > NewHash and runs the testsuite, this will fail consistently and in a > > safe way. But I wonder if it would

Re: [PATCH v3 2/4] eoie: add End of Index Entry (EOIE) extension

On Fri, 7 Sep 2018 at 22:24, Ben Peart wrote: > > Ben Peart writes: > >> - 160-bit SHA-1 over the extension types and their sizes (but not > >> their contents). E.g. if we have "TREE" extension that is N-bytes > >> long, "REUC" extension that is M-bytes long, followed by "EOIE", > >> then the

Re: [PATCH 2/2] submodule.c: warn about missing submodule commit in recursive actions

> + if (repo_submodule_init(, the_repository, path) < 0) > + warning(_("Could not get submodule repository for submodule > 's'"), path); Missing "%" in format specifier, so `path` will never be used. Also, s/C/c/ at the start of the warning. Thanks for marking with _().

Re: [PATCH] diff: allow --recurse-submodules as an synonym for --submodule

On Thu, 6 Sep 2018 at 00:59, Stefan Beller wrote: > > --submodule[=]:: Maybe drop `--submodule` here ... > +--recurse-submodules[=]:: > Specify how differences in submodules are shown. When specifying > `--submodule=short` the 'short' format is used. This format just ... and

Re: [PATCH] Document update for nd/unpack-trees-with-cache-tree

On Sat, 25 Aug 2018 at 14:22, Nguyễn Thái Ngọc Duy wrote: > * Fast path if we detect that all trees are the same as cache-tree at this > - * path. We'll walk these trees recursively using cache-tree/index instead of > - * ODB since already know what these trees contain. > + * path. We'll walk

Re: [PATCH v2] worktree: add --quiet option

Hi Eric, On Thu, 16 Aug 2018 at 10:25, Eric Sunshine wrote: > (/me nudges Martin off the fence onto the side of not bothering to > mention the obvious) :-) Thanks for sanity-checking my thoughts. I agree with everything you wrote in your reply (and, FWIW, your other findings that you sent

Re: [PATCH v2] worktree: add --quiet option

On Wed, 15 Aug 2018 at 22:56, Elia Pinto wrote: > Add the '--quiet' option to git worktree, > as for the other git commands. 'add' is the > only command affected by it since all other > commands, except 'list', are currently > silent by default. Thanks for a follow-up. The word "currently"

Re: [PATCH 10/10] fetch: retry fetching submodules if sha1 were not fetched

On 9 August 2018 at 00:17, Stefan Beller wrote: > Currently when git-fetch is asked to recurse into submodules, it dispatches > a plain "git-fetch -C " (and some submodule related options > such as prefix and recusing strategy, but) without any information of the > remote or the tip that should

Re: [PATCH 03/10] sha1-array: provide oid_array_remove_if

On 9 August 2018 at 00:17, Stefan Beller wrote: > +int oid_array_remove_if(struct oid_array *array, > + for_each_oid_fn fn, > + void *data) > +{ > + int i, j; > + char *to_remove = xcalloc(array->nr, sizeof(char)); Do you really need this

Re: [PATCH 02/10] string-list.h: add string_list_pop function.

On 9 August 2018 at 00:17, Stefan Beller wrote: > A string list can be used as a stack, but should we? A later patch shows > how useful this will be. > > Signed-off-by: Stefan Beller > --- > string-list.c | 8 > string-list.h | 6 ++ > 2 files changed, 14 insertions(+) > > diff

Re: [PATCH] worktree: add --quiet option

Hi Elia On 7 August 2018 at 15:21, Elia Pinto wrote: > Add the '--quiet' option to git worktree add, > as for the other git commands. > > Signed-off-by: Elia Pinto > --- > Documentation/git-worktree.txt | 4 +++- > builtin/worktree.c | 11 +-- > 2 files changed, 12

Re: [PATCH 0/2] Simple fixes to t7406

On 6 August 2018 at 17:25, Elijah Newren wrote: > Changes since v1: > - Simplify multiple tests using diff --name-only instead of diff --raw; > these tests are only interested in which file was modified anyway. > (Suggested by Junio) > - Avoid putting git commands upstream of a pipe,

Re: [PATCH 4/8] gpg-interface: introduce an abstraction for multiple gpg formats

Hi Henning, On 3 July 2018 at 14:38, Henning Schild wrote: > Create a struct that holds the format details for the supported formats. > At the moment that is still just "PGP". This commit prepares for the > introduction of more formats, that might use other programs and match > other signatures.

Re: [PATCH 20/20] abbrev: add a core.validateAbbrev setting

On 9 June 2018 at 00:41, Ævar Arnfjörð Bjarmason wrote: > Instead of trying really hard to find an unambiguous SHA-1 we can with > core.validateAbbrev=false, and preferably combined with the new > support for relative core.abbrev values (such as +4) unconditionally > print a short SHA-1 without

Re: [PATCH 19/20] abbrev: support relative abbrev values

On 9 June 2018 at 00:41, Ævar Arnfjörð Bjarmason wrote: > diff --git a/Documentation/config.txt b/Documentation/config.txt > index ab641bf5a9..abf07be7b6 100644 > --- a/Documentation/config.txt > +++ b/Documentation/config.txt > @@ -919,6 +919,12 @@ core.abbrev:: > in your repository,

Re: [PATCH 17/20] abbrev: unify the handling of empty values

On 9 June 2018 at 16:24, Martin Ågren wrote: > On 9 June 2018 at 00:41, Ævar Arnfjörð Bjarmason wrote: >> For no good reason the --abbrev= command-line option was less strict >> than the core.abbrev config option, which came down to the latter >> using git_config_int() w

Re: [PATCH 17/20] abbrev: unify the handling of empty values

On 9 June 2018 at 00:41, Ævar Arnfjörð Bjarmason wrote: > For no good reason the --abbrev= command-line option was less strict > than the core.abbrev config option, which came down to the latter > using git_config_int() which rejects an empty string, but the rest of > the parsing using strtoul()

Re: [PATCH 09/20] abbrev tests: test for "git-log" behavior

On 9 June 2018 at 11:56, Ævar Arnfjörð Bjarmason wrote: > > On Sat, Jun 09 2018, Martin Ågren wrote: > >> On 9 June 2018 at 00:41, Ævar Arnfjörð Bjarmason wrote: >>> The "log" family of commands does its own parsing for --abbrev in >>> revision.c, s

Re: [PATCH] fsck: avoid looking at NULL blob->object

On 9 June 2018 at 10:32, Jeff King wrote: > Except it _does_ do one non-trivial thing, which is call the > report() function, which wants us to pass a pointer to a > "struct object". Which we don't have (we have only a "struct > object_id"). So we erroneously passed the NULL object, which

Re: [PATCH 09/20] abbrev tests: test for "git-log" behavior

On 9 June 2018 at 00:41, Ævar Arnfjörð Bjarmason wrote: > The "log" family of commands does its own parsing for --abbrev in > revision.c, so having dedicated tests for it makes sense. > +for i in $(test_seq 4 40) I've just been skimming so might have missed something, but I see several

Re: [PATCH 0/3] refspec: refactor & fix free() behavior

into two different patches to make it clear that > all callers of refpsec_item_init relying on dieing. Me too. >> Martin Ågren (1): >> refspec: initalize `refspec_item` in `valid_fetch_refspec()` I was a bit surprised at first that this wasn't a "while at it" in the second pat

Re: [PATCH] refspec: initalize `refspec_item` in `valid_fetch_refspec()`

On 4 June 2018 at 23:55, Ævar Arnfjörð Bjarmason wrote: > I think this makes more sense instead of this fix: [...] > -void refspec_item_init(struct refspec_item *item, const char *refspec, int > fetch) > +int refspec_item_init(struct refspec_item *item, const char *refspec, int > fetch) > { >

[PATCH] refspec: initalize `refspec_item` in `valid_fetch_refspec()`

by calling `valid_fetch_refspec(":*")`. Zero the struct, as is done in other users of `struct refspec_item`. Signed-off-by: Martin Ågren --- I found some time to look into this. It does not seem to be a user-visible bug, so not particularly critical. refspec.c | 5 - 1 file changed, 4 inser

Re: [PATCH v2 05/36] refspec: convert valid_fetch_refspec to use parse_refspec

Hi Brandon, On 17 May 2018 at 00:57, Brandon Williams wrote: > Convert 'valid_fetch_refspec()' to use the new 'parse_refspec()' > function to only parse a single refspec and eliminate an allocation. > > Signed-off-by: Brandon Williams > --- > refspec.c | 17 - > refspec.h | 3

Re: [RFC PATCH 1/3] usage: extract `prefix_suffix_lines()` from `advise()`

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, >>>

Re: [RFC PATCH 2/3] usage: prefix all lines in `vreportf()`, not just the first

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

Re: [RFC PATCH 2/3] usage: prefix all lines in `vreportf()`, not just the first

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: su

Re: [RFC PATCH 2/3] usage: prefix all lines in `vreportf()`, not just the first

On 29 May 2018 at 07:50, Junio C Hamano wrote: > Martin Ågren writes: > >>> - allow callers to align 1st prefix (e.g. "error: ") with the >>>leading indent for the second and subsequent lines by passing the >>>second prefix with appropriate

Re: [RFC PATCH 2/3] usage: prefix all lines in `vreportf()`, not just the first

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 switch branches. Aborting EOF >>> >>> This shows the typical effect of this series, which (I

[RFC PATCH 3/3] usage: translate the "error: "-prefix and others

appear anyway) so it makes sense to let the prefix be nontranslated, too. Signed-off-by: Martin Ågren <martin.ag...@gmail.com> --- This change breaks several tests under GETTEXT_POISON, e.g. t6030 which does this: git bisect skip > my_bisect_log.txt 2>&1 &&

[RFC PATCH 1/3] usage: extract `prefix_suffix_lines()` from `advise()`

"warning: "-messages. In preparation for that, extract the code for printing the individual lines and expose it through git-compat-util.h. Signed-off-by: Martin Ågren <martin.ag...@gmail.com> --- I'm open for suggestions on the naming of `prefix_suffix_lines()`... git-compat-util.h |

[RFC PATCH 2/3] usage: prefix all lines in `vreportf()`, not just the first

uture users). Note that we need to adjust quite a few tests as a result of this change. All of these changes are because we obviously need to prefix more lines in various "expect"-files -- except for one instance of a trailing empty line that disappears with this commit (see t7609). This is a ve

[RFC PATCH 0/3] usage: prefix all lines in `vreportf()`, not just the first

'm running out of time anyway, I thought I'd post this as a heads-up of "I'm looking into this". I do wonder: If our tests rely on grepping for "warning" (for pretty good reasons), how many scripts out there do something similar (for maybe-not-so-good reasons, but still)? Do we wan

Re: [PATCH v5 0/4] unpack_trees_options: free messages when done

On 22 May 2018 at 04:54, Junio C Hamano wrote: > Junio C Hamano writes: >> Hmph, this unfortunately depends on 'next', which means we cannot >> merge it down to 'maint' later to fix these leaks. I guess it is >> not a huge deal, though. We've lived with

Re: [PATCH] regex: do not call `regfree()` if compilation fails

On 22 May 2018 at 04:20, Eric Sunshine <sunsh...@sunshineco.com> wrote: > On Mon, May 21, 2018 at 2:43 PM, Stefan Beller <sbel...@google.com> wrote: >> On Sun, May 20, 2018 at 3:50 AM, Martin Ågren <martin.ag...@gmail.com> wrote: >>> It is apparently

  1   2   3   4   5   6   >