On Thu, Jun 27, 2019 at 01:35:17PM -0400, Derrick Stolee wrote:
> > t/helper/test-example-decorate.c
> > 0ebbcf70 29) one = lookup_unknown_object(&one_oid);
> > 0ebbcf70 30) two = lookup_unknown_object(&two_oid);
> > 0ebbcf70 59) three = lookup_unknown_object(&three_oid);
>
> Peff: again interest
On Thu, Jun 27, 2019 at 01:35:17PM -0400, Derrick Stolee wrote:
> > pack-bitmap-write.c
> > 05805d74 378) static struct ewah_bitmap *find_reused_bitmap(const struct
> > object_id *oid)
> > d2bc62b1 385) hash_pos = kh_get_oid_map(writer.reused, *oid);
> > 05805d74 425) reused_bitmap = find_reused_
On Wed, Jun 26, 2019 at 03:29:29PM -0700, Junio C Hamano wrote:
> * br/blame-ignore (2019-06-20) 9 commits
> - blame: add a test to cover blame_coalesce()
> - blame: use the fingerprint heuristic to match ignored lines
> - blame: add a fingerprint heuristic to match ignored lines
> - blame: op
Matthew DeVore writes:
> On Wed, Jun 26, 2019 at 03:29:29PM -0700, Junio C Hamano wrote:
>> * md/list-objects-filter-combo (2019-06-17) 10 commits
>> - list-objects-filter-options: make parser void
>> - list-objects-filter-options: clean up use of ALLOC_GROW
>> - list-objects-filter-options: a
On Thu, Jun 27, 2019 at 6:31 PM Emily Shaffer wrote:
> On Thu, Jun 27, 2019 at 01:37:58AM -0400, Eric Sunshine wrote:
> > Don't localize the die() message via _() here or in the preceding
> > OBJ_COMMIT case.
>
> I'm a little surprised by that. Is it because die() is expected to only
> be seen by
Bring back optimized fixed-string search for "grep", this time with
PCRE v2 as an optional backend. As noted in [1] with kwset we were
slower than PCRE v1 and v2 JIT with the kwset backend, so that
optimization was counterproductive.
This brings back the optimization for "--fixed-strings", without
A later change will replace this optimization with optimistic use of
PCRE v2. I'm completely removing it as an intermediate step, as
opposed to replacing it with PCRE v2, to demonstrate that no grep
semantics depend on this (or any other) optimization for the fixed
backend anymore.
For now this is
Move the "grep binary" test case added in aca20dd558 ("grep: add test
script for binary file handling", 2010-05-22) so that it lives
alongside the rest of the "grep" tests in t781*. This would have left
a gap in the t/700* namespace, so move a "filter-branch" test down,
leaving the "t7010-setup.sh"
Change "-f " to not support patterns with a NUL-byte in them
under --fixed-strings. We'll now only support these under
"--perl-regexp" with PCRE v2.
A previous change to grep's documentation changed the description of
"-f " to be vague enough as to not promise that this would work.
By dropping sup
The behavior of "grep" when patterns contained a NUL-byte has always
been haphazard, and has served the vagaries of the implementation more
than anything else. A pattern containing a NUL-byte can only be
provided via "-f ". Since pickaxe (log search) has no such flag
the NUL-byte in patterns has on
Fix a bug introduced in 18547aacf5 ("grep/pcre: support utf-8",
2016-06-25) that was missed due to a blindspot in our tests, as
discussed in the previous commit. I then blindly copied the same bug
in 94da9193a6 ("grep: add support for PCRE v2", 2017-06-01) when
adding the PCRE v2 code.
We should n
Improve the tests added in 04deccda11 ("log: re-encode commit messages
before grepping", 2013-02-11) to test the regex backends. Those tests
never worked as advertised, due to the is_fixed() optimization in
grep.c (which was in place at the time), and the needle in the tests
being a fixed string.
A non-RFC since it seem people like this approach.
This should fix the test failure noted by Johannes, there's two new
patches at the start of this series. They address a bug that was there
for a long time, but I happened to trip over since PCRE is more strict
about UTF-8 validation than kwset (wh
Since e944d9d932 ("grep: rewrite an if/else condition to avoid
duplicate expression", 2016-06-25) the "ascii_only" variable has only
been used once in compile_regexp(), let's just inline it there.
This makes the code easier to read, and might make it marginally
faster depending on compiler optimiz
Move the tests for "-f " where "" contains a NUL byte
pattern into their own file. I added most of these tests in
966be95549 ("grep: add tests to fix blind spots with \0 patterns",
2017-05-20).
Whether a regex engine supports matching binary content is very
different from whether it matches binary
On Wed, Jun 26, 2019 at 3:44 PM Taylor Blau wrote:
>
Ok, now I've got some time to look at the code itself.
> ref-filter.c| 89 +
> t/t6300-for-each-ref.sh | 26
> 2 files changed, 89 insertions(+), 26 deletions(-)
>
> diff --git
On Wed, Jun 26, 2019 at 04:50:19PM -0700, Emily Shaffer wrote:
> Since r1, made some significant changes.
>
> - Added a commit for counting the 'omitted' list, to match the new
>section added to the tutorial.
> - Added significant comments to allow the sample to better stand on its
>own.
Allow combining of multiple filters by simply repeating the --filter
flag. Before this patch, the user had to combine them in a single flag
somewhat awkwardly (e.g. --filter=combine:FOO+BAR), including
URL-encoding the individual filters.
To make this work, in the --filter flag parsing callback, r
Allow combining filters such that only objects accepted by all filters
are shown. The motivation for this is to allow getting directory
listings without also fetching blobs. This can be done by combining
blob:none with tree:. There are massive repositories that have
larger-than-expected trees - eve
Make the filter_spec string a string_list rather than a raw C string.
The list of strings must be concatted together to make a complete
filter_spec. A future patch will use this capability to build "combine:"
filter specs gradually.
A strbuf would seem to be a more natural choice for this object,
Making errbuf an optional argument complicates error reporting. Fix this
by making all callers supply an errbuf, even if they may ignore it. This
will be important in follow-up patches where the filter-spec parsing has
more pitfalls and possible errors.
Signed-off-by: Matthew DeVore
---
list-obj
Allow callers to specify exactly what characters need to be URL-encoded
and which do not. This new API will be taken advantage of in a patch
later in this set.
Helped-by: Jeff King
Signed-off-by: Matthew DeVore
---
credential-store.c | 9 +
http.c | 6 --
strbuf.c
Introduce a new macro ALLOC_GROW_BY which automatically zeros the added
array elements and takes care of updating the nr value. Use the macro in
code introduced earlier in this patchset.
Signed-off-by: Matthew DeVore
---
cache.h | 22 ++
list-objects-fil
Encapsulate filter_fn, filter_free_fn, and filter_data into their own
opaque struct.
Due to opaqueness, filter_fn and filter_free_fn can no longer be
accessed directly by users. Currently, all usages of filter_fn are
guarded by a necessary check:
(obj->flags & NOT_USER_GIVEN) && filter_fn
Move the check that filter_options->choice is set to higher in the call
stack. This can only be set when the gentle parse function is called
from one of the two call sites.
This is important because in an upcoming patch this may or may not be an
error, and whether it is an error is only known to t
The oidset *omits pointer must be accessed by the combine filter in a
type-agnostic way once the graph traversal is over. Store that pointer
in the general `filter` struct. This will be used in a follow-up patch
to implement the combine filter.
Signed-off-by: Matthew DeVore
---
list-objects-filt
This function always returns 0, so make it return void instead.
Signed-off-by: Matthew DeVore
---
list-objects-filter-options.c | 12 +---
list-objects-filter-options.h | 2 +-
2 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/list-objects-filter-options.c b/list-objects-fi
This applies suggestions made by Jonathan Tan, as well as fixes a
Coccinelle-breaking error in strbuf usage, and makes an additional string
localizable.
Thanks,
Matthew DeVore (10):
list-objects-filter: encapsulate filter components
list-objects-filter: put omits set in filter struct
list-o
On Thu, Jun 27, 2019 at 01:42:45AM -0400, Eric Sunshine wrote:
> On Wed, Jun 26, 2019 at 7:51 PM Emily Shaffer wrote:
> > Demonstrate how filter specs can be used when performing a revision walk
> > of all object types. In this case, tree depth is used. Contributors who
> > are following the revis
On Thu, Jun 27, 2019 at 01:37:58AM -0400, Eric Sunshine wrote:
> On Wed, Jun 26, 2019 at 7:51 PM Emily Shaffer wrote:
> > Provide a demonstration of a revision walk which traverses all types of
> > object, not just commits. This type of revision walk is used for
> > operations such as creating pac
On Thu, Jun 27, 2019 at 02:24:57PM -0700, Matthew DeVore wrote:
> Great. I feel much better about the comments and commit messages now. I
> am about to send a roll-up (v5). Here is the interdiff which catches
> your comments and Dscho's comment about strbuf_addstr:
>
>
Forgot to make a string lo
On Thu, Jun 27, 2019 at 01:26:19AM -0400, Eric Sunshine wrote:
> On Wed, Jun 26, 2019 at 7:51 PM Emily Shaffer wrote:
> > The final installment in the tutorial about sorting revision walk
> > outputs. This commit reverses the commit list, so that we see newer
> > commits last (handy since we aren'
On Thu, Jun 27, 2019 at 01:22:10AM -0400, Eric Sunshine wrote:
> On Wed, Jun 26, 2019 at 7:51 PM Emily Shaffer wrote:
> > Order the revision walk by author or commit dates, to demonstrate how to
>
> s/,//
Done.
Jeff King writes:
> I'm also not entirely convinced it's worth caring about this problem at
> all (whether the solution is buffering here, or just adding the "\n"
> back to the original strings). It's true that p1451 shows off a
> measurable improvement, but I think it's a silly, pathological cas
On Thu, Jun 27, 2019 at 07:32:53PM +0700, Duy Nguyen wrote:
> > It's also not possible for translators to do this by mistake
>
> This (accidentally dropping \n which sometimes is significant) is the
> part that I made me prefer *printf_ln(). I had been translating for
> years, as far back as 2003
On Fri, Jun 21, 2019 at 05:46:31PM -0700, Jonathan Tan wrote:
> > This function always returns 0, so make it return void instead.
>
> And...patches 7-10 look straightforward and good to me.
>
> In summary, I don't think any changes need to be made to all 10 patches
> other than textual ones (comm
On Thu, Jun 27, 2019 at 04:27:07PM +0700, Duy Nguyen wrote:
> > int fprintf_ln(FILE *fp, const char *fmt, ...)
> > {
> > + char buf[1024];
> > int ret;
> > va_list ap;
> > +
> > + /* Fast path: format it ourselves and dump it via fwrite. */
> > + va_start(ap, fm
On Fri, Jun 21, 2019 at 05:37:13PM -0700, Jonathan Tan wrote:
> Patch 5 and this patch look good to me.
>
>
>
> So expand_list_objects_filter_spec() now returns a filter_options-owned
> string (instead of previously writing to a strbuf), which is why we no
> longer need to do any freeing or rele
On Fri, Jun 21, 2019 at 05:26:26PM -0700, Jonathan Tan wrote:
> > Allow combining filters such that only objects accepted by all filters
> > are shown. The motivation for this is to allow getting directory
> > listings without also fetching blobs. This can be done by combining
> > blob:none with tr
On Thu, Jun 27, 2019 at 02:00:54PM +0200, Johannes Schindelin wrote:
> > I can get similar speedups by formatting into a buffer:
> [..]
> > But we shouldn't have to resort to that.
>
> Why not?
My thinking was that it was introducing an extra copy of the data. But
on further reflection, it proba
On Thu, Jun 27, 2019 at 01:20:25AM -0400, Eric Sunshine wrote:
> On Wed, Jun 26, 2019 at 7:51 PM Emily Shaffer wrote:
> > In order to demonstrate how to create grep filters for revision walks,
> > filter the walk performed by cmd_walken() to print only commits which
> > are authored by someone wit
On Thu, Jun 27, 2019 at 01:16:58AM -0400, Eric Sunshine wrote:
> On Wed, Jun 26, 2019 at 7:51 PM Emily Shaffer wrote:
> > Add the final steps needed and implement the walk loop itself. We add a
> > method walken_commit_walk() which performs the final setup to revision.c
> > and then iterates over
"Quentin Nerden via GitGitGadget" writes:
> From: Quentin Nerden
>
> To make the doc of git-clone easier to read,
> refer to the long version of the options
> (it is easier to guess what --verbose is doing than -v).
>
> Also:
> put the short options first, to match the doc of git-add, git-commit
On Wed, Jun 26, 2019 at 03:29:29PM -0700, Junio C Hamano wrote:
> * md/list-objects-filter-combo (2019-06-17) 10 commits
> - list-objects-filter-options: make parser void
> - list-objects-filter-options: clean up use of ALLOC_GROW
> - list-objects-filter-options: allow mult. --filter
> - strbuf
Nguyễn Thái Ngọc Duy writes:
> tree-walk.h | 8 ---
> unpack-trees.c | 2 +-
> 25 files changed, 129 insertions(+), 97 deletions(-)
>
> Range-diff dựa trên v1:
> 1: 35d7cdbe6a ! 1: 9e73c39f9a sha1-file.c: remove the_repo from
> read_object_with_reference()
On Thu, Jun 27, 2019 at 3:47 PM Johannes Schindelin
wrote:
>
> Hi Matheus,
>
> On Thu, 27 Jun 2019, Matheus Tavares Bernardino wrote:
>
> > On Wed, Jun 26, 2019 at 3:04 PM Junio C Hamano wrote:
> > >
> > > Johannes Schindelin writes:
> > >
> > > > Hi Matheus,
> > > >
> > > > On Tue, 18 Jun 2019,
From: Quentin Nerden
To make the doc of git-clone easier to read,
refer to the long version of the options
(it is easier to guess what --verbose is doing than -v).
Also:
put the short options first, to match the doc of git-add, git-commit,
git-clean, git-branch...
Signed-off-by: Quentin Nerden
To make doc of git-clone easier to read, refer to the long version of the
options (it is easier to guess what --verbose is doing than -v).
Also: put the short options first, to match the doc of git-add, git-commit,
git-clean, git-branch...
Quentin Nerden (1):
docs: update git-clone doc: refer t
Johannes Schindelin writes:
>> > > If we would not have plenty of exercise for the PCRE2 build options, I
>> > > would be worried. But AFAICT the CI build includes this all the time, so
>> > > we're fine.
>> >
>> > Well, I'd feel safer if it were not "all the time", i.e. we know we
>> > are testi
On Thu, Jun 27, 2019 at 01:06:32AM -0400, Eric Sunshine wrote:
> On Wed, Jun 26, 2019 at 7:51 PM Emily Shaffer wrote:
> > `struct rev_info` is what's used by the struct itself.
>
> What "struct itself"? Do you mean 'struct rev_info' is used by the
> _walk_ itself? Or something?
Yep, that's the o
Hi Eric,
On Thu, 27 Jun 2019, Eric Sunshine wrote:
> On Thu, Jun 27, 2019 at 5:37 AM Johannes Schindelin via GitGitGadget
> wrote:
> > Many Win32 API functions actually exist in two variants: one with
> > the `A` suffix that takes ANSI parameters (`char *` or `const char *`)
> > and one with the
Hi Matheus,
On Thu, 27 Jun 2019, Matheus Tavares Bernardino wrote:
> On Wed, Jun 26, 2019 at 3:04 PM Junio C Hamano wrote:
> >
> > Johannes Schindelin writes:
> >
> > > Hi Matheus,
> > >
> > > On Tue, 18 Jun 2019, Matheus Tavares wrote:
> > >
> > >>[...]
> > >> +/*
> > >> + * Look for a recursi
On Thu, Jun 27, 2019 at 12:54:15AM -0400, Eric Sunshine wrote:
> On Wed, Jun 26, 2019 at 7:51 PM Emily Shaffer wrote:
> > For now, we have no configuration options we want to set up for
> > ourselves, but in the future we may need to. At the very least, we
> > should invoke git_default_config() fo
Hi,
On Thu, 27 Jun 2019, Johannes Schindelin wrote:
> On Wed, 26 Jun 2019, Junio C Hamano wrote:
>
> > Johannes Schindelin writes:
> >
> > > ...
> > > Ah hah!
> > >
> > > If we would not have plenty of exercise for the PCRE2 build options, I
> > > would be worried. But AFAICT the CI build includ
On Thu, Jun 27, 2019 at 12:47:25AM -0400, Eric Sunshine wrote:
> On Wed, Jun 26, 2019 at 7:51 PM Emily Shaffer wrote:
> > It's expected that Git commands support '-h' in order to provide a
> > consistent user experience (and this expectation is enforced by the
> > test suite). '-h' is captured by
"Johannes Schindelin via GitGitGadget"
writes:
> From: Johannes Schindelin
>
> It does not make sense to stop non-interactive rebases when that config
> setting is set to `true`.
The reader is assumed to know that that config setting is only about
interactive rebases, including "rebase -x", whi
Hi Ævar,
On Thu, 27 Jun 2019, Ævar Arnfjörð Bjarmason wrote:
>
> On Thu, Jun 27 2019, Johannes Schindelin wrote:
>
> > On Wed, 26 Jun 2019, Johannes Schindelin wrote:
> >
> >> On Wed, 26 Jun 2019, Ævar Arnfjörð Bjarmason wrote:
> >>
> >> > This speeds things up a lot, but as shown in the patches
Duy Nguyen writes:
>> without
>> being caught, because msgfmt will catch this (and other common issues):
>>
>> po/de.po:23: 'msgid' and 'msgstr' entries do not both end with '\n'
>
> Ok good. And with the downside of degraded performance, sure remove
> all the *printf_ln()
Sounds good. Than
Duy Nguyen writes:
> On Thu, Jun 27, 2019 at 9:53 AM Duy Nguyen wrote:
>>
>> On Thu, Jun 27, 2019 at 2:58 AM Junio C Hamano wrote:
>> >
>> > Nguyễn Thái Ngọc Duy writes:
>> >
>> > > This is small refinements (except 4/4).
>> >
>> > What's the status of these?
>>
>> Small test fixup needed. I
"Dr. Adam Nielsen" writes:
> Hi everyone,
>
> any comments about the patch note from 04.06 ?
https://git.kernel.org/pub/scm/git/git.git/log/ shows that the topic
holding the patch has already been merged to the 'master' branch
about 6 days ago, at
https://git.kernel.org/pub/scm/git/git.git/comm
Here are some interesting sections I found when examining the test coverage
report. I am only highlighting these sections because they seem to include
non-trivial logic. In some cases, maybe the code isn't needed.
On 6/27/2019 1:05 PM, Derrick Stolee wrote:
> promisor-remote.c
> db27dca5 25) die(_
"Phillip Wood via GitGitGadget" writes:
> As I don't want to burden other callers with having to pass in a pointer
> to the end of the line the test for an abbreviated command is
> changed.
A comma missing somewhere between "As <>, <>",
perhaps after "end of the line"?
> This change should not
On Thu, Jun 27, 2019 at 5:37 AM Johannes Schindelin via GitGitGadget
wrote:
> Many Win32 API functions actually exist in two variants: one with
> the `A` suffix that takes ANSI parameters (`char *` or `const char *`)
> and one with the `W` suffix that takes Unicode parameters (`wchar_t *`
> or `co
On Wed, Jun 26, 2019 at 3:04 PM Junio C Hamano wrote:
>
> Johannes Schindelin writes:
>
> > Hi Matheus,
> >
> > On Tue, 18 Jun 2019, Matheus Tavares wrote:
> >
> >>[...]
> >> +/*
> >> + * Look for a recursive symlink at iter->base.path pointing to any
> >> directory on
> >> + * the previous stac
"Phillip Wood via GitGitGadget" writes:
> From: Phillip Wood
>
> The code that parses the todo list allows an unabbreviated command name
> to be followed by a space or a tab, but if the command name is
> abbreviated it only allows a space after it. Fix this inconsistency.
Makes sense.
>
> Sign
Jonathan Tan writes:
> Junio, what do you think of this small patch that just updates a test:
>
> https://public-inbox.org/git/20190605192624.129677-1-jonathanta...@google.com/
>
> For what it's worth, Stolee and Peff have replied and both of them seem
> to be OK with it.
Thanks for pointing out
On 25.06.19 13:31, Philip Oakley wrote:
only one minor point...
>>> + - For example, a pattern `doc/frotz/` matches `doc/frotz` directory,
>>> + but not `a/doc/frotz` directory; however `frotz/` matches `frotz`
>
> her I misread this as: "but not a `doc/frotz` directory;"
> i.e. the leadin
On 6/27/2019 9:04 AM, Johannes Schindelin wrote:
> Given that this bug was only caught by a failing CI build, it does make me
> wonder what other bugs are hidden and would slip into our code base just
> because of gaps in the code coverage.
Here are the lines introduced by this series that are not
Here is today's test coverage report.
Thanks,
-Stolee
[1] https://derrickstolee.github.io/git-test-coverage/reports/2019-06-27.htm
[2] https://derrickstolee.github.io/git-test-coverage/reports/2019-06-27.txt
---
pu f8df19e612605e564ac8006e61428c8b95391624
jch e1093b448f0c8fd5069bcff6cd
Hello
My name is Joe Akaba. I am a lawyer by profession. I would like to offer you
the closest relatives to my client. They inherit the sum of ($ 14.2 million)
Dollars that my client left in the bank before he died.
My client is a citizen of your country who died in a car accident with his wife
a
Duy Nguyen writes:
> If refs/heads/master does _not_ exist, then ref/heads/master can
> resolve to refs/heads/refs/heads/master, which I think is unexpected.
> "ref not found" error or something should be returned instead.
Ah, that was what I missed. Thanks.
SZEDER Gábor writes:
> However, we've always used the macOS build jobs as "build and test
> with the latest and greatest", i.e. they install the latest available
> Perforce and Git-LFS. To keep up with this tradition we'd need to run
> 'brew update' and in turn would need to 'brew install gcc'.
On Thu, Jun 27 2019, Johannes Schindelin wrote:
> Hi Ævar,
>
> On Wed, 26 Jun 2019, Johannes Schindelin wrote:
>
>> On Wed, 26 Jun 2019, Ævar Arnfjörð Bjarmason wrote:
>>
>> > This speeds things up a lot, but as shown in the patches & tests
>> > changed modifies the behavior where we have \0 in
From: Phillip Wood
commit 4a72486de9 ("fix cherry-pick/revert status after commit",
2019-04-16) used parse_insn_line() to parse the first line of the todo
list to check if it was a pick or revert. However if the todo list is
left over from an old cherry-pick or revert and references a commit that
From: Phillip Wood
Factor out the code that parses the name of the command at the start of
each line in the todo file into its own function so that it can be used
in the next commit.
As I don't want to burden other callers with having to pass in a pointer
to the end of the line the test for an a
From: Phillip Wood
The code that parses the todo list allows an unabbreviated command name
to be followed by a space or a tab, but if the command name is
abbreviated it only allows a space after it. Fix this inconsistency.
Signed-off-by: Phillip Wood
---
sequencer.c | 2 +-
1 file changed, 1 i
Thanks for the comments on v1. I've updated the commit message of the second
patch to try and explain why the new function is not a straight-forward copy
of the old code
If we cannot parse the oid in the sequencer todo file do not show an error
when running git status but instead report that a che
On 6/21/2019 7:53 AM, Jakub Narebski wrote:
Josh Steadmon writes:
On 2019.06.12 15:28, Ævar Arnfjörð Bjarmason wrote:
On Wed, Jun 12 2019, Josh Steadmon wrote:
trace_schema_validator can be used to verify that trace2 event output
conforms to the expectations set by the API documentation a
On Thu, Jun 27, 2019 at 8:42 PM Derrick Stolee wrote:
>
> On 6/27/2019 9:24 AM, Jeff Hostetler wrote:
> > On 6/27/2019 6:48 AM, Duy Nguyen wrote:
> >> On Tue, Jun 25, 2019 at 7:40 PM Derrick Stolee wrote:
> >>>
> >>> On 6/25/2019 6:29 AM, Duy Nguyen wrote:
> On Tue, Jun 25, 2019 at 3:06 AM J
When running a command with the 'exec' instruction during an
interactive rebase session, or for a range of commits using 'git
rebase -x', the output can be a bit garbled when the name of the
command is short enough:
$ git rebase -x true HEAD~5
Executing: true
Executing: true
Executing: tru
On 6/27/2019 9:24 AM, Jeff Hostetler wrote:
> On 6/27/2019 6:48 AM, Duy Nguyen wrote:
>> On Tue, Jun 25, 2019 at 7:40 PM Derrick Stolee wrote:
>>>
>>> On 6/25/2019 6:29 AM, Duy Nguyen wrote:
On Tue, Jun 25, 2019 at 3:06 AM Jeff Hostetler
wrote:
> I'm curious how big these EWAHs wil
On 6/27/2019 6:48 AM, Duy Nguyen wrote:
On Tue, Jun 25, 2019 at 7:40 PM Derrick Stolee wrote:
On 6/25/2019 6:29 AM, Duy Nguyen wrote:
On Tue, Jun 25, 2019 at 3:06 AM Jeff Hostetler wrote:
I'm curious how big these EWAHs will be in practice and
how useful an array of integers will be (esp
On Wed, Jun 26, 2019 at 03:35:59PM -0500, Taylor Blau wrote:
> Hi Gábor,
>
> On Sun, Jun 02, 2019 at 01:22:39PM +0200, SZEDER Gábor wrote:
> > On Sat, Jun 01, 2019 at 12:41:43AM +, brian m. carlson wrote:
> > > On 2019-05-30 at 19:32:41, Johannes Schindelin wrote:
> > > > Hi Gábor,
> > > >
> >
On Thu, Jun 27, 2019 at 7:54 PM Johannes Schindelin
wrote:
>
> Hi Duy,
>
> On Mon, 24 Jun 2019, Nguyễn Thái Ngọc Duy wrote:
>
> > diff --git a/builtin/grep.c b/builtin/grep.c
> > index 580fd38f41..85da7ee542 100644
> > --- a/builtin/grep.c
> > +++ b/builtin/grep.c
> > @@ -458,7 +458,8 @@ static in
Hi Junio,
On Wed, 26 Jun 2019, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
> > This is the continuation of nd/sha1-name-c-wo-the-repository. In that
> > series I sealed off one place in sha1-name.c that cannot walk trees
> > from arbitrary repositories. With tree-walk.c taking 'struc
Hi Duy,
On Mon, 24 Jun 2019, Nguyễn Thái Ngọc Duy wrote:
> diff --git a/builtin/grep.c b/builtin/grep.c
> index 580fd38f41..85da7ee542 100644
> --- a/builtin/grep.c
> +++ b/builtin/grep.c
> @@ -458,7 +458,8 @@ static int grep_submodule(struct grep_opt *opt,
> object = parse_object_o
On Thu, Jun 27, 2019 at 7:18 PM Ævar Arnfjörð Bjarmason
wrote:
> Why shouldn't we just move back to plain fprintf() with "\n"? Your
> 9a0a30aa4b ("strbuf: convenience format functions with \n automatically
> appended", 2012-04-23) doesn't explain why this is a convenience for
> translators.
>
> Wh
On Thu, Jun 27 2019, Duy Nguyen wrote:
> On Thu, Jun 27, 2019 at 1:00 PM Jeff King wrote:
>>
>> On Thu, Jun 27, 2019 at 01:25:15AM -0400, Jeff King wrote:
>>
>> > Taylor and I noticed a slowdown in p1451 between v2.20.1 and v2.21.0. I
>> > was surprised to find that it bisects to bbb15c5193 (fs
Hi Peff,
On Thu, 27 Jun 2019, Jeff King wrote:
> On Thu, Jun 27, 2019 at 01:25:15AM -0400, Jeff King wrote:
>
> > Taylor and I noticed a slowdown in p1451 between v2.20.1 and v2.21.0. I
> > was surprised to find that it bisects to bbb15c5193 (fsck: reduce word
> > legos to help i18n, 2018-11-10).
On Tue, Jun 25, 2019 at 7:40 PM Derrick Stolee wrote:
>
> On 6/25/2019 6:29 AM, Duy Nguyen wrote:
> > On Tue, Jun 25, 2019 at 3:06 AM Jeff Hostetler
> > wrote:
> >> I'm curious how big these EWAHs will be in practice and
> >> how useful an array of integers will be (especially as the
> >> pretty
On Wed, Jun 26, 2019 at 01:03:03PM -0700, Carlo Marcelo Arenas Belón wrote:
> an apparent typo for the environment variable was included with 81567caf87
> ("trace2: update docs to describe system/global config settings",
> 2019-04-15), and was missed when renamed variables by e4b75d6a1d
> ("trace2:
From: Johannes Schindelin
Many Win32 API functions actually exist in two variants: one with
the `A` suffix that takes ANSI parameters (`char *` or `const char *`)
and one with the `W` suffix that takes Unicode parameters (`wchar_t *`
or `const wchar_t *`).
The ANSI variant assumes that the strin
For many Win32 functions, there actually exist two variants: one that takes
const char * ("ANSI", meaning the current code page) and wchar_t *
("Unicode", i.e. UTF-16, at least for all practical matters).
These functions have "A" and "W" suffixes, respectively, e.g.
GetFileAttributesW(). The sy
From: Johannes Schindelin
Previously, we would have obtained the user name encoded in whatever the
current code page is.
Note: the "user name" here does not denote the full name but instead the
short logon name.
Signed-off-by: Johannes Schindelin
---
compat/mingw.c | 10 --
1 file cha
Hi Junio,
On Wed, 26 Jun 2019, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > ...
> > Ah hah!
> >
> > If we would not have plenty of exercise for the PCRE2 build options, I
> > would be worried. But AFAICT the CI build includes this all the time, so
> > we're fine.
>
> Well, I'd feel
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Junio C Hamano
---
archive.c | 4 +++-
blame.c| 4 ++--
builtin/rm.c | 2 +-
builtin/update-index.c | 2 +-
line-log.c | 7 ---
match-trees.c | 6 +++---
merge-recursive.c
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Junio C Hamano
---
cache.h | 4 ++--
match-trees.c | 12 +++-
merge-recursive.c | 4 ++--
t/helper/test-match-trees.c | 2 +-
4 files changed, 12 insertions(+), 10 deletions(-)
diff --git a
There are a couple of places where 'struct repository' is already passed
around, but the_repository is still used. Use the right repo.
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Junio C Hamano
---
merge-recursive.c | 35 ---
sequencer.c | 4 ++--
s
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Junio C Hamano
---
sha1-name.c | 10 +-
tree-walk.c | 12
tree-walk.h | 2 +-
3 files changed, 10 insertions(+), 14 deletions(-)
diff --git a/sha1-name.c b/sha1-name.c
index e8fb215e5c..3c9fa10af8 100644
--- a/sha1-name.c
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/cat-file.c | 3 ++-
builtin/grep.c | 6 --
builtin/pack-objects.c | 3 ++-
cache.h| 3 ++-
fast-import.c | 9 ++---
sha1-file.c| 5 +++--
tree-walk.c| 7 ---
7 files changed, 2
1 - 100 of 115 matches
Mail list logo