Re: [PATCH v5 5/7] builtin/grep.c: add '--column' option to 'git-grep(1)'

On Sat, May 12, 2018 at 02:08:48PM +0900, Junio C Hamano wrote: > Taylor Blau writes: > > >> $ git grep -v second > >> $ git grep --not -e second > >> > >> may hit all lines in this message (except for the obvious two > >> lines), but we cannot say which column we found

Re: [PATCH v5 5/7] builtin/grep.c: add '--column' option to 'git-grep(1)'

Taylor Blau writes: >> $ git grep -v second >> $ git grep --not -e second >> >> may hit all lines in this message (except for the obvious two >> lines), but we cannot say which column we found a hit. I am >> wondering if it is too grave a sin to report "the whole line

Re: [PATCH v5 5/7] builtin/grep.c: add '--column' option to 'git-grep(1)'

On Thu, May 10, 2018 at 09:04:34AM +0900, Junio C Hamano wrote: > Taylor Blau writes: > > > This check we should retain and change the wording to mention '--and', > > '--or', and '--not' specifically. > > Why are these problematic in the first place? If I said > > $ git

[PATCH v2 2/2] builtin/grep.c: teach '-o', '--only-matching' to 'git-grep'

Teach GNU grep(1)'s '-o' ('--only-matching') to 'git-grep'. This option prints only the matching components of each line. It writes multiple lines if more than one match exists on a given line. For example: $ /git grep -on --column git -- README.md | head -3 README.md:15:56:git

[PATCH v2 0/2] builtin/grep.c: teach '-o', '--only-matching'

Hi, Attached is the second re-roll of my series to add GNU grep's '--only-matching' to git-grep. The main thing that has changed since last time is our handling of -{A,B,C}. Previously, as Peff points out in [1], we handle this in a buggy way different than GNU. I agree that although 'git grep

[PATCH v2 1/2] grep.c: extract show_line_header()

Teach 'git-grep(1)' how to print a line header multiple times from show_line() in preparation for it learning '--only-matching'. show_line_header() comprises the code in show_line() executed in order to produce a line header. It is a one-for-one extraction of the existing implementation. For

[PATCH v6 4/7] grep.c: display column number of first match

To prepare for 'git grep' learning '--column', teach grep.c's show_line() how to show the column of the first match on non-context line. Signed-off-by: Taylor Blau --- grep.c | 21 - 1 file changed, 16 insertions(+), 5 deletions(-) diff --git a/grep.c

[PATCH v6 5/7] builtin/grep.c: add '--column' option to 'git-grep(1)'

Teach 'git-grep(1)' a new option, '--column', to show the column number of the first match on a non-context line. This makes it possible to teach 'contrib/git-jump/git-jump' how to seek to the first matching position of a grep match in your editor, and allows similar additional scripting

[PATCH v6 7/7] contrib/git-jump/git-jump: jump to match column in addition to line

Take advantage of 'git-grep(1)''s new option, '--column' in order to teach Peff's 'git-jump' script how to jump to the correct column for any given match. 'git-grep(1)''s output is in the correct format for Vim's jump list, so no additional cleanup is necessary. Signed-off-by: Taylor Blau

[PATCH v6 6/7] grep.c: add configuration variables to show matched option

To support git-grep(1)'s new option, '--column', document and teach grep.c how to interpret relevant configuration options, similar to those associated with '--line-number'. Signed-off-by: Taylor Blau --- Documentation/config.txt | 5 + Documentation/git-grep.txt | 3

[PATCH v6 1/7] Documentation/config.txt: camel-case lineNumber for consistency

lineNumber has casing that is inconsistent with surrounding options, like color.grep.matchContext, and color.grep.matchSelected. Re-case this documentation in order to be consistent with the text around it, and to ensure that new entries are consistent, too. Signed-off-by: Taylor Blau

[PATCH v6 2/7] grep.c: expose matched column in match_line()

When calling match_line(), callers presently cannot determine the relative offset of the match because match_line() discards the 'regmatch_t' that contains this information. Instead, teach match_line() to take in a 'regmatch_t *' so that callers can inspect the match's starting and ending offset

