Taylor Blau writes:
> I re-read your note and understand more clearly now what your suggestion
> is. To ensure that we're in agreement, do you mean:
>
> 1. '--column -v' will _never_ give a column, but will never die(),
> either
No, I don't.
> 2. '--column --[and | or | not]' will nev
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 a hit. I am
> >> w
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 is what
>> satisfie
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 grep -e first --and -e
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
README.md:18
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 -
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 now,
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 b/grep.c
index fb0fa232
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 capabiliti
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
---
c
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 +++
grep.c
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
---
Docume
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(+)
diff --git a/grep.c b/g
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 f
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
?" but
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: 10
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
>> the git global con
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 this is interesting.
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.
>
> Interesting.
>
> I
--
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
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 re
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
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 to consume.
> Sign
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
> git_default_config().
> While
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,
> for example.
> Signed
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
> ---
> diff --git a/fsck.c b/fsck.c
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
> (and ideally libgit2, as well).
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 reflect the fact that it d
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 matc
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
---
Documenta
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 +++---
1 file changed, 15
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
commit-grap
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
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 --
1 file change
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 non-trivi
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'
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 th
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
---
t/t5318-commit-graph.sh | 53
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
---
co
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
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. Ther
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/
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 must be given with a step o
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 al
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, I merged the two
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 apply' does then I
>> think 'g
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
one
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 numb
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 d
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 inst
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 cas
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 any
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 avoi
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 direction of the tes
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 review.
I don't know about "full" and "rigorous
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 early
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 Th
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 rather straightforward.
But there are traps.
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
ta
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.
Signed-off-by: Derrick Stol
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 porcelain
> commands", t
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.
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 rename logic
> triggers th
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
> categorization in 'command-list.tx
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 thanks to
caching it's on
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 seem
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 writes:
>> >>
>> But it somehow feels backwards in spirit to me,
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
ta
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 (the actual example that
triggered this patch to
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.
Packfiles and loose objects are primary data,
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 the pager.
> +
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 a
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 the new default reference st
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) bu
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
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 reason why we
> use "void *" there in the decorat
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 some reason and f
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 m
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 terminal
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.
While
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[] = {
>> + [BRANCH_COLOR_RESET]= "reset",
>
> In 5
81 matches
Mail list logo
