This is a follow-up to the discussion in:
https://public-inbox.org/git/20180822030344.ga14...@sigill.intra.peff.net/
The general idea is that the majority of callers don't care about actual
plus/minus ordering from oidcmp() and hashcmp(); they just want to know
if two oids are equal. The strict
Sometimes we want to suppress a coccinelle transformation
inside a particular function. For example, in finding
conversions of hashcmp() to oidcmp(), we should not convert
the call in oidcmp() itself, since that would cause infinite
recursion. We write that like this:
@@
identifier f != oidcmp
The main comparison functions we provide for comparing
object ids are hashcmp() and oidcmp(). These are more
flexible than a strict equality check, since they also
express ordering. That makes them them useful for sorting
and binary searching. However, it also makes them
potentially slower than a s
Using the more restrictive oideq() should, in the long run,
give the compiler more opportunities to optimize these
callsites. For now, this conversion should be a complete
noop with respect to the generated code.
The result is also perhaps a little more readable, as it
avoids the "zero is equal" i
This is the partner patch to the previous one, but covering
the "hash" variants instead of "oid". Note that our
coccinelle rule is slightly more complex to avoid triggering
the call in hasheq().
I didn't bother to add a new rule to convert:
- hasheq(E1->hash, E2->hash)
+ oideq(E1, E2)
Since
This is the flip side of the previous two patches: checking
for a non-zero oidcmp() can be more strictly expressed as
inequality. Like those patches, we write "!= 0" in the
coccinelle transformation, which covers by isomorphism the
more common:
if (oidcmp(E1, E2))
As with the previous two patch
This rounds out the previous three patches, covering the
inequality logic for the "hash" variant of the functions.
As with the previous three, the accompanying code changes
are the mechanical result of applying the coccinelle patch;
see those patches for more discussion.
Signed-off-by: Jeff King
The comparison functions used for hashmaps don't care about
strict ordering; they only want to compare entries for
equality. Let's use the oideq() function instead, which can
potentially be better optimized. Note that unlike the
previous patches mass-converting calls like "!oidcmp()",
this patch co
These functions return the full oidcmp() value, but the
callers really only care whether it is non-zero. We can use
the more strict !oideq(), which a compiler may be able to
optimize further.
This does change the meaning of the return value subtly, but
it's unlikely that anybody would try to use t
We two nested conditionals to store a content_changed
variable, but only bother to look at the result once,
directly after we set it. We can drop the variable entirely
and just use a single "if".
This needless complexity is the result of 2ff3a80334 (Teach
--dirstat not to completely ignore rearran
On Sat, Aug 25, 2018 at 4:17 AM Jeff King wrote:
> We two nested conditionals to store a content_changed
grammo...
> variable, but only bother to look at the result once,
> directly after we set it. We can drop the variable entirely
> and just use a single "if".
>
> This needless complexity is t
On Sat, Aug 25, 2018 at 04:20:33AM -0400, Eric Sunshine wrote:
> On Sat, Aug 25, 2018 at 4:17 AM Jeff King wrote:
> > We two nested conditionals to store a content_changed
>
> grammo...
Heh. Edited in my MUA while proof-reading, of course. ;)
It should be "We use two...".
-Peff
On Fri, Aug 24, 2018 at 12:45:10PM -0400, Derrick Stolee wrote:
> Here are the numbers for Linux:
>
> | | v2.18.0 | v2.19.0-rc0 | HEAD |
> |--|--|-||
> | | 86.5 | 70.739 | 57.266 |
> | | 60.582 | 101.928 | 56.641 |
> | | 58.964
On Sat, Aug 25, 2018 at 04:07:15AM -0400, Jeff King wrote:
> diff --git a/contrib/coccinelle/object_id.cocci
> b/contrib/coccinelle/object_id.cocci
> index 5869979be7..548c02336d 100644
> --- a/contrib/coccinelle/object_id.cocci
> +++ b/contrib/coccinelle/object_id.cocci
> @@ -108,3 +108,9 @@ exp
On 25/08/18 10:05, Jeff King wrote:
> The main comparison functions we provide for comparing
> object ids are hashcmp() and oidcmp(). These are more
> flexible than a strict equality check, since they also
> express ordering. That makes them them useful for sorting
s/them them/them/
> We can solv
Fix an incorrect comment in the new code added in b4da37380b
(unpack-trees: optimize walking same trees with cache-tree -
2018-08-18) and document about the new test variable that is enabled
by default in test-lib.sh in 4592e6080f (cache-tree: verify valid
cache-tree in the test suite - 2018-08-18)
On Sat, 25 Aug 2018 at 14:22, Nguyễn Thái Ngọc Duy wrote:
> * Fast path if we detect that all trees are the same as cache-tree at this
> - * path. We'll walk these trees recursively using cache-tree/index instead of
> - * ODB since already know what these trees contain.
> + * path. We'll walk th
Fix an incorrect comment in the new code added in b4da37380b
(unpack-trees: optimize walking same trees with cache-tree -
2018-08-18) and document about the new test variable that is enabled
by default in test-lib.sh in 4592e6080f (cache-tree: verify valid
cache-tree in the test suite - 2018-08-18)
I think there are two aspects to using "force with lease".
Firstly, you, a person aware of the option, using it. In this case I
think an alias is very fitting, because you get quickly used to just
typing `git pf` or so. Plus, you don't have the disadvantage you
described: if you’re working on a ma
I'm Ruth, i am 26yrs old, i'm a free minded,open hearted girl,i'm one of the
few that still believes in friendship, love, trust and signs, I'm very much
single and ready to mingle,i will like to be your friend if you don't mind, i
hope you will not take my request for granted,feel free to email
Am 11.08.2018 um 22:48 schrieb Ramsay Jones:
> On 11/08/18 16:47, René Scharfe wrote:
>> @@ -34,12 +36,12 @@ struct fsck_options {
>> fsck_error error_func;
>> unsigned strict:1;
>> int *msg_type;
>> - struct oid_array *skiplist;
>> + struct oidset skiplist;
>> struct deco
Am 11.08.2018 um 18:54 schrieb Ævar Arnfjörð Bjarmason:
>
> On Sat, Aug 11 2018, René Scharfe wrote:
>
>> Object IDs to skip are stored in a shared static oid_array. Lookups do
>> a binary search on the sorted array. The code checks if the object IDs
>> are already in the correct order while lo
Object IDs to skip are stored in a shared static oid_array. Lookups do
a binary search on the sorted array. The code checks if the object IDs
are already in the correct order while loading and skips sorting in that
case. Lookups are done before reporting a (non-fatal) corruption and
before check
buffer is unlikely to contain a NUL character, so printing its contents
using %s in a die() format is unsafe (detected with ASan).
Use an idiomatic strbuf_getline() loop instead, which ensures the buffer
is always NUL-terminated, supports CRLF files as well, accepts files
without a newline after t
I wish to seek for your assistance in a deal that will be of mutual benefit for
the both of us from Camp Stanley, Stationed in Uijeongbu, South Korea.
Please get back to me for more info.
Thank you for your time.
Sgt.Joan Martinez
Add best-effort support for patches sent using format=flowed (RFC 3676).
Remove leading spaces ("unstuff"), remove soft line breaks (indicated
by space + newline), but leave the signature separator (dash dash space
newline) alone.
Warn in git am when encountering a format=flowed patch, because any
Hi Jonathan,
On Wed, 22 Aug 2018, Jonathan Nieder wrote:
> Johannes Schindelin wrote:
>
> [nice description snipped]
> > This patch fixes that.
>
> Please include this information in the commit message. It's super
> helpful to find this kind of information about why a patch does what
> it does
Hi Bryan,
On Fri, 24 Aug 2018, Bryan Turner wrote:
> On Fri, Aug 24, 2018 at 5:14 AM Johannes Schindelin
> wrote:
> >
> > For that reason, I was delighted to see that our Google Summer of Code
> > pushed pretty hard in that direction. And I could not help myself so I had
> > to test how much fas
On Wed, Aug 22, 2018 at 04:16:00PM -0700, Gregory Oschwald wrote:
> As of the release of 2.18.0, $GIT_DIR is no longer set before calling
> pre-commit hooks. This change was introduced in "set_work_tree: use
> chdir_notify" (8500e0de) and is still present in master.
>
> I reviewed the discussion
Hi git community!
I found what seems to be a vulnerability/bug on git. I'm running
version 2.7.4 on Ubuntu xenial, but also tested with last version
2.19.0.rc0.2.g29d9e3e.
The steps to reproduce are:
1. open your .git/conf
2. add something like:
[core]
editor = ls /etc/passwd
or even
edi
On Sat, Aug 25, 2018 at 11:13:30PM -0300, Leo Silva (a.k.a kirotawa) wrote:
> Hi git community!
>
> I found what seems to be a vulnerability/bug on git. I'm running
> version 2.7.4 on Ubuntu xenial, but also tested with last version
> 2.19.0.rc0.2.g29d9e3e.
>
> The steps to reproduce are:
>
> 1
ah, cool!
So, when a git clone is executed it generates a new .git/config to the
local one (I didn't pay attention on that).
Thanks a lot for the clarification Peff!
On Sun, Aug 26, 2018 at 12:19 AM Jeff King wrote:
>
> On Sat, Aug 25, 2018 at 11:13:30PM -0300, Leo Silva (a.k.a kirotawa) wrote
Hello amc2399,
We wanted to let you know that your GitHub password was reset.
If you did not perform this action, you can recover access by entering
git@vger.kernel.org into the form at https://github.com/password_reset
To see this and other security events for your account, visit
https://gith
We heard that you lost your GitHub password. Sorry about that!
But don’t worry! You can use the following link to reset your password:
https://github.com/password_reset/0289e07960cb65215eefb2f61c23506a55bbfa82268ca3c092ce5b82779283a5656d61696cb367697440766765722e6b65726e656c2e6f7267a5666f726365c2
34 matches
Mail list logo