[PATCH v6 3/7] grep.[ch]: extend grep_opt to allow showing matched column

To support showing the matched column when calling 'git-grep(1)', teach 'grep_opt' the normal set of options to configure the default behavior and colorization of this feature. Signed-off-by: Taylor Blau --- grep.c | 3 +++ grep.h | 2 ++ 2 files changed, 5 insertions(+)

[PATCH v6 0/7] Teach '--column' to 'git-grep(1)'

Hi, Attached is my sixth re-roll of a series to add '--column' to 'git grep'. The main change since v5 is supporting --column with queries containing --and, --or, or --not. Previously, I had chosen to die() in this case since there isn't always a good answer to "what is the first column of ?"

Bug report for git push

Hi everyone! I am facing this spurious issue (not easily reproducible and usually a retry fixes it) with git push: Warning: Permanently added 'github.com,192.30.255.112' (RSA) to the list of known hosts. Counting objects: 8, done. Delta compression using up to 2 threads. Compressing objects:

Re: [PATCH] doc: fix config API documentation about config_with_options

Brandon Williams writes: > On 05/09, Antonio Ospite wrote: >> In commit dc8441fdb ("config: don't implicitly use gitdir or commondir", >> 2017-06-14) the function git_config_with_options was renamed to >> config_with_options to better reflect the fact that it does not access

Re: [PATCH] git-submodule.sh: try harder to fetch a submodule

Jonathan Nieder writes: >> HEAD is allowed by the protocol spec and would happen, if HEAD points at a >> ref, that this user cannot see (due to ACLs for example). > > A more typical example would be if the ref simply doesn't exist (i.e., > is a branch yet to be born). Indeed

Re: [PATCH] git-submodule.sh: try harder to fetch a submodule

On Fri, May 11, 2018 at 4:28 PM, Jonathan Nieder wrote: > Hi, > > Stefan Beller wrote: > >> This is the logical continuum of fb43e31f2b4 (submodule: try harder to >> fetch needed sha1 by direct fetching sha1, 2016-02-23) and fixes it as >> some assumptions were not correct. >

Proposal

-- Hello Greetings to you please i have a business proposal for you contact me for more detailes asap thanks. Best Regards, Miss.Zeliha ömer faruk Esentepe Mahallesi Büyükdere Caddesi Kristal Kule Binasi No:215 Sisli - Istanbul, Turkey

Re: [PATCH] git-submodule.sh: try harder to fetch a submodule

Hi, Stefan Beller wrote: > This is the logical continuum of fb43e31f2b4 (submodule: try harder to > fetch needed sha1 by direct fetching sha1, 2016-02-23) and fixes it as > some assumptions were not correct. Interesting. I think what would help most is an example set of commands I can use to

[PATCH] git-submodule.sh: try harder to fetch a submodule

This is the logical continuum of fb43e31f2b4 (submodule: try harder to fetch needed sha1 by direct fetching sha1, 2016-02-23) and fixes it as some assumptions were not correct. > If $sha1 was not part of the default fetch ... fail ourselves here assumes that the fetch_in_submodule only fails when

Re: [PATCH 7/9] completion: drop the hard coded list of config vars

On Thu, May 10, 2018 at 10:19 AM Nguyễn Thái Ngọc Duy wrote: > The new help option --config-for-completion is a machine friendlier > version of --config where all the placeholders and wildcards are > dropped, leaving only the good, completable prefixes for > git-completion.bash

Re: [PATCH 6/9] am: move advice.amWorkDir parsing back to advice.c

On Thu, May 10, 2018 at 10:19 AM Nguyễn Thái Ngọc Duy wrote: > The only benefit from this move (apart from cleaner code) is that > advice.amWorkDir should now show up in `git help --config`. There > should be no regression since advice config is always read by the >

Re: [PATCH 4/9] help: add --config to list all available config

On Thu, May 10, 2018 at 10:20 AM Nguyễn Thái Ngọc Duy wrote: > Sometimes it helps to list all available config vars so the user can > search for something they want. The config man page can also be used > but it's harder to search if you want to focus on the variable name, >

