Denton,
On Wed, Oct 2, 2019 at 11:47 PM Denton Liu wrote:
>
> Hi Bert,
>
> > Subject: format-patch: document and exercise that -o does only create the
> > trailing directory
>
> s/does only create/only creates/ ?
>
> Anyway, as a prepatory patch, I don't t
Hi Bert,
> Subject: format-patch: document and exercise that -o does only create the
> trailing directory
s/does only create/only creates/ ?
Anyway, as a prepatory patch, I don't think that it's necessary. Maybe
it's just me but I assume that most tools create at most one
..fe7492353e 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -66,7 +66,9 @@ they are created in the current working directory. The
default path
can be set with the `format.outputDirectory` configuration option.
The `-o` option takes precedence over
Remove the mention of symlinks from the test description because
several tests that are not related to symlinks have been added since
this file was introduced long ago.
Signed-off-by: Kyle Meyer
---
t/t3000-ls-files-others.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/
In the previous commit, we noted that several places throughout merge
recursive both had a reason to use 'o'; some for a merge_options struct,
and others for a diff_filespec struct. Some places had both, forcing
one of the two to be renamed, though the choice was inconsistent. No
The name 'o' was used for the merge_options struct pointer taken by many
functions, but in a few places it was named 'opt'. Several functions
that didn't need merge_options instead used 'o' for a diff_filespec
argument or local. Some functions needed both a
Since we want to replace oid,mode pairs with a single diff_filespec,
we will soon want to be able to use the names 'o', 'a', and 'b' for
the three different file versions. Rename some local variables in
blob_unchanged() that would otherwise conflict.
Signed-off
When a2d5156c2b (resolve_gitlink_ref: ignore non-repository paths,
2016-01-22) added this test, the purpose was to check the 'ls-files
-o' didn't die() when processing the bogus repository. The expected
output didn't even need to be adjusted for the addition because the
Since we want to replace oid,mode pairs with a single diff_filespec,
we will soon want to be able to use the names 'o', 'a', and 'b' for
the three different file versions. Rename some local variables in
blob_unchanged() that would otherwise conflict.
Signed-off
In the previous commit, we noted that several places throughout merge
recursive both had a reason to use 'o'; some for a merge_options struct,
and others for a diff_filespec struct. Some places had both, forcing
one of the two to be renamed, though the choice was inconsistent. No
The name 'o' was used for the merge_options struct pointer taken by many
functions, but in a few places it was named 'opt'. Several functions
that didn't need merge_options instead used 'o' for a diff_filespec
argument or local. Some functions needed both a
ot;),
DIFF_PICKAXE_REGEX, PARSE_OPT_NONEG),
+ OPT_FILENAME('O', NULL, &options->orderfile,
+N_("control the order in which files appear in the
output")),
{ OPTION_CALLBACK, 0, "output"
On Wed, 20 Mar 2019 at 12:48, Nguyễn Thái Ngọc Duy wrote:
> + OPT_FILENAME('O', NULL, &options->orderfile,
> +N_("override diff.orderFile configuration
> variable")),
This doesn't really tell me *why* I wou
ot;),
DIFF_PICKAXE_REGEX, PARSE_OPT_NONEG),
+ OPT_FILENAME('O', NULL, &options->orderfile,
+N_("override diff.orderFile configuration
variable")),
{ OPTION_CALLBACK, 0, "output", opt
When a2d5156c2b (resolve_gitlink_ref: ignore non-repository paths,
2016-01-22) added this test, the purpose was to check the 'ls-files
-o' didn't die() when processing the bogus repository. The expected
output didn't even need to be adjusted for the addition because the
T_F(0, "pickaxe-regex", &options->pickaxe_opts,
> N_("treat in -S as extended POSIX regular
> expression"),
> DIFF_PICKAXE_REGEX, PARSE_OPT_NONEG),
> + OPT_FILENAME('O', NULL, &options->orde
)
OPT_BIT_F(0, "pickaxe-regex", &options->pickaxe_opts,
N_("treat in -S as extended POSIX regular
expression"),
DIFF_PICKAXE_REGEX, PARSE_OPT_NONEG),
+ OPT_FILENAME('O', NULL, &options-&g
Good point. I'll check it out. Thanks for the tip.
Thanks,
Peter
Thanks,
Peter Kostyukov
Senior Systems Engineer
Kohl's Department Stores - KIC
Office: 262-703-6533
On Sat, Nov 3, 2018 at 6:48 PM Philip Oakley wrote:
>
>
> On 03/11/2018 16:44, brian m. carlson wrote:
> > On Fri, Nov 02, 2018 a
On 03/11/2018 16:44, brian m. carlson wrote:
On Fri, Nov 02, 2018 at 11:10:51AM -0500, Peter Kostyukov wrote:
Wanted to bring to your attention an issue that we discovered on our
Windows Jenkins nodes with git scm installed (git.exe). Our Jenkins
servers don't have Internet access. It appears
On Fri, Nov 02, 2018 at 11:10:51AM -0500, Peter Kostyukov wrote:
> Wanted to bring to your attention an issue that we discovered on our
> Windows Jenkins nodes with git scm installed (git.exe). Our Jenkins
> servers don't have Internet access. It appears that git.exe is trying
> to connect to vario
Hello,
Wanted to bring to your attention an issue that we discovered on our
Windows Jenkins nodes with git scm installed (git.exe). Our Jenkins
servers don't have Internet access. It appears that git.exe is trying
to connect to various Cloudflare and Akamai CDN instances over the
Internet when it
(js/mingw-o-append) mingw: enable atomic O_APPEND
The new mingw_open_append() routine successfully opens the client side of
the named pipe, but the first write() to it fails with EBADF. Adding the
FILE_WRITE_DATA corrects the problem.
Signed-off-by: Jeff Hostetler jeffh...@microsoft.com
[jeffh
(js/mingw-o-append) mingw: enable atomic O_APPEND
The new mingw_open_append() routine successfully opens the client side of
the named pipe, but the first write() to it fails with EBADF. Adding the
FILE_WRITE_DATA corrects the problem.
Signed-off-by: Jeff Hostetler jeffh...@microsoft.com
[jeffh
first commit adds a new test to confirm the breakage and the
second commit fixes the problem. These could be squashed together or we can
just keep the fix and omit the test if that would be better.
d641097589 (js/mingw-o-append) mingw: enable atomic O_APPEND
The new mingw_open_append() routine
(js/mingw-o-append) mingw: enable atomic O_APPEND
The new mingw_open_append() routine successfully opens the client side of
the named pipe, but the first write() to it fails with EBADF. Adding the
FILE_WRITE_DATA corrects the problem.
Signed-off-by: Jeff Hostetler jeffh...@microsoft.com
[jeffh
This patch series implements an entirely alternate method of achieving
some of the same ends as the MIDX, using the approach suggested by
Jeff King from the RFC thread back in January[1]. You can now do:
core.abbrev = 20
core.validateAbbrev = false
Or:
core.abbrev = +2
core.valid
On Wed, Jun 06 2018, Ævar Arnfjörð Bjarmason wrote:
> On Mon, Jan 08 2018, Derrick Stolee wrote:
>
>> On 1/7/2018 5:42 PM, Ævar Arnfjörð Bjarmason wrote:
>>>
>>> On Sun, Jan 07 2018, Derrick Stolee jotted:
>>>
git log --oneline --raw --parents
Num Packs | Before MIDX | After MI
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 -
hough 'git grep -C -o ...' is an unusual invocation,
it is useful to (1) maintain as much consistency as reasonably makes
sense, and (2) to at least not be buggy.
I have also responded to Eric's suggestions in [2], and [3].
Thanks as always for your kind review :-).
Thanks,
Taylor
On Wed, May 09, 2018 at 07:00:10PM -0700, Taylor Blau wrote:
> > - they test with context (-C3) for us. It looks like GNU grep omits
> >context lines with "-o", but we show a bunch of blank lines. This is
> >I guess a bug (though it seems kind of an odd comb
umber --column mmap file
> > > >actual &&
> > > + test_cmp expected actual
> > > +'
> > > +
> > > cat >expected < > > hello.c
> > > 4:int main(int argc, const char **argv)
> >
> > We should test t
mp expected actual
> > +'
> > +
> > cat >expected < > hello.c
> > 4:int main(int argc, const char **argv)
>
> We should test this a lot more, I think a good way to do that would be
> to extend this series by first importing GNU grep's -o tests, see
&
On Sat, May 05, 2018 at 03:36:12AM -0400, Eric Sunshine wrote:
> On Sat, May 5, 2018 at 12:03 AM, Taylor Blau wrote:
> > Teach GNU grep(1)'s '-o' ('--only-matching') to 'git-grep'. This option
> > prints only the matching components of each l
On Sat, May 5, 2018 at 12:03 AM, Taylor Blau wrote:
> 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
On Sat, May 05 2018, Taylor Blau wrote:
> +--o::
> +--only-matching::
> + Show only the matching part of the lines.
> +
Makes sense to steal GNU grep's description here:
Print only the matched (non-empty) parts of a matching line, with
each such part on a sep
Hi,
Attached is a series to teach 'git-grep(1)' how to respond to
'--only-matching' (a-la GNU grep(1)'s --only-matching, including an '-o'
synonym) to only print the matching component(s) of a line. It is based
on v4 of tb/grep-colno, which was sent in [1].
Thi
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 --heading git -- README.m
Add the missing `-o` shortcut for `--push-option` to the synopsis.
Add the missing `-d` shortcut for `--delete` in the main section.
Signed-off-by: Andreas Heiduk
Reviewed-by: Martin Ågren
---
Documentation/git-push.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a
;> > @@ -1412,12 +1422,13 @@ int unpack_trees(unsigned len, struct tree_desc
>>>>> > *t, struct unpack_trees_options
>>>>> > WRITE_TREE_SILENT |
>>>>> >
t tree_desc
>>>> > *t, struct unpack_trees_options
>>>> > WRITE_TREE_SILENT |
>>>> > WRITE_TREE_REPAIR);
>>>> > }
>>>> > -
t, struct unpack_trees_options
>>> > WRITE_TREE_SILENT |
>>> > WRITE_TREE_REPAIR);
>>> > }
>>> > - move_index_extensions(&o->result, o->dst_index);
>>> > +
WRITE_TREE_SILENT |
>> > WRITE_TREE_REPAIR);
>> > }
>> > - move_index_extensions(&o->result, o->dst_index);
>> > + move_index_extensions(&o->result, o->src_index);
>>
>> While t
Hi Duy,
On Sun, 29 Apr 2018, Duy Nguyen wrote:
> On Tue, Apr 24, 2018 at 8:50 AM, Elijah Newren wrote:
> > Currently, all callers of unpack_trees() set o->src_index == o->dst_index.
> > The code in unpack_trees() does not correctly handle them being different.
> > Th
On Tue, Apr 24, 2018 at 8:50 AM, Elijah Newren wrote:
> Currently, all callers of unpack_trees() set o->src_index == o->dst_index.
> The code in unpack_trees() does not correctly handle them being different.
> There are two separate issues:
>
> First, there is the possibility
Add the missing `-o` shortcut for `--push-option` to the synopsis.
Add the missing `-d` shortcut for `--delete` in the main section.
Signed-off-by: Andreas Heiduk
Reviewed-by: Martin Ågren
---
Documentation/git-push.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a
Currently, all callers of unpack_trees() set o->src_index == o->dst_index.
The code in unpack_trees() does not correctly handle them being different.
There are two separate issues:
First, there is the possibility of memory corruption. Since
unpack_trees() creates a temporary index in o-&
4,20 @@ int unpack_trees(unsigned len, struct tree_desc *t,
> struct unpack_trees_options
> o->result.timestamp.sec = o->src_index->timestamp.sec;
> o->result.timestamp.nsec = o->src_index->timestamp.nsec;
> o->result.version = o->src_index->ver
Elijah Newren writes:
> Marked as PATCH v2, though I marked the previous one as "RFC PATCH v10
> 32.5/36" because I thought I was going to put it in my series. But it is
> an independent fix that my series needs.
Thanks. Let's take this before the remainder of the series ;-)
Currently, all callers of unpack_trees() set o->src_index == o->dst_index.
The code in unpack_trees() does not correctly handle them being different.
There are two separate issues:
First, there is the possibility of memory corruption. Since
unpack_trees() creates a temporary index in o-&
Previously, if !o->detect_rename then get_renames() would return an
empty string_list, and then process_renames() would have nothing to
iterate over. It seems more straightforward to simply avoid calling
either function in that case.
Reviewed-by: Stefan Beller
Signed-off-by: Elijah New
Previously, if !o->detect_rename then get_renames() would return an
empty string_list, and then process_renames() would have nothing to
iterate over. It seems more straightforward to simply avoid calling
either function in that case.
Reviewed-by: Stefan Beller
Signed-off-by: Elijah New
On Tue, Jan 30, 2018 at 3:25 PM, Elijah Newren wrote:
> Previously, if !o->detect_rename then get_renames() would return an
> empty string_list, and then process_renames() would have nothing to
> iterate over. It seems more straightforward to simply avoid calling
> either functi
Previously, if !o->detect_rename then get_renames() would return an
empty string_list, and then process_renames() would have nothing to
iterate over. It seems more straightforward to simply avoid calling
either function in that case.
Signed-off-by: Elijah Newren
---
merge-recursive.c |
Previously, if !o->detect_rename then get_renames() would return an
empty string_list, and then process_renames() would have nothing to
iterate over. It seems more straightforward to simply avoid calling
either function in that case.
Signed-off-by: Elijah Newren
---
merge-recursive.c |
Previously, if !o->detect_rename then get_renames() would return an
empty string_list, and then process_renames() would have nothing to
iterate over. It seems more straightforward to simply avoid calling
either function in that case.
Signed-off-by: Elijah Newren
---
merge-recursive.c |
Previously, if !o->detect_rename then get_renames() would return an
empty string_list, and then process_renames() would have nothing to
iterate over. It seems more straightforward to simply avoid calling
either function in that case.
Signed-off-by: Elijah Newren
---
merge-recursive.c |
Previously, if !o->detect_rename then get_renames() would return an
empty string_list, and then process_renames() would have nothing to
iterate over. It seems more straightforward to simply avoid calling
either function in that case.
Signed-off-by: Elijah Newren
---
merge-recursive.c |
Previously, if !o->detect_rename then get_renames() would return an
empty string_list, and then process_renames() would have nothing to
iterate over. It seems more straightforward to simply avoid calling
either function in that case.
Signed-off-by: Elijah Newren
---
merge-recursive.c |
git archive -o name.tar.gz generates a gzipped file without needing an
explicit --format switch.
However, git archive -o name.tar.gz --remote [url] generates a tar
file, which is unexpected, bandwidth-heavier, and additionally in some
cases it's not immediately obvious that this has hap
Previously, if !o->detect_rename then get_renames() would return an
empty string_list, and then process_renames() would have nothing to
iterate over. It seems more straightforward to simply avoid calling
either function in that case.
Signed-off-by: Elijah Newren
---
merge-recursive.c
-clone.sh
index 9c56f771b..7e65013c5 100755
--- a/t/t5601-clone.sh
+++ b/t/t5601-clone.sh
@@ -332,13 +332,13 @@ expect_ssh () {
1)
;;
2)
- echo "ssh: $1 git-upload-pack '$2&
On Thu, Jun 29, 2017 at 03:11:37PM -0700, Luck, Tony wrote:
> So there is a "--cc-cmd" option that can do the same as those "-cc" arguments.
> Combine that with --suppress-cc=bodycc and things get a bit more automated.
Yeah, whatever works for you.
I did play with cc-cmd somewhat but can't be bot
o wrote:
>>> Miguel Torroja writes:
>>>
>>>> The option -G of p4 (python marshal output) gives more context about the
>>>> data being output. That's useful when using the command "change -o" as
>>>> we can distinguish between warn
> On 24 Jun 2017, at 13:49, Luke Diamand wrote:
>
> On 22 June 2017 at 18:32, Junio C Hamano wrote:
>> Miguel Torroja writes:
>>
>>> The option -G of p4 (python marshal output) gives more context about the
>>> data being output. That's useful when
t 18:32, Junio C Hamano wrote:
>> Miguel Torroja writes:
>>
>>> The option -G of p4 (python marshal output) gives more context about the
>>> data being output. That's useful when using the command "change -o" as
>>> we can distinguish between warnin
On 22 June 2017 at 18:32, Junio C Hamano wrote:
> Miguel Torroja writes:
>
>> The option -G of p4 (python marshal output) gives more context about the
>> data being output. That's useful when using the command "change -o" as
>> we can distinguish bet
Miguel Torroja writes:
> The option -G of p4 (python marshal output) gives more context about the
> data being output. That's useful when using the command "change -o" as
> we can distinguish between warning/error line and real change description.
>
> Some p4 p
The option -G of p4 (python marshal output) gives more context about the
data being output. That's useful when using the command "change -o" as
we can distinguish between warning/error line and real change description.
Some p4 plugin/hooks in the server side generates some warning
Am 29.03.2017 um 06:54 schrieb Christian Couder:
On Tue, Mar 28, 2017 at 11:49 PM, Jeff King wrote:
On Tue, Mar 28, 2017 at 11:15:12PM +0200, Christian Couder wrote:
On Sun, Mar 26, 2017 at 3:43 PM, René Scharfe wrote:
FreeBSD implements getcwd(3) as a syscall, but falls back to a version
b
On Tue, Mar 28, 2017 at 11:49 PM, Jeff King wrote:
> On Tue, Mar 28, 2017 at 11:15:12PM +0200, Christian Couder wrote:
>
>> On Sun, Mar 26, 2017 at 3:43 PM, René Scharfe wrote:
>> > FreeBSD implements getcwd(3) as a syscall, but falls back to a version
>> > based on readdir(3) if it fails for som
On Tue, Mar 28, 2017 at 11:15:12PM +0200, Christian Couder wrote:
> On Sun, Mar 26, 2017 at 3:43 PM, René Scharfe wrote:
> > FreeBSD implements getcwd(3) as a syscall, but falls back to a version
> > based on readdir(3) if it fails for some reason. The latter requires
> > permissions to read and
On Tue, Mar 28, 2017 at 11:24 PM, Stefan Beller wrote:
> On Tue, Mar 28, 2017 at 2:15 PM, Christian Couder
> wrote:
>> On Sun, Mar 26, 2017 at 3:43 PM, René Scharfe wrote:
>>> FreeBSD implements getcwd(3) as a syscall, but falls back to a version
>>> based on readdir(3) if it fails for some reas
On Tue, Mar 28, 2017 at 2:15 PM, Christian Couder
wrote:
> On Sun, Mar 26, 2017 at 3:43 PM, René Scharfe wrote:
>> FreeBSD implements getcwd(3) as a syscall, but falls back to a version
>> based on readdir(3) if it fails for some reason. The latter requires
>> permissions to read and execute pat
On Sun, Mar 26, 2017 at 3:43 PM, René Scharfe wrote:
> FreeBSD implements getcwd(3) as a syscall, but falls back to a version
> based on readdir(3) if it fails for some reason. The latter requires
> permissions to read and execute path components, while the former does
> not. That means that if
Zenobiusz Kunegunda writes:
> Od: "Junio C Hamano"
> Do: "René Scharfe" ;
> Wysłane: 2:40 Poniedziałek 2017-03-27
> Temat: Re: [PATCH] strbuf: support long paths w/o read rights in
> strbuf_getcwd() on FreeBSD
>
>>
>> Nicely analy
Od: "Junio C Hamano"
Do: "René Scharfe" ;
Wysłane: 2:40 Poniedziałek 2017-03-27
Temat: Re: [PATCH] strbuf: support long paths w/o read rights in
strbuf_getcwd() on FreeBSD
>
> Nicely analysed and fixed (or is the right word "worked around"?)
>
> Th
René Scharfe writes:
> FreeBSD implements getcwd(3) as a syscall, but falls back to a version
> based on readdir(3) if it fails for some reason. The latter requires
> permissions to read and execute path components, while the former does
> not. That means that if our buffer is too small and we'
FreeBSD implements getcwd(3) as a syscall, but falls back to a version
based on readdir(3) if it fails for some reason. The latter requires
permissions to read and execute path components, while the former does
not. That means that if our buffer is too small and we're missing
rights we could get
one shell glob pattern per line.
+ File indicating how to order files within a diff.
+ See the '-O' option to linkgit:git-diff[1] for details.
If `diff.orderFile` is a relative pathname, it is treated as
relative to the top of the work tree.
- Can be o
one shell glob pattern per line.
+ File indicating how to order files within a diff.
+ See the '-O' option to linkgit:git-diff[1] for details.
If `diff.orderFile` is a relative pathname, it is treated as
relative to the top of the work tree.
- Can
--git a/git-mergetool.sh b/git-mergetool.sh
index e52b4e4f2..b506896dc 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -421,7 +421,7 @@ main () {
prompt=true
;;
-O*)
- orderfile=&qu
--git a/git-mergetool.sh b/git-mergetool.sh
index e52b4e4f2..b506896dc 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -421,7 +421,7 @@ main () {
prompt=true
;;
-O*)
- orderfile=&qu
--git a/git-mergetool.sh b/git-mergetool.sh
index e52b4e4f2..b506896dc 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -421,7 +421,7 @@ main () {
prompt=true
;;
-O*)
- orderfile=&qu
David Aguilar writes:
>> I only see 4/4 in v4; am I correct to assume that 1-3/4 of v4 are
>> the same as their counterparts in v3?
>
> Yes, 1-3 are unchanged since v3.
> Thanks for checking,
I'll queue these four with Reviewed-by's from j6t.
Thanks, both.
On Mon, Oct 10, 2016 at 11:28:35AM -0700, Junio C Hamano wrote:
> David Aguilar writes:
>
> > Teach mergetool to pass "-O" down to `git diff` when
> > specified on the command-line.
> >
> > Helped-by: Johannes Sixt
> > Signed-off-by: David Aguil
David Aguilar writes:
> Teach mergetool to pass "-O" down to `git diff` when
> specified on the command-line.
>
> Helped-by: Johannes Sixt
> Signed-off-by: David Aguilar
> ---
> Since v3:
>
> I missed one last piped invocation of "git mergetool"
With this final fixup, the series looks good to me, and I have no
further comments.
Reviewed-by: Johannes Sixt
-- Hannes
Teach mergetool to pass "-O" down to `git diff` when
specified on the command-line.
Helped-by: Johannes Sixt
Signed-off-by: David Aguilar
---
Since v3:
I missed one last piped invocation of "git mergetool" in the tests,
which has been fixed.
Documentation/gi
Teach mergetool to pass "-O" down to `git diff` when
specified on the command-line.
Helped-by: Johannes Sixt
Signed-off-by: David Aguilar
---
Changes since v2:
The tests no longer rely on "grep -A" and instead use "git grep"
for portability. The mergetool output
rompt] [file to merge]
...'
+USAGE='[--tool=tool] [--tool-help] [-y|--no-prompt|--prompt] [-O]
[file to merge] ...'
SUBDIRECTORY_OK=Yes
NONGIT_OK=Yes
OPTIONS_SPEC=
@@ -390,6 +390,7 @@ print_noop_and_exit () {
main () {
prompt=$(git config --bool mergetool.prompt)
gues
Teach mergetool to pass "-O" down to `git diff` when
specified on the command-line.
Signed-off-by: David Aguilar
---
This is a replacement patch for 4/4 from the original series.
The changes are stylistic -- the "order_file" variable name and
"-O" in the usage w
Teach mergetool to pass "-O" down to `git diff` when
specified on the command-line.
Signed-off-by: David Aguilar
---
Documentation/git-mergetool.txt | 10 ++
git-mergetool.sh| 14 --
t/t7610-mergetool.sh| 27 ++
Using the a Linux-kernel-derived doubly-linked list
implementation from the Userspace RCU library allows us to
enqueue and delete items from the object request queue in
constant time.
This change reduces enqueue times in the prefetch() function
where object request queue could grow to several thou
On 09/06/16 18:12, Jeff King wrote:
> On Thu, Jun 09, 2016 at 03:34:59PM +0100, Ramsay Jones wrote:
>
>> Just FYI, this patch removes the last use of write_or_whine() - should it
>> be removed?
>
> That sounds reasonable. Want to do a patch on top?
OK, will do.
ATB,
Ramsay Jones
--
To unsub
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> Jeff King writes:
>>
>>> --- a/send-pack.c
>>> +++ b/send-pack.c
>>> @@ -36,18 +36,15 @@ int option_parse_push_signed(const struct option *opt,
>>> die("bad %s argument: %s", opt->long_name, arg);
>>> }
>>>
>>> -static int feed_object(co
On Thu, Jun 09, 2016 at 09:40:42AM -0700, Junio C Hamano wrote:
> >>for (i = 0; i < extra->nr; i++)
> >> - if (!feed_object(extra->sha1[i], po.in, 1))
> >> - break;
> >> + feed_object(extra->sha1[i], po_in, 1);
> >
> > I may have missed the obvious, but doesn
On Thu, Jun 09, 2016 at 03:34:59PM +0100, Ramsay Jones wrote:
> Just FYI, this patch removes the last use of write_or_whine() - should it
> be removed?
That sounds reasonable. Want to do a patch on top?
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a mess
Matthieu Moy writes:
> Jeff King writes:
>
>> --- a/send-pack.c
>> +++ b/send-pack.c
>> @@ -36,18 +36,15 @@ int option_parse_push_signed(const struct option *opt,
>> die("bad %s argument: %s", opt->long_name, arg);
>> }
>>
>> -static int feed_object(const unsigned char *sha1, int fd, int
On 09/06/16 13:10, Matthieu Moy wrote:
> Jeff King writes:
>
>> --- a/send-pack.c
>> +++ b/send-pack.c
>> @@ -36,18 +36,15 @@ int option_parse_push_signed(const struct option *opt,
>> die("bad %s argument: %s", opt->long_name, arg);
>> }
>>
>> -static int feed_object(const unsigned char
1 - 100 of 388 matches
Mail list logo
