On 09/19/2017 02:08 AM, Stefan Beller wrote:
>> I am hoping that this last one is not allowed and we can use the
>> "same condition is checked every time we loop" version that hides
>> the uglyness inside the macro.
>
> By which you are referring to Jonathans solution posted.
> Maybe we can combin
On Tue, 2017-09-19 at 12:01 +0900, Junio C Hamano wrote:
>
> Hmph. I cannot shake this nagging feeling that this is probably a
> solution that is overly narrow to a single problem that won't scale
> into the future.
>
> [...snip good point...]
>
> If we drop the "verification" step from the abo
It will prove convenient in upcoming patches.
Signed-off-by: Michael Haggerty
---
refs/packed-backend.c | 23 ---
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/refs/packed-backend.c b/refs/packed-backend.c
index e411501871..a3d9210cb0 100644
--- a/refs/packed
Now that the `packed-refs` backend doesn't use `ref_cache`, there is
nobody left who might want to store peeled values of references in
`ref_cache`. So remove that feature.
Signed-off-by: Michael Haggerty
---
refs/packed-backend.c | 9 -
refs/ref-cache.c | 42 +-
We've made huge changes to this file, and some of the old names and
comments are no longer very fitting. So rename a bunch of things:
* `struct packed_ref_cache` → `struct snapshot`
* `acquire_packed_ref_cache()` → `acquire_snapshot()`
* `release_packed_ref_buffer()` → `clear_snapshot_buffer()`
*
This tightens up the parsing a bit; previously, stray header-looking
lines would have been processed.
Signed-off-by: Michael Haggerty
---
refs/packed-backend.c | 35 ---
1 file changed, 24 insertions(+), 11 deletions(-)
diff --git a/refs/packed-backend.c b/refs/p
We're about to stop storing packed refs in a `ref_cache`. That means
that the only way we have left to optimize `peel_ref()` is by checking
whether the reference being peeled is the one currently being iterated
over (in `current_ref_iter`), and if so, using `ref_iterator_peel()`.
But this can be do
References are iterated over in order by refname, but reflogs are not.
Some consumers of reference iteration care about the difference. Teach
each `ref_iterator` to keep track of whether its output is ordered.
`overlay_ref_iterator` is one of the picky consumers. Add a sanity
check in `overlay_ref
The old code parsed the traits in the `packed-refs` header by looking
for the string " trait " (i.e., the name of the trait with a space on
either side) in the header line. This is fragile, because if any other
implementation of Git forgets to write the trailing space, the last
trait would silently
No code has been changed. This will make subsequent patches more
self-contained.
Signed-off-by: Michael Haggerty
---
refs/packed-backend.c | 48
1 file changed, 24 insertions(+), 24 deletions(-)
diff --git a/refs/packed-backend.c b/refs/packed-ba
Since `packed_ref_iterator` is now delegating to
`mmapped_ref_iterator` rather than `cache_ref_iterator` to do the
heavy lifting, there is no need to keep the two iterators separate. So
"inline" `mmapped_ref_iterator` into `packed_ref_iterator`. This
removes a bunch of boilerplate.
Signed-off-by:
Rather than store the peeling state (i.e., the one defined by traits
in the `packed-refs` file header line) in a local variable in
`read_packed_refs()`, store it permanently in `packed_ref_cache`. This
will be needed when we stop reading all packed refs at once.
Signed-off-by: Michael Haggerty
--
Instead of reading the reference from the `ref_cache`, read it
directly from the mmapped buffer.
Signed-off-by: Michael Haggerty
---
refs/packed-backend.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/refs/packed-backend.c b/refs/packed-backend.c
index 53d0b7
If a reference is broken, suppress its peeled value.
Signed-off-by: Michael Haggerty
---
refs/packed-backend.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/refs/packed-backend.c b/refs/packed-backend.c
index 312116a99d..724c88631d 100644
--- a/refs/packed-backen
This is v2 of a patch series that changes the reading and caching of
the `packed-refs` file to use `mmap()`. Thanks to Junio, Stefan, and
Johannes for their comments about v1 [1].
The main change since v1 is to accommodate Windows, which doesn't let
you replace a file using `rename()` if the file
From: Jeff King
If the underlying iterator is ordered, then `prefix_ref_iterator` can
stop as soon as it sees a refname that comes after the prefix. This
will rarely make a big difference now, because `ref_cache_iterator`
only iterates over the directory containing the prefix (and usually
the pre
Now that we have an efficient way to iterate, in order, over the
mmapped contents of the `packed-refs` file, we can use that directly
to implement reference iteration for the `packed_ref_store`, rather
than iterating over the `ref_cache`. This is the next step towards
getting rid of the `ref_cache`
Add a new `mmapped_ref_iterator`, which can iterate over the
references in an mmapped `packed-refs` file directly. Use this
iterator from `read_packed_refs()` to fill the packed refs cache.
Note that we are not yet willing to promise that the new iterator
generates its output in order. That doesn'
Now that everything has been changed to read what it needs directly
out of the `packed-refs` file, `packed_ref_store` doesn't need to
maintain a `ref_cache` at all. So get rid of it.
First of all, this will save a lot of memory and lots of little
allocations. Instead of needing to store complicate
Extract some helper functions for reporting errors. While we're at it,
prevent them from spewing unlimited output to the terminal. These
functions will soon have more callers.
These functions accept the problematic line as a `(ptr, len)` pair
rather than a NUL-terminated string, and `die_invalid_l
Instead of copying data from the `packed-refs` file one line at time
and then processing it, process the data in place as much as possible.
Also, instead of processing one line per iteration of the main loop,
process a reference line plus its corresponding peeled line (if
present) together.
Note
It's still done in a pretty stupid way, involving more data copying
than necessary. That will improve in future commits.
Signed-off-by: Michael Haggerty
---
refs/packed-backend.c | 42 --
1 file changed, 32 insertions(+), 10 deletions(-)
diff --git a/refs
Keep a copy of the `packed-refs` file contents in memory for as long
as a `packed_ref_cache` object is in use:
* If the system allows it, keep the `packed-refs` file mmapped.
* If not (either because the system doesn't support `mmap()` at all,
or because a file that is currently mmapped cannot
It doesn't actually matter now, because the references are only
iterated over to fill the associated `ref_cache`, which itself puts
them in the correct order. But we want to get rid of the `ref_cache`,
so we want to be able to iterate directly over the `packed-refs`
buffer, and then the iteration w
Jonathan Tan writes:
> For those interested in partial clones and/or missing objects in repos,
> I've updated my original partialclone patches to not require an explicit
> list of promises. Fetch/clone still only permits exclusion of blobs, but
> the infrastructure is there for a local repo to su
On Mon, Sep 18, 2017 at 04:17:24PM -0700, Jonathan Nieder wrote:
> phionah bugosi wrote:
>
> > Just to reecho a previous change requested before in one of the mail
> > threads, we currently have two global variables declared:
> >
> > struct mru packed_git_mru_storage;
> > struct mru *packed_git_m
On Mon, Sep 18, 2017 at 07:46:24PM -0700, Jonathan Nieder wrote:
> Jeff King wrote:
>
> > When we fail to open $GIT_DIR/info/alternates, we silently
> > assume there are no alternates. This is the right thing to
> > do for ENOENT, but not for other errors.
> >
> > A hard error is probably overkil
On Mon, Sep 18, 2017 at 07:42:53PM -0700, Jonathan Nieder wrote:
> Jeff King wrote:
>
> > Reported-by: Michael Haggerty
> > Signed-off-by: Jeff King
> > ---
> > sha1_file.c | 29 +
> > 1 file changed, 9 insertions(+), 20 deletions(-)
>
> Thanks for tracking it down
On Mon, Sep 18, 2017 at 07:36:03PM -0700, Jonathan Nieder wrote:
> Jeff King wrote:
>
> > This series fixes a regression in v2.11.1 where we might read past the
> > end of an mmap'd buffer. It was introduced in cf3c635210,
>
> The above information is super helpful. Can it go in one of the comm
Jameson Miller writes:
> Improve the performance of the directory listing logic when it wants to list
> non-empty ignored directories. In order to show non-empty ignored directories,
> the existing logic will recursively iterate through all contents of an ignored
> directory. This change introduc
Jonathan Nieder writes:
>> test_expect_success 'showing the superproject correctly' '
>
> With the two tweaks mentioned above,
> Reviewed-by: Jonathan Nieder
I agree with the fixes to the test titles suggested, so I'll queue
the patch with the fixes squashed in. Hearing "yeah, the titles
were
Kaartic Sivaraam writes:
> Signed-off-by: Kaartic Sivaraam
> ---
> t/README | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/t/README b/t/README
> index 2f95860369751..4b079e4494d93 100644
> --- a/t/README
> +++ b/t/README
> @@ -265,12 +265,12 @@ or:
>
> $ s
Junio C Hamano writes:
> But the point is that we do not want such an overhead in core, as
> all of that is a useless waste of the cycle for a site that wants to
> store the push certificate away outside of the repository itself.
By this I do not mean that cert blobs shouldn't become part of the
Ian Campbell writes:
> This can be useful e.g. in `filter-branch` when rewritting tags produced by
> older versions of Git, such as v2.6.12-rc2..v2.6.13-rc3 in the Linux kernel
> source tree:
>
> $ git cat-file tag v2.6.12-rc2
> object 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
>
Ramsay Jones wrote:
> Every test in this file, except one, is marked with the PIPE prereq.
> However, that lone test ('set up svn repo'), only performs some setup
> work and checks whether the following test should be executed (by
> setting an additional SVNREPO prerequisite). Since the following
Ramsay Jones wrote:
> Signed-off-by: Ramsay Jones
> ---
> t/test-lib.sh | 10 ++
> 1 file changed, 2 insertions(+), 8 deletions(-)
Reviewed-by: Jonathan Nieder
Jeff King wrote:
> When we fail to open $GIT_DIR/info/alternates, we silently
> assume there are no alternates. This is the right thing to
> do for ENOENT, but not for other errors.
>
> A hard error is probably overkill here. If we fail to read
> an alternates file then either we'll complete our o
Jeff King wrote:
> Reported-by: Michael Haggerty
> Signed-off-by: Jeff King
> ---
> sha1_file.c | 29 +
> 1 file changed, 9 insertions(+), 20 deletions(-)
Thanks for tracking it down.
Reviewed-by: Jonathan Nieder
[...]
> +++ b/sha1_file.c
[...]
> @@ -427,28 +427,
Jeff King wrote:
> This series fixes a regression in v2.11.1 where we might read past the
> end of an mmap'd buffer. It was introduced in cf3c635210,
The above information is super helpful. Can it go in one of the commit
messages?
> but
Hi,
Øystein Walle wrote:
> Running `git fetch --unshallow` on a repo that is not in fact shallow
> produces a fatal error message.
Hm, can you say more about the context? From a certain point of view,
it might make sense for that command to succeed instead: if the repo
is already unshallow, the
Johannes Schindelin writes:
>> Do you have a concrete suggestion to make these individual entries more
>> helpful for people who may want go back to the original thread in doing
>> so? In-reply-to: or References: fields of the "What's cooking" report
>> would not help. I often have the message
Lars Schneider writes:
> SZEDER noticing a bug in this series that I was about to fix:
> https://public-inbox.org/git/3b175d35-5b1c-43cd-a7e9-85693335b...@gmail.com/
>
> I assume at this point a new patch is better than a re-roll, right?
Thanks, yes indeed.
Santiago Torres writes:
> - *if there is a hook* the blob is computed, but it is up to the
> hook itself to store it *somewhere*. This makes me feel like it's
> somewhat of a useless waste of computation if the hook is not
> meant to handle it anyway(which is just a post-rec
Derrick Stolee writes:
>> But I do not think we want this "clever" optimization that involves
>> 'n' in the first place.
+ while (count++ < 10) {
>>> + for (i = 0; i < n; i++)
>>> + ((unsigned int*)oid.hash)[i] = hash_base;
>>
>> Does it make sense to assume
On Mon, Sep 18, 2017 at 4:52 PM, Junio C Hamano wrote:
> Max Kirillov writes:
>
>> --match ::
>> Only consider tags matching the given `glob(7)` pattern,
>> - excluding the "refs/tags/" prefix. This can be used to avoid
>> - leaking private tags from the repository. If given multi
Jeff King writes:
> We could also just make a NUL-terminated copy of the input
> bytes and operate on that. But since all but one caller
> already is passing a string, instead let's just fix that
> caller to provide NUL-terminated input in the first place,
> by swapping out mmap for strbuf_read_f
> I am hoping that this last one is not allowed and we can use the
> "same condition is checked every time we loop" version that hides
> the uglyness inside the macro.
By which you are referring to Jonathans solution posted.
Maybe we can combine the two solutions (checking for thelist
to not be NU
Max Kirillov writes:
> --match ::
> Only consider tags matching the given `glob(7)` pattern,
> - excluding the "refs/tags/" prefix. This can be used to avoid
> - leaking private tags from the repository. If given multiple times, a
> - list of patterns will be accumulated, and
Hi,
phionah bugosi wrote:
> Just to reecho a previous change requested before in one of the mail
> threads, we currently have two global variables declared:
>
> struct mru packed_git_mru_storage;
> struct mru *packed_git_mru = &packed_git_mru_storage;
>
> We normally use pointers in C to point or
Hi,
Gilles Van Assche wrote:
> Hi Johannes,
>> SHA-256 got much more cryptanalysis than SHA3-256 […].
>
> I do not think this is true. Keccak/SHA-3 actually got (and is still
> getting) a lot of cryptanalysis, with papers published at renowned
> crypto conferences [1].
>
> Keccak/SHA-3 is recogni
Hi Gilles,
On Mon, 18 Sep 2017, Gilles Van Assche wrote:
> > SHA-256 got much more cryptanalysis than SHA3-256 […].
>
> I do not think this is true.
Please read what I said again: SHA-256 got much more cryptanalysis than
SHA3-256.
I never said that SHA3-256 got little cryptanalysis. Personally
>> instead compared to the proposed configuration above.
>> (Even better yet, then people could play around with "v1 only"
>> and see how it falls apart on old servers)
>
> Except we can't start with an explicit whitelist because we must
> fallback to v0 if v1 isn't supported otherwise we would bre
>> Took a little while but here is a more clean patch creating individual
>> submodules for the nesting.
>>
>> Cheers Heiko
Thanks for writing this test!
>
> Thanks. Stefan, does this look good to you now?
Yes, though there are nits below.
> It is not quite clear which step is expected to fail
On 09/18, Stefan Beller wrote:
> >> From a users POV this may be frustrating as I would imagine that
> >> people want to run
> >>
> >> git config --global protocol.version 2
> >>
> >> to try it out and then realize that some of their hosts do not speak
> >> 2, so they have to actually configure i
>> From a users POV this may be frustrating as I would imagine that
>> people want to run
>>
>> git config --global protocol.version 2
>>
>> to try it out and then realize that some of their hosts do not speak
>> 2, so they have to actually configure it per repo/remote.
>
> The point would be to
> -Original Message-
> From: Johannes Schindelin [mailto:johannes.schinde...@gmx.de]
> Sent: Monday, September 18, 2017 10:25 AM
> To: Ben Peart
> Cc: david.tur...@twosigma.com; ava...@gmail.com;
> christian.cou...@gmail.com; git@vger.kernel.org; gits...@pobox.com;
> pclo...@gmail.com; p.
On Mon, Sep 18, 2017 at 7:22 AM, Santiago Torres wrote:
> Hello, everyone.
>
> Sorry for being late in this thread, I was making sure I didn't say
> anything outrageously wrong.
>
>> That's Stefan; I wouldn't have suggested any approach that uses the
>> blob whose sole purpose is to serve as a tem
On Sun, Sep 17, 2017 at 1:44 PM, Christian Couder
wrote:
> On Sun, Sep 17, 2017 at 10:42 PM, Christian Couder
> wrote:
>> On Sun, Sep 17, 2017 at 10:17 PM, phionah bugosi wrote:
>>> Signed-off-by: phionah bugosi
>>> ---
>>> builtin/pack-objects.c | 5 +++--
>>> cache.h| 7 ---
Improve the performance of the directory listing logic when it wants to list
non-empty ignored directories. In order to show non-empty ignored directories,
the existing logic will recursively iterate through all contents of an ignored
directory. This change introduces the optimization to stop itera
This is the second version of my patches to improve handling of
ignored files
I have decided to break the original patch series into two parts:
1) Perf improvements to handling ignored directories
2) Expose extra options to control which ignored files are displayed
by git status.
This patch
Just to reecho a previous change requested before in one of the mail threads,
we currently have
two global variables declared:
struct mru packed_git_mru_storage;
struct mru *packed_git_mru = &packed_git_mru_storage;
We normally use pointers in C to point or refer to the same location or space
i
Running `git fetch --unshallow` on a repo that is not in fact shallow
produces a fatal error message. Add a helper to rev-parse that scripters
can use to determine whether a repo is shallow or not.
Signed-off-by: Øystein Walle
---
Documentation/git-rev-parse.txt | 3 +++
builtin/rev-parse.c
On 09/13, Stefan Beller wrote:
> On Wed, Sep 13, 2017 at 2:54 PM, Brandon Williams wrote:
> > Create protocol.{c,h} and provide functions which future servers and
> > clients can use to determine which protocol to use or is being used.
> >
> > Also introduce the 'GIT_PROTOCOL' environment variable
On 09/13, Stefan Beller wrote:
> On Wed, Sep 13, 2017 at 2:54 PM, Brandon Williams wrote:
> > A normal request to git-daemon is structured as
> > "command path/to/repo\0host=..\0" and due to a bug in an old version of
> > git-daemon 73bb33a94 (daemon: Strictly parse the "extra arg" part of the
> >
On 09/12, Jonathan Nieder wrote:
> From: Stefan Beller
>
> The check_has_commit helper uses resolves a submodule entry to a
> commit, when validating its existence. As a side effect this means
> tolerates a submodule entry pointing to a tag, which is not a valid
> submodule entry that git command
On 09/15, Heiko Voigt wrote:
> We store the changed submodules paths to calculate which submodule needs
> fetching. This does not work for moved submodules since their paths do
> not stay the same in case of a moved submodules. In case of new
> submodules we do not have a path in the current checko
On 09/15, Heiko Voigt wrote:
> To make extending this logic later easier.
>
> Signed-off-by: Heiko Voigt
I like the result of this patch, its much cleaner.
> ---
> submodule.c | 74
> ++---
> 1 file changed, 37 insertions(+), 37 deletion
On 09/17, Ramsay Jones wrote:
>
> Signed-off-by: Ramsay Jones
> ---
>
> Hi Brandon,
>
> If you need to re-roll your 'bw/protocol-v1' branch, could you please
> squash this into the relevant patch (commit 45954f179e, "protocol:
> introduce protocol extention mechanisms", 13-09-2017).
>
> This a
> -Original Message-
> From: Torsten Bögershausen [mailto:tbo...@web.de]
> Sent: Monday, September 18, 2017 11:43 AM
> To: Ben Peart ; Junio C Hamano
> ; Ben Peart
> Cc: david.tur...@twosigma.com; ava...@gmail.com;
> christian.cou...@gmail.com; git@vger.kernel.org;
> johannes.schinde...@gm
When we fail to open $GIT_DIR/info/alternates, we silently
assume there are no alternates. This is the right thing to
do for ENOENT, but not for other errors.
A hard error is probably overkill here. If we fail to read
an alternates file then either we'll complete our operation
anyway, or we'll fai
The link_alt_odb_entries() function has always taken a
ptr/len pair as input. Until cf3c635210 (alternates: accept
double-quoted paths, 2016-12-12), we made a copy of those
bytes in a string. But after that commit, we switched to
parsing the input left-to-right, and we ignore "len"
totally, instead
This series fixes a regression in v2.11.1 where we might read past the
end of an mmap'd buffer. It was introduced in cf3c635210, but I didn't
base the patch on there, for a few reasons:
1. There's a trivial conflict when merging up (because of
git_open_noatime() becoming just git_open() in
On 2017-09-18 15:38, Ben Peart wrote:
>
>
> On 9/17/2017 4:02 AM, Junio C Hamano wrote:
>> Ben Peart writes:
>>
>>> diff --git a/t/helper/test-dump-fsmonitor.c b/t/helper/test-dump-fsmonitor.c
>>> new file mode 100644
>>> index 00..482d749bb9
>>> --- /dev/null
>>> +++ b/t/helper/test-dum
On 9/17/2017 12:47 AM, Junio C Hamano wrote:
Ben Peart writes:
+write_integration_script() {
+ write_script .git/hooks/fsmonitor-test<<-\EOF
+ if [ "$#" -ne 2 ]; then
+ echo "$0: exactly 2 arguments expected"
+ exit 2
+ fi
+ if [ "$1" != 1
Hi Junio,
On Sat, 16 Sep 2017, Junio C Hamano wrote:
> And as you alluded to, we may need to see if we can help making it
> easier to do the latter when needed.
That mistakes it for "Someone Else's Problem".
> Johannes Schindelin writes:
>
> > That's what you are buying into by having these "
Hi Ben,
sorry for not catching this earlier:
On Fri, 15 Sep 2017, Ben Peart wrote:
> [...]
> +
> +int cmd_dropcaches(void)
> +{
> + HANDLE hProcess = GetCurrentProcess();
> + HANDLE hToken;
> + int status;
> +
> + if (!OpenProcessToken(hProcess, TOKEN_QUERY | TOKEN_ADJUST_PRIVILE
Hello, everyone.
Sorry for being late in this thread, I was making sure I didn't say
anything outrageously wrong.
> That's Stefan; I wouldn't have suggested any approach that uses the
> blob whose sole purpose is to serve as a temporary storage area to
> pass the information to the hook as part
On 9/16/2017 11:27 AM, Torsten Bögershausen wrote:
On 2017-09-15 21:20, Ben Peart wrote:
+if [ "$1" != 1 ]
+then
+ echo -e "Unsupported core.fsmonitor hook version.\n" >&2
+ exit 1
+fi
The echo -e not portable
(It was detected by a tighter version of the lint script,
which I ha
On 9/18/2017 9:32 AM, David Turner wrote:
-Original Message-
From: Ben Peart [mailto:peart...@gmail.com]
Sent: Monday, September 18, 2017 9:07 AM
To: David Turner ; 'Ben Peart'
Cc: ava...@gmail.com; christian.cou...@gmail.com; git@vger.kernel.org;
gits...@pobox.com; johannes.schinde...
On 9/17/2017 4:02 AM, Junio C Hamano wrote:
Ben Peart writes:
diff --git a/t/helper/test-dump-fsmonitor.c b/t/helper/test-dump-fsmonitor.c
new file mode 100644
index 00..482d749bb9
--- /dev/null
+++ b/t/helper/test-dump-fsmonitor.c
@@ -0,0 +1,21 @@
+#include "cache.h"
+
+int cmd_main
On Monday 18 September 2017 12:52 AM, Kevin Daudt wrote:
Why is this empty line unwanted? This kind of whitespace can help
separate logical sections, just like paragraphs would.
You're right. I seem to have sent a fix precariously because I haven't
such separation
before (forgetting the fact th
> -Original Message-
> From: Ben Peart [mailto:peart...@gmail.com]
> Sent: Monday, September 18, 2017 9:07 AM
> To: David Turner ; 'Ben Peart'
>
> Cc: ava...@gmail.com; christian.cou...@gmail.com; git@vger.kernel.org;
> gits...@pobox.com; johannes.schinde...@gmx.de; pclo...@gmail.com;
> p.
On 9/17/2017 4:03 AM, Junio C Hamano wrote:
Ben Peart writes:
+[[fsmonitor-watchman]]
+fsmonitor-watchman
+~~~
I've queued a mini squash on top to make sure the line aligns
with the length of the string above it by adding three ~'s here.
Thanks, I'll do the same assumin
On 9/15/2017 3:43 PM, David Turner wrote:
-Original Message-
From: Ben Peart [mailto:benpe...@microsoft.com]
Sent: Friday, September 15, 2017 3:21 PM
To: benpe...@microsoft.com
Cc: David Turner ; ava...@gmail.com;
christian.cou...@gmail.com; git@vger.kernel.org; gits...@pobox.com;
jo
Thanks for taking the time to review/provide feedback!
On 9/15/2017 5:35 PM, David Turner wrote:
-Original Message-
From: Ben Peart [mailto:benpe...@microsoft.com]
Sent: Friday, September 15, 2017 3:21 PM
To: benpe...@microsoft.com
Cc: David Turner ; ava...@gmail.com;
christian.cou...@gm
On 9/17/2017 12:14 PM, Ramsay Jones wrote:
Signed-off-by: Ramsay Jones
---
Hi Ben,
If you need to re-roll your 'bp/fsmonitor' branch, could you please
squash this into the relevant patch (commit c6b5a28941, "fsmonitor:
add a performance test", 15-09-2017).
Absolutely. Thanks!
I'd really
Hi Johannes,
> SHA-256 got much more cryptanalysis than SHA3-256 […].
I do not think this is true. Keccak/SHA-3 actually got (and is still
getting) a lot of cryptanalysis, with papers published at renowned
crypto conferences [1].
Keccak/SHA-3 is recognized to have a significant safety margin. E.
On 9/17/2017 5:51 PM, Junio C Hamano wrote:
Derrick Stolee writes:
+int cmd_main(int ac, const char **av)
+{
+ setup_git_directory();
As far as I recall, we do not (yet) allow declaration after
statement in our codebase. Move this down to make it after all
decls.
Will fix.
+
+
88 matches
Mail list logo