Re: [PATCH 3/9] fsck: factor out msg_id_info[] lazy initialization code

On Thu, May 10, 2018 at 10:19 AM Nguyễn Thái Ngọc Duy wrote: > This array will be used by some other function than parse_msg_id() in > the following commit. Factor out this prep code so it could be called > from that one. > Signed-off-by: Nguyễn Thái Ngọc Duy

Re: Implementing reftable in Git

On Fri, 2018-05-11 at 11:31 +0200, Michael Haggerty wrote: > On Wed, May 9, 2018 at 4:33 PM, Christian Couder > wrote: > > I might start working on implementing reftable in Git soon. > > [...] > > Nice. It'll be great to have a reftable implementation in git core >

Re: [PATCH] doc: fix config API documentation about config_with_options

On Wed, 9 May 2018 10:19:50 -0700 Brandon Williams wrote: > On 05/09, Antonio Ospite wrote: > > In commit dc8441fdb ("config: don't implicitly use gitdir or commondir", > > 2017-06-14) the function git_config_with_options was renamed to > > config_with_options to better

[PATCH v2 05/12] commit-graph: verify fanout and lookup table

While running 'git commit-graph verify', verify that the object IDs are listed in lexicographic order and that the fanout table correctly navigates into that list of object IDs. Add tests that check these corruptions are caught by the verify subcommand. Most of the tests check the full output

[PATCH v2 04/12] commit-graph: parse commit from chosen graph

Before verifying a commit-graph file against the object database, we need to parse all commits from the given commit-graph file. Create parse_commit_in_graph_one() to target a given struct commit_graph. Signed-off-by: Derrick Stolee --- commit-graph.c | 18

[PATCH v2 12/12] commit-graph: update design document

The commit-graph feature is now integrated with 'fsck' and 'gc', so remove those items from the "Future Work" section of the commit-graph design document. Also remove the section on lazy-loading trees, as that was completed in an earlier patch series. Signed-off-by: Derrick Stolee

[PATCH v2 09/12] fsck: verify commit-graph

If core.commitGraph is true, verify the contents of the commit-graph during 'git fsck' using the 'git commit-graph verify' subcommand. Run this check on all alternates, as well. We use a new process for two reasons: 1. The subcommand decouples the details of loading and verifying a

[PATCH v2 06/12] commit: force commit to parse from object database

In anticipation of verifying commit-graph file contents against the object database, create parse_commit_internal() to allow side-stepping the commit-graph file and parse directly from the object database. Due to the use of generation numbers, this method should not be called unless the intention

[PATCH v2 07/12] commit-graph: load a root tree from specific graph

When lazy-loading a tree for a commit, it will be important to select the tree from a specific struct commit_graph. Create a new method that specifies the commit-graph file and use that in get_commit_tree_in_graph(). Signed-off-by: Derrick Stolee --- commit-graph.c | 10

[PATCH v2 11/12] gc: automatically write commit-graph files

The commit-graph file is a very helpful feature for speeding up git operations. In order to make it more useful, write the commit-graph file by default during standard garbage collection operations. Add a 'gc.commitGraph' config setting that triggers writing a commit-graph file after any

[PATCH v2 10/12] commit-graph: add '--reachable' option

When writing commit-graph files, it can be convenient to ask for all reachable commits (starting at the ref set) in the resulting file. This is particularly helpful when writing to stdin is complicated, such as a future integration with 'git gc' which will call 'git commit-graph write --reachable'

[PATCH v2 08/12] commit-graph: verify commit contents against odb

When running 'git commit-graph verify', compare the contents of the commits that are loaded from the commit-graph file with commits that are loaded directly from the object database. This includes checking the root tree object ID, commit date, and parents. Parse the commit from the graph during

[PATCH v2 03/12] commit-graph: test that 'verify' finds corruption

Add test cases to t5318-commit-graph.sh that corrupt the commit-graph file and check that the 'git commit-graph verify' command fails. These tests verify the header and chunk information is checked carefully. Helped-by: Martin Ågren Signed-off-by: Derrick Stolee

[PATCH v2 02/12] commit-graph: verify file header information

During a run of 'git commit-graph verify', list the issues with the header information in the commit-graph file. Some of this information is inferred from the loaded 'struct commit_graph'. Some header information is checked as part of load_commit_graph_one(). Signed-off-by: Derrick Stolee

[PATCH v2 01/12] commit-graph: add 'verify' subcommand

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 file. Add the 'verify' subcommand to the 'commit-graph' builtin and its

[PATCH v2 00/12] Integrate commit-graph into fsck and gc

I'm sending this v2 re-roll rather quickly after the previous version because Martin provided a framework to add tests to the 'verify' subcommand. I took that framework and added tests for the other checks of the commit-graph data. This also found some interesting things about the command: 1.

Re: [PATCH] alloc: allow arbitrary repositories for alloc functions

On Fri, May 11, 2018 at 3:17 PM Stefan Beller wrote: > diff --git a/commit.c b/commit.c > @@ -296,6 +297,17 @@ void free_commit_buffer(struct commit *commit) > +void relase_commit_memory(struct commit *c) s/relase/release/

RE: [Best Practices Request] clean/smudge configuration

On May 10, 2018 10:27 PM, Junio C Hamano wrote: > "Randall S. Becker" writes: > > > What if we create a ../.gitconfig like ../.gitattributes, that is > > loaded before .git/config? > > You should not forget one of the two reasons why clean/smudge/diff etc. > drivers

[PATCH] alloc: allow arbitrary repositories for alloc functions

We have to convert all of the alloc functions at once, because alloc_report uses a funky macro for reporting. It is better for the sake of mechanical conversion to convert multiple functions at once rather than changing the structure of the reporting function. We record all memory allocation in

Re: [PATCH v2 0/4] Fix mem leaks of recent object store conversions.

On Fri, May 11, 2018 at 1:37 AM, Jeff King wrote: > On Thu, May 10, 2018 at 12:58:45PM -0700, Stefan Beller wrote: > >> This series replaces the two commits that were queued on >> sb/object-store-replace, >> fixing memory leaks that were recently introduced. >> >> Compared to v1,

Re: Regression in patch add?

On 11/05/18 03:47, Junio C Hamano wrote: > Phillip Wood writes: > >> Yes, I think it probably makes sense to do that. Originally I didn't >> count empty lines as context lines in case the user accidentally added >> some empty lines at the end of the hunk but if 'git

[PATCH 4/4] mark_parents_uninteresting(): avoid most allocation

Commit 941ba8db57 (Eliminate recursion in setting/clearing marks in commit list, 2012-01-14) used a clever double-loop to avoid allocations for single-parent chains of history. However, it did so only when following parents of parents (which was an uncommon case), and _always_ incurred at least

[PATCH 3/4] mark_parents_uninteresting(): replace list with stack

The mark_parents_uninteresting() function uses two loops: an outer one to process our queue of pending parents, and an inner one to process first-parent chains. This is a clever optimization from 941ba8db57 (Eliminate recursion in setting/clearing marks in commit list, 2012-01-14) to limit the

[PATCH 2/4] mark_parents_uninteresting(): drop missing object check

We allow UNINTERESTING objects in a traversal to be unavailable. As part of this, mark_parents_uninteresting() checks whether we have a particular uninteresting parent; if not, we will mark it as "parsed" so that later code skips it. This code is redundant and even a little bit harmful, so let's

[PATCH 1/4] mark_tree_contents_uninteresting(): drop missing object check

It's generally acceptable for UNINTERESTING objects in a traversal to be unavailable (e.g., see aeeae1b771). When marking trees UNINTERESTING, we access the object database twice: once to check if the object is missing (and return quietly if it is), and then again to actually parse it. We can

[PATCH 0/4] a few mark_parents_uninteresting cleanups

This is a follow-up to the discussion from February: https://public-inbox.org/git/1519522496-73090-1-git-send-email-dsto...@microsoft.com/ There I theorized that some of these extra has_object_file() checks were unnecessary. After poking around a bit, I've convinced myself that this is the

Re: Patch add: previous hunk across file boundaries

On Fri, May 11, 2018 at 09:53:52AM -0500, Robert Dailey wrote: > I noticed that when stepping into a new file while doing `git add -p`, > pressing `k` or `K` does not go back to the previous file. Is this a > bug? Is there a setting for it? I googled & checked out the git docs, > I didn't find

Re: [PATCH] fast-export: avoid NULL pointer arithmetic

On Fri, May 11, 2018 at 03:34:19PM +0200, Duy Nguyen wrote: > On Fri, May 11, 2018 at 03:11:46PM +0200, Duy Nguyen wrote: > > Back to fast-export, can we just allocate a new int on heap and point > > it there? Allocating small pieces becomes quite cheap and fast with > > mem-pool.h and we can

Re: [PATCH 00/12] Integrate commit-graph into fsck, gc, and fetch

On 11 May 2018 at 19:23, Derrick Stolee wrote: > Martin's initial test cases are wonderful. I've adapted them to test the > other conditions in the verify_commit_graph() method and caught some > interesting behavior in the process. I'm preparing v2 so we can investigate > the

Re: [PATCH 00/12] Integrate commit-graph into fsck, gc, and fetch

On 5/10/2018 3:22 PM, Stefan Beller wrote: On Thu, May 10, 2018 at 12:05 PM, Martin Ågren wrote: On 10 May 2018 at 19:34, Derrick Stolee wrote: Commits 01-07 focus on the 'git commit-graph verify' subcommand. These are ready for full, rigorous

Re: [PATCH 00/12] Integrate commit-graph into fsck, gc, and fetch

On 5/10/2018 3:17 PM, Ævar Arnfjörð Bjarmason wrote: On Thu, May 10 2018, Derrick Stolee wrote: The behavior in this patch series does the following: 1. Near the end of 'git gc', run 'git commit-graph write'. The location of this code assumes that a 'git gc --auto' has not terminated

[PATCH] commit.h: rearrange 'index' to shrink struct commit

On linux 64-bit architecture, pahole finds that there's a 4 bytes padding after 'index'. Moving it to the end reduces this struct's size from 72 to 64 bytes (because of another 4 bytes padding after graph_pos). On linux 32-bit, the struct size remains 52 bytes like before. Signed-off-by: Nguyễn

Re: [PATCH v7 07/13] completion: implement and use --list-cmds=main,others

On Fri, May 11, 2018 at 4:06 PM, SZEDER Gábor wrote: > On Thu, May 10, 2018 at 10:46 AM, Nguyễn Thái Ngọc Duy > wrote: >> Instead of parsing "git help -a" output, which is tricky to get right, >> less elegant and also slow, > > Is it tricky? It seems

[PATCH v4] add status config and command line options for rename detection

After performing a merge that has conflicts git status will, by default, attempt to detect renames which causes many objects to be examined. In a virtualized repo, those objects do not exist locally so the rename logic triggers them to be fetched from the server. This results in the status call

Re: [PATCH 04/12] commit-graph: verify fanout and lookup table

On 5/10/2018 2:29 PM, Martin Ågren wrote: On 10 May 2018 at 19:34, Derrick Stolee wrote: While running 'git commit-graph verify', verify that the object IDs are listed in lexicographic order and that the fanout table correctly navigates into that list of object IDs.

Re: [PATCH v7 12/13] completion: let git provide the completable command list

On Thu, May 10, 2018 at 10:46 AM, Nguyễn Thái Ngọc Duy wrote: > Instead of maintaining a separate list of command classification, > which often could go out of date, let's centralize the information > back in git. > > While the function in git-completion.bash implies "list

Patch add: previous hunk across file boundaries

I noticed that when stepping into a new file while doing `git add -p`, pressing `k` or `K` does not go back to the previous file. Is this a bug? Is there a setting for it? I googled & checked out the git docs, I didn't find any specific information on this.

Re: [PATCH v3] add status config and command line options for rename detection

Hi Ben, On Fri, May 11, 2018 at 5:56 AM, Ben Peart wrote: > After performing a merge that has conflicts git status will, by default, > attempt to detect renames which causes many objects to be examined. In a > virtualized repo, those objects do not exist locally so the

Re: [PATCH v7 07/13] completion: implement and use --list-cmds=main,others

On Fri, May 11, 2018 at 4:06 PM, SZEDER Gábor wrote: > OTOH you don't mention the most important reason, namely that the > completion script contains a long hard-coded list of the names of all > known plumbing commands to filter out, which is redundant with the >

Re: [PATCH v7 07/13] completion: implement and use --list-cmds=main,others

On Thu, May 10, 2018 at 10:46 AM, Nguyễn Thái Ngọc Duy wrote: > Instead of parsing "git help -a" output, which is tricky to get right, > less elegant and also slow, Is it tricky? It seems rather straightforward. Is it slow? Well, there is a pipe and an egrep, sure, but

Re: [PATCH] fast-export: avoid NULL pointer arithmetic

On Fri, May 11, 2018 at 03:11:46PM +0200, Duy Nguyen wrote: > Back to fast-export, can we just allocate a new int on heap and point > it there? Allocating small pieces becomes quite cheap and fast with > mem-pool.h and we can avoid this storing integer in pointer business. Something like this

Re: [PATCH] fast-export: avoid NULL pointer arithmetic

On Fri, May 11, 2018 at 10:56 AM, Jeff King wrote: > On Fri, May 11, 2018 at 08:19:59AM +0200, Duy Nguyen wrote: > >> On Fri, May 11, 2018 at 6:49 AM, Junio C Hamano wrote: >> > Junio C Hamano writes: >> > >> >> René Scharfe

[PATCH v3] add status config and command line options for rename detection

After performing a merge that has conflicts git status will, by default, attempt to detect renames which causes many objects to be examined. In a virtualized repo, those objects do not exist locally so the rename logic triggers them to be fetched from the server. This results in the status call

Re: [PATCH v2] add status config and command line options for rename detection

On 5/10/2018 6:31 PM, Elijah Newren wrote: Hi Ben, On Thu, May 10, 2018 at 12:09 PM, Ben Peart wrote: On 5/10/2018 12:19 PM, Elijah Newren wrote: On Thu, May 10, 2018 at 7:16 AM, Ben Peart wrote: Given the example perf impact is arbitrary

Re: [PATCH 00/12] Integrate commit-graph into fsck, gc, and fetch

On 5/10/2018 4:45 PM, Martin Ågren wrote: On 10 May 2018 at 21:22, Stefan Beller wrote: On Thu, May 10, 2018 at 12:05 PM, Martin Ågren wrote: I hope to find time to do some more hands-on testing of this to see that errors actually do get caught.

Re: [PATCH] pager: set COLUMNS to term_columns()

On Fri, May 11, 2018 at 11:25 AM, Jeff King wrote: > --- a/pager.c > +++ b/pager.c > @@ -109,10 +109,15 @@ void setup_pager(void) > return; > > /* > -* force computing the width of the terminal before we redirect > -* the standard output to

[PATCH] column: fix off-by-one default width

By default we want to fill the whole screen if possible, but we do not want to use up _all_ terminal columns because the last character is going hit the border, push the cursor over and wrap. Keep it at default value zero, which will make print_columns() set the width at term_columns() - 1. This

Re: Implementing reftable in Git

On Wed, May 9, 2018 at 4:33 PM, Christian Couder wrote: > I might start working on implementing reftable in Git soon. > [...] Nice. It'll be great to have a reftable implementation in git core (and ideally libgit2, as well). It seems to me that it could someday become

[PATCH] pager: set COLUMNS to term_columns()

On Fri, May 11, 2018 at 10:43:45AM +0200, Duy Nguyen wrote: > > As an aside, I was confused while looking into this because I _thought_ > > I had COLUMNS set: > > > > $ echo $COLUMNS > > 119 > > > > But it turns out that bash sets that by default (if you have the > > checkwinsize option on)

Re: [PATCH v2] commit-graph: fix UX issue when .lock file exists

On Thu, May 10, 2018 at 05:42:52PM +, Derrick Stolee wrote: > We use the lockfile API to avoid multiple Git processes from writing to > the commit-graph file in the .git/objects/info directory. In some cases, > this directory may not exist, so we check for its existence. > [...] This version

Re: [PATCH] fast-export: avoid NULL pointer arithmetic

On Fri, May 11, 2018 at 08:19:59AM +0200, Duy Nguyen wrote: > On Fri, May 11, 2018 at 6:49 AM, Junio C Hamano wrote: > > Junio C Hamano writes: > > > >> René Scharfe writes: > >> > But it somehow feels backwards in spirit to me, as the

Re: [PATCH] tag: fix column output not using all terminal space

On Fri, May 11, 2018 at 10:28 AM, Jeff King wrote: > On Fri, May 11, 2018 at 09:56:02AM +0200, Nguyễn Thái Ngọc Duy wrote: > >> git-tag runs a separate git-column command via run_column_filter(). >> This makes the new 'git-column' process fail to pick up the terminal >> width for

Re: [PATCH v2 0/4] Fix mem leaks of recent object store conversions.

On Thu, May 10, 2018 at 12:58:45PM -0700, Stefan Beller wrote: > This series replaces the two commits that were queued on > sb/object-store-replace, > fixing memory leaks that were recently introduced. > > Compared to v1, I merged the two independent series from yesterday, > rewrote the commit

Re: [PATCH] tag: fix column output not using all terminal space

On Fri, May 11, 2018 at 09:56:02AM +0200, Nguyễn Thái Ngọc Duy wrote: > git-tag runs a separate git-column command via run_column_filter(). > This makes the new 'git-column' process fail to pick up the terminal > width for some reason and fall back to default width. Just explicitly > pass

[PATCH] tag: fix column output not using all terminal space

git-tag runs a separate git-column command via run_column_filter(). This makes the new 'git-column' process fail to pick up the terminal width for some reason and fall back to default width. Just explicitly pass terminal width and avoid this terminal width detection business in subprocesses.

Re: [PATCH 1/9] Add and use generic name->id mapping code for color slot parsing

On Thu, May 10, 2018 at 7:16 PM, Stefan Beller wrote: > On Thu, May 10, 2018 at 7:19 AM, Nguyễn Thái Ngọc Duy > wrote: > >> 7 files changed, 82 insertions(+), 112 deletions(-) > > Nice! > > >> >> +static const char *color_branch_slots[] = { >> +

[PATCH v3] pack-format.txt: more details on pack file format

The current document mentions OBJ_* constants without their actual values. A git developer would know these are from cache.h but that's not very friendly to a person who wants to read this file to implement a pack file parser. Similarly, the deltified representation is not documented at all (the

Re: [PATCH v2] pack-format.txt: more details on pack file format

On Thu, May 10, 2018 at 7:06 PM, Stefan Beller wrote: >> +=== Deltified representation >> + >> +Conceptually there are only four object types: commit, tree, tag and >> +blob. However to save space, an object could be stored as a "delta" of >> +another "base" object. These

Re: [PATCH v2] add status config and command line options for rename detection

Ben Peart writes: > Documentation/config.txt | 10 > Documentation/git-status.txt | 10 > builtin/commit.c | 41 > diff.c | 2 +- > diff.h | 1 + > t/t7525-status-rename.sh | 90

Re: [PATCH 0/9] completion: avoid hard coding config var list

On Fri, May 11, 2018 at 8:00 AM, Junio C Hamano wrote: > Nguyễn Thái Ngọc Duy writes: > >> While at there, this config list is also available to the user via >> `git help --config` if you can't remember the exact config name you >> want and don't want to go

Re: [PATCH] fast-export: avoid NULL pointer arithmetic

On Fri, May 11, 2018 at 6:49 AM, Junio C Hamano wrote: > Junio C Hamano writes: > >> René Scharfe writes: >> But it somehow feels backwards in spirit to me, as the reason why we use "void *" there in the decoration field is because

Re: [PATCH 0/9] completion: avoid hard coding config var list

Nguyễn Thái Ngọc Duy writes: > While at there, this config list is also available to the user via > `git help --config` if you can't remember the exact config name you > want and don't want to go through that big git-config man page. Makes a reader anticipate a new user of