Re: [RFC/WIP] range-diff: show old/new blob OIDs in comments

2019-10-23 Thread Eric Wong
Eric Wong wrote: > Johannes Schindelin wrote: > > I guess your patch won't hurt. > > Cool, will update tests and resend. Turns out the t3206 "trivial reordering" case is way too noisy. I might need to change diff.c to support this case; will update in a few days or week.

Re: [RFC/WIP] range-diff: show old/new blob OIDs in comments

2019-10-22 Thread Eric Wong
Johannes Schindelin wrote: > Hi Eric, > > > On Thu, 17 Oct 2019, Eric Wong wrote: > > > (WIP, mostly stream-of-concious notes + reasoning) > > > > When using "git format-patch --range-diff", the pre and > > post-image blob OIDs are in each

Re: email as a bona fide git transport

2019-10-22 Thread Eric Wong
Vegard Nossum wrote: > I sent v2 of the patches (with metadata _after_ the diff) to the git > list here: > > https://public-inbox.org/git/20191022114518.32055-1-vegard.nos...@oracle.com/T/#u > > As I wrote in there, we could already today start using > >git am --message-id > > when applyin

Re: email as a bona fide git transport

2019-10-17 Thread Eric Wong
ers brought up around exactness and working on top of cherry-picks. > PS: Eric Wong described something that comes quite close to this idea, but > AFAICT without actually recreating commits exactly. I've included the link > for completeness. [4] > [4]: https://lore.kernel.org/work

[RFC/WIP] range-diff: show old/new blob OIDs in comments

2019-10-17 Thread Eric Wong
ld. I'm also still learning my way around git's C internals, but using patch.{old,new}_oid_prefix seems alright... FIXME: tests, t3206 needs updating Not-signed-off-by: Eric Wong --- range-diff.c | 19 +++ 1 file changed, 15 insertions(+), 4 deletions(-) diff --git a/ran

Re: ds/sparse-cone, was Re: What's cooking in git.git (Oct 2019, #03; Fri, 11)

2019-10-15 Thread Eric Wong
Junio C Hamano wrote: > Eric Wong writes: > > > I just took a brief look, but that appears to leak memory. > > > > "hashmap_free(var, 1)" should be replaced with > > "hashmap_free_entries(var, struct foo, member)" > > > > Onl

Re: ds/sparse-cone, was Re: What's cooking in git.git (Oct 2019, #03; Fri, 11)

2019-10-14 Thread Eric Wong
Johannes Schindelin wrote: > On Fri, 11 Oct 2019, Junio C Hamano wrote: > > * ds/sparse-cone (2019-10-08) 17 commits > > - sparse-checkout: cone mode should not interact with .gitignore > > - sparse-checkout: write using lockfile > > - sparse-checkout: update working directory in-process > > -

Re: RFE: use patchwork to submit a patch

2019-10-10 Thread Eric Wong
Jonathan Nieder wrote: > Eric Wong wrote: > > Konstantin Ryabitsev wrote: > > >> This is actually really fast if you already have a local copy of the > >> repository with most objects. Try this yourself if you have > >> torvalds/linux.git locally:

Re: Raise your hand to Ack jk/code-of-conduct if your Ack fell thru cracks

2019-10-09 Thread Eric Wong
Junio C Hamano wrote: > For reference, here is the CoC the patch wants to add (there is no > such topic yet locally, nor a single patch that can be made into > such a topic, so there isn't exactly something people can Ack on > yet. So here is a "preview" of what we would see once such a series

Re: [PATCH v3 21/20] convert: drop invalid comment for subprocess_entry

2019-10-07 Thread Eric Wong
Junio C Hamano wrote: > Eric Wong writes: > > > "struct hashmap_entry" inside "struct subprocess_entry" > > no longer needs to be the first member of any struct, > > so the old comment is no longer true. > > Hmm, is that true? > &

[PATCH v3 21/20] convert: drop invalid comment for subprocess_entry

2019-10-07 Thread Eric Wong
Junio C Hamano wrote: > Eric Wong writes: > > > Comments stating that "struct hashmap_entry" must be the first > > member in a struct are no longer valid. > > After this patch, there is one "/* must be the first member! */" > comment left in conv

[PATCH v3 18/20] OFFSETOF_VAR macro to simplify hashmap iterators

2019-10-06 Thread Eric Wong
on non-portable `__typeof__'. v3: use `__typeof__' to avoid clang warnings Signed-off-by: Eric Wong Reviewed-by: Derrick Stolee --- attr.c | 1 - blame.c | 2 -- builtin/describe.c | 2 +- builtin/difftool.c

[PATCH v3 17/20] hashmap: introduce hashmap_free_entries

2019-10-06 Thread Eric Wong
takes any arguments aside from the hashmap itself. Signed-off-by: Eric Wong Reviewed-by: Derrick Stolee --- blame.c | 2 +- builtin/fetch.c | 6 +++--- config.c| 2 +- diff.c | 6 -- diffcore-rename.c | 2 +- hashmap.

[PATCH v3 20/20] hashmap_entry: remove first member requirement from docs

2019-10-06 Thread Eric Wong
Comments stating that "struct hashmap_entry" must be the first member in a struct are no longer valid. Suggested-by: Phillip Wood Signed-off-by: Eric Wong --- attr.c | 2 +- builtin/fetch.c | 2 +- hashmap.h | 4 ++-- merge-recursive.h | 4

[PATCH v3 19/20] hashmap: remove type arg from hashmap_{get,put,remove}_entry

2019-10-06 Thread Eric Wong
used as: `keyvar->member' Signed-off-by: Eric Wong Reviewed-by: Derrick Stolee --- attr.c | 2 +- blame.c | 10 - builtin/difftool.c | 2 +- builtin/fast-export.c | 2 +- config.c| 3 +-- diff.c | 6 ++-

[PATCH v3 11/20] hashmap_get_next returns "struct hashmap_entry *"

2019-10-06 Thread Eric Wong
This is a step towards removing the requirement for hashmap_entry being the first field of a struct. Signed-off-by: Eric Wong Reviewed-by: Derrick Stolee --- diff.c | 19 --- diffcore-rename.c | 11 +++ hashmap.c | 2 +- hashmap.h

[PATCH v3 12/20] hashmap: use *_entry APIs to wrap container_of

2019-10-06 Thread Eric Wong
an extra parameter to specify the type. Signed-off-by: Eric Wong Reviewed-by: Derrick Stolee --- diff.c | 21 + diffcore-rename.c | 14 +- git-compat-util.h | 15 +++ hashmap.h | 40 +++

[PATCH v3 14/20] hashmap_cmp_fn takes hashmap_entry params

2019-10-06 Thread Eric Wong
Another step in eliminating the requirement of hashmap_entry being the first member of a struct. Signed-off-by: Eric Wong Reviewed-by: Derrick Stolee --- attr.c | 10 ++ builtin/describe.c | 10 ++ builtin/difftool.c | 31

[PATCH v3 16/20] hashmap: hashmap_{put,remove} return hashmap_entry *

2019-10-06 Thread Eric Wong
And add *_entry variants to perform container_of as necessary to simplify most callers. Signed-off-by: Eric Wong Reviewed-by: Derrick Stolee --- hashmap.c | 8 +--- hashmap.h | 15 --- range-diff.c| 4 +++- remote.c| 3

[PATCH v3 06/20] hashmap_add takes "struct hashmap_entry *"

2019-10-06 Thread Eric Wong
This is less error-prone than "void *" as the compiler now detects invalid types being passed. Signed-off-by: Eric Wong Reviewed-by: Derrick Stolee --- attr.c | 2 +- blame.c | 2 +- builtin/describe.c | 2 +- builtin/difftool.c | 6 +++--

[PATCH v3 08/20] hashmap_remove takes "const struct hashmap_entry *"

2019-10-06 Thread Eric Wong
This is less error-prone than "const void *" as the compiler now detects invalid types being passed. Signed-off-by: Eric Wong Reviewed-by: Derrick Stolee --- blame.c| 2 +- hashmap.c | 3 ++- hashmap.h | 2 +- merge-recursive.c | 2 +- name-hash.c

[PATCH v3 15/20] hashmap: use *_entry APIs for iteration

2019-10-06 Thread Eric Wong
Inspired by list_for_each_entry in the Linux kernel. Once again, these are somewhat compromised usability-wise by compilers lacking __typeof__ support. Signed-off-by: Eric Wong Reviewed-by: Derrick Stolee --- attr.c | 5 +++-- blame.c

[PATCH v3 05/20] hashmap_get_next takes "const struct hashmap_entry *"

2019-10-06 Thread Eric Wong
This is less error-prone than "const void *" as the compiler now detects invalid types being passed. Signed-off-by: Eric Wong Reviewed-by: Derrick Stolee --- diff.c | 5 +++-- diffcore-rename.c | 2 +- hashmap.c | 5 +++-- hashmap.h

[PATCH v3 13/20] hashmap_get{,_from_hash} return "struct hashmap_entry *"

2019-10-06 Thread Eric Wong
Update callers to use hashmap_get_entry, hashmap_get_entry_from_hash or container_of as appropriate. This is another step towards eliminating the requirement of hashmap_entry being the first field in a struct. Signed-off-by: Eric Wong Reviewed-by: Derrick Stolee --- attr.c| 2

[PATCH v3 03/20] packfile: use hashmap_entry in delta_base_cache_entry

2019-10-06 Thread Eric Wong
hashmap_entry struct without data corruption. This has the beneficial side effect of reducing the size of a delta_base_cache_entry from 104 bytes to 72 bytes on 64-bit systems. Signed-off-by: Eric Wong Reviewed-by: Derrick Stolee --- packfile.c | 2 +- 1 file changed, 1 insertion(+), 1 delet

[PATCH v3 02/20] coccicheck: detect hashmap_entry.hash assignment

2019-10-06 Thread Eric Wong
Assigning hashmap_entry.hash manually leaves hashmap_entry.next uninitialized, which can be dangerous once the hashmap_entry is inserted into a hashmap. Detect those assignments and use hashmap_entry_init, instead. Signed-off-by: Eric Wong Reviewed-by: Derrick Stolee --- contrib/coccinelle

[PATCH v3 01/20] diff: use hashmap_entry_init on moved_entry.ent

2019-10-06 Thread Eric Wong
Otherwise, the hashmap_entry.next field appears to remain uninitialized, which can lead to problems when add_lines_to_move_detection calls hashmap_add. I found this through manual inspection when converting hashmap_add callers to take "struct hashmap_entry *". Signed-off-by: Eric Wong

[PATCH v3 04/20] hashmap_entry_init takes "struct hashmap_entry *"

2019-10-06 Thread Eric Wong
C compilers do type checking to make life easier for us. So rely on that and update all hashmap_entry_init callers to take "struct hashmap_entry *" to avoid future bugs while improving safety and readability. Signed-off-by: Eric Wong Reviewed-by: Derrick Stolee -

[PATCH v3 07/20] hashmap_get takes "const struct hashmap_entry *"

2019-10-06 Thread Eric Wong
This is less error-prone than "const void *" as the compiler now detects invalid types being passed. Signed-off-by: Eric Wong Reviewed-by: Derrick Stolee --- attr.c| 2 +- blame.c | 6 +++--- builtin/difftool.c| 5 +++-- builtin/fast-export.c | 2 +-

[PATCH v3 10/20] introduce container_of macro

2019-10-06 Thread Eric Wong
g location-dependent. This will complete the transition to compile-time type checking for the hashmap API. This macro already exists in our source as "list_entry" in list.h and making "list_entry" an alias to "container_of" as the Linux kernel has done is a possibility

[PATCH v3 09/20] hashmap_put takes "struct hashmap_entry *"

2019-10-06 Thread Eric Wong
This is less error-prone than "void *" as the compiler now detects invalid types being passed. Signed-off-by: Eric Wong Reviewed-by: Derrick Stolee --- builtin/fast-export.c | 2 +- hashmap.c | 2 +- hashmap.h | 2 +- merge-recursive.c | 4 ++--

[PATCH v3 00/20] hashmap bug/safety/ease-of-use fixes

2019-10-06 Thread Eric Wong
: hashmap_entry: remove first member requirement from docs (2019-10-06 23:05:22 +) Eric Wong (20): diff: use hashmap_entry_init on moved_entry.ent coccicheck: detect hashmap_entry.hash assignment packfile: use

Re: [PATCH v2 18/19] OFFSETOF_VAR macro to simplify hashmap iterators

2019-10-04 Thread Eric Wong
Junio C Hamano wrote: > Eric Wong writes: > > > That seems too tedious. I'm learning towards just initializing > > var = NULL in the start of the for-loop: > > > > @@ -449,7 +449,8 @@ static inline struct hashmap_entry > > *hashmap_iter_first(struct h

Re: [PATCH v2 18/19] OFFSETOF_VAR macro to simplify hashmap iterators

2019-10-03 Thread Eric Wong
Junio C Hamano wrote: > Eric Wong writes: > > > In the future, list iterator macros (e.g. list_for_each_entry) > > may also be implemented using OFFSETOF_VAR to save hackers the > > trouble of using container_of/list_entry macros and without > > relying on non-port

Re: [PATCH v2 10/19] introduce container_of macro

2019-09-30 Thread Eric Wong
Derrick Stolee wrote: > On 9/23/2019 9:03 PM, Eric Wong wrote: > > This macro is popular within the Linux kernel for supporting > > intrusive data structures such as linked lists, red-black trees, > > and chained hash tables while allowing the compiler to do > > type

Re: [PATCH v2 00/19] hashmap bug/safety/ease-of-use fixes

2019-09-30 Thread Eric Wong
Johannes Schindelin wrote: > Hi Eric, > > On Tue, 24 Sep 2019, Eric Wong wrote: > > > Patches 1-11 are largely unchanged from the original series with the > > exception of 2, which is new and posted at: > > > > https://public-inbox.org/git/20190908074953.

Re: [PATCH v2 07/19] hashmap_get takes "const struct hashmap_entry *"

2019-09-30 Thread Eric Wong
Derrick Stolee wrote: > On 9/23/2019 9:03 PM, Eric Wong wrote: > > This is less error-prone than "const void *" as the compiler > > now detects invalid types being passed. > [snip] > > diff --git a/hashmap.h b/hashmap.h > > index 40bcc64289..2a4b4a3

Re: Git in Outreachy December 2019?

2019-09-30 Thread Eric Wong
Johannes Schindelin wrote: > On Tue, 24 Sep 2019, Eric Wong wrote: > > Johannes Schindelin wrote: > > > On Mon, 16 Sep 2019, Emily Shaffer wrote: > > > > - try and make progress towards running many tests from a single test > > > >file in parallel -

Re: Virtual Git Contributor Summit

2019-09-26 Thread Eric Wong
James Ramsay wrote: > On 3 Jul 2019, at 9:01, Johannes Schindelin wrote: > > Team, > > > > I kept talking about this idea of a purely online Git Contributor > > Summit, > > and it is finally time for action. > > Thank you for organizing! > > Yesterday, Christian and I took notes in the doc belo

[PATCH v2 05/19] hashmap_get_next takes "const struct hashmap_entry *"

2019-09-23 Thread Eric Wong
This is less error-prone than "const void *" as the compiler now detects invalid types being passed. Signed-off-by: Eric Wong --- diff.c | 5 +++-- diffcore-rename.c | 2 +- hashmap.c | 5 +++-- hashmap.h | 3 ++- name-hash.c

[PATCH v2 16/19] hashmap: hashmap_{put,remove} return hashmap_entry *

2019-09-23 Thread Eric Wong
And add *_entry variants to perform container_of as necessary to simplify most callers. Signed-off-by: Eric Wong --- hashmap.c | 6 -- hashmap.h | 13 +++-- range-diff.c| 4 +++- remote.c| 3 ++- submodule-config.c | 4

[PATCH v2 09/19] hashmap_put takes "struct hashmap_entry *"

2019-09-23 Thread Eric Wong
This is less error-prone than "void *" as the compiler now detects invalid types being passed. Signed-off-by: Eric Wong --- builtin/fast-export.c | 2 +- hashmap.c | 2 +- hashmap.h | 2 +- merge-recursive.c | 4 ++-- oidmap.c| 2

[PATCH v2 06/19] hashmap_add takes "struct hashmap_entry *"

2019-09-23 Thread Eric Wong
This is less error-prone than "void *" as the compiler now detects invalid types being passed. Signed-off-by: Eric Wong --- attr.c | 2 +- blame.c | 2 +- builtin/describe.c | 2 +- builtin/difftool.c | 6 +++--- builtin/fetch.c

[PATCH v2 07/19] hashmap_get takes "const struct hashmap_entry *"

2019-09-23 Thread Eric Wong
This is less error-prone than "const void *" as the compiler now detects invalid types being passed. Signed-off-by: Eric Wong --- attr.c| 2 +- blame.c | 6 +++--- builtin/difftool.c| 5 +++-- builtin/fast-export.c | 2 +- config.c | 2

[PATCH v2 17/19] hashmap: introduce hashmap_free_entries

2019-09-23 Thread Eric Wong
takes any arguments aside from the hashmap itself. Signed-off-by: Eric Wong --- blame.c | 2 +- builtin/fetch.c | 6 +++--- config.c| 2 +- diff.c | 6 -- diffcore-rename.c | 2 +- hashmap.c | 11 ++

[PATCH v2 10/19] introduce container_of macro

2019-09-23 Thread Eric Wong
ent and to allow more compile-time type checking. This macro already exists in our source as "list_entry" in list.h and making "list_entry" an alias to "container_of" as the Linux kernel has done is a possibility. Signed-off-by: Eric Wong --- git-compat-util.h | 10 +

[PATCH v2 18/19] OFFSETOF_VAR macro to simplify hashmap iterators

2019-09-23 Thread Eric Wong
ify a type when a pointer of that type is already given. In the future, list iterator macros (e.g. list_for_each_entry) may also be implemented using OFFSETOF_VAR to save hackers the trouble of using container_of/list_entry macros and without relying on non-portable `__typeof__'. Signed-of

[PATCH v2 08/19] hashmap_remove takes "const struct hashmap_entry *"

2019-09-23 Thread Eric Wong
This is less error-prone than "const void *" as the compiler now detects invalid types being passed. Signed-off-by: Eric Wong --- blame.c| 2 +- hashmap.c | 3 ++- hashmap.h | 2 +- merge-recursive.c | 2 +- name-hash.c| 4 ++-- packfile.c

[PATCH v2 11/19] hashmap_get_next returns "struct hashmap_entry *"

2019-09-23 Thread Eric Wong
This is a step towards removing the requirement for hashmap_entry being the first field of a struct. Signed-off-by: Eric Wong --- diff.c | 19 --- diffcore-rename.c | 11 +++ hashmap.c | 2 +- hashmap.h | 12

[PATCH v2 13/19] hashmap_get{,_from_hash} return "struct hashmap_entry *"

2019-09-23 Thread Eric Wong
Update callers to use hashmap_get_entry, hashmap_get_entry_from_hash or container_of as appropriate. This is another step towards eliminating the requirement of hashmap_entry being the first field in a struct. Signed-off-by: Eric Wong --- attr.c| 2 +- blame.c

[PATCH v2 19/19] hashmap: remove type arg from hashmap_{get,put,remove}_entry

2019-09-23 Thread Eric Wong
used as: `keyvar->member' Signed-off-by: Eric Wong --- attr.c | 2 +- blame.c | 10 - builtin/difftool.c | 2 +- builtin/fast-export.c | 2 +- config.c| 3 +-- diff.c | 6 ++ hashmap.c

[PATCH v2 04/19] hashmap_entry_init takes "struct hashmap_entry *"

2019-09-23 Thread Eric Wong
C compilers do type checking to make life easier for us. So rely on that and update all hashmap_entry_init callers to take "struct hashmap_entry *" to avoid future bugs while improving safety and readability. Signed-off-by: Eric Wong --- attr.c | 4 ++-

[PATCH v2 15/19] hashmap: use *_entry APIs for iteration

2019-09-23 Thread Eric Wong
Inspired by list_for_each_entry in the Linux kernel. Once again, these are somewhat compromised usability-wise by compilers lacking __typeof__ support. Signed-off-by: Eric Wong --- attr.c | 5 +++-- blame.c | 10 ++ builtin

[PATCH v2 14/19] hashmap_cmp_fn takes hashmap_entry params

2019-09-23 Thread Eric Wong
Another step in eliminating the requirement of hashmap_entry being the first member of a struct. Signed-off-by: Eric Wong --- attr.c | 10 ++ builtin/describe.c | 10 ++ builtin/difftool.c | 31 +++ builtin/fast-export.c

[PATCH v2 03/19] packfile: use hashmap_entry in delta_base_cache_entry

2019-09-23 Thread Eric Wong
hashmap_entry struct without data corruption. This has the beneficial side effect of reducing the size of a delta_base_cache_entry from 104 bytes to 72 bytes on 64-bit systems. Signed-off-by: Eric Wong --- packfile.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/packfile.

[PATCH v2 12/19] hashmap: use *_entry APIs to wrap container_of

2019-09-23 Thread Eric Wong
an extra parameter to specify the type. Signed-off-by: Eric Wong --- diff.c | 21 + diffcore-rename.c | 14 +- git-compat-util.h | 16 hashmap.h | 40 ++-- name-hash.c

[PATCH v2 01/19] diff: use hashmap_entry_init on moved_entry.ent

2019-09-23 Thread Eric Wong
Otherwise, the hashmap_entry.next field appears to remain uninitialized, which can lead to problems when add_lines_to_move_detection calls hashmap_add. I found this through manual inspection when converting hashmap_add callers to take "struct hashmap_entry *". Signed-off-by:

[PATCH v2 02/19] coccicheck: detect hashmap_entry.hash assignment

2019-09-23 Thread Eric Wong
Assigning hashmap_entry.hash manually leaves hashmap_entry.next uninitialized, which can be dangerous once the hashmap_entry is inserted into a hashmap. Detect those assignments and use hashmap_entry_init, instead. Signed-off-by: Eric Wong --- contrib/coccinelle/hashmap.cocci | 16

[PATCH v2 00/19] hashmap bug/safety/ease-of-use fixes

2019-09-23 Thread Eric Wong
hashmap: remove type arg from hashmap_{get,put,remove}_entry (2019-09-24 00:42:22 +) Eric Wong (19): diff: use hashmap_entry_init on moved_entry.ent coccicheck: detect hashmap_entry.hash assignment pac

Re: Git in Outreachy December 2019?

2019-09-23 Thread Eric Wong
Johannes Schindelin wrote: > On Mon, 16 Sep 2019, Emily Shaffer wrote: > > - try and make progress towards running many tests from a single test > >file in parallel - maybe this is too big, I'm not sure if we know how > >many of our tests are order-dependent within a file for now... > >

Re: git-svn authors file in repo (Author: xxx not defined in .gitauthors file)

2019-09-19 Thread Eric Wong
SZEDER Gábor wrote: > On Thu, Sep 19, 2019 at 11:34:21AM -0300, Joseph Mingrone wrote: > > Hello, > > > > We maintain a .gitauthors file for git-svn. When a new committer is > > added to our project, a new entry is added to the .gitauthors file, > > but we sometimes see errors like this: > > >

git-svn future goals...

2019-09-16 Thread Eric Wong
It looks like git-svn has mostly killed SVN(*), but commands like "git svn find-rev" and maybe "git svn log" will continue to be useful for projects that already migrated to git. So I'm hoping to find time at some point in the future to port some non-libsvn-dependent parts over to C, and maybe imp

Re: Git in Outreachy December 2019?

2019-09-16 Thread Eric Wong
Emily Shaffer wrote: > Jonathan Tan, Jonathan Nieder, Josh Steadmon and I met on Friday to talk > about projects and we came up with a trimmed list; not sure what more > needs to be done to make them into fully-fledged proposals. > For the longer projects, we came up with a few more: > - ad

[RFC 04/11] coccicheck: detect hashmap_entry.hash assignment

2019-09-08 Thread Eric Wong
Eric Wong wrote: > By renaming the "hash" field to "_hash", it's easy to spot > improper initialization of hashmap_entry structs which > can leave "hashmap_entry.next" uninitialized. Junio, I'm planning to reroll this series. (Sorry for not fo

Re: [PATCH 04/11] hashmap_entry: detect improper initialization

2019-08-30 Thread Eric Wong
Phillip Wood wrote: > Hi Eric > > On 27/08/2019 10:49, Eric Wong wrote: > > Johannes Schindelin wrote: > > > Hi Eric, > > > > > > On Mon, 26 Aug 2019, Eric Wong wrote: > > > > > > > By renaming the "hash" field to &q

Re: [PATCH 03/11] hashmap_entry_init takes "struct hashmap_entry *"

2019-08-30 Thread Eric Wong
Johannes Schindelin wrote: > Hi Stolee, > > On Tue, 27 Aug 2019, Derrick Stolee wrote: > > > On 8/25/2019 10:43 PM, Eric Wong wrote: > > > C compilers do type checking to make life easier for us. So > > > rely on that and update all hashmap_entr

Re: [PATCH 10/11] introduce container_of macro

2019-08-30 Thread Eric Wong
Derrick Stolee wrote: > On 8/25/2019 10:43 PM, Eric Wong wrote: > > + * container_of - Get the address of an object containing a field. > > + * > > + * @ptr: pointer to the field. > > + * @type: type of the object. > > + * @member: name of the field within

Re: [PATCH 11/11] hashmap_get_next returns "struct hashmap_entry *"

2019-08-30 Thread Eric Wong
Derrick Stolee wrote: > On 8/25/2019 10:43 PM, Eric Wong wrote: > > --- a/diff.c > > +++ b/diff.c > > @@ -1035,8 +1035,10 @@ static void pmb_advance_or_null_multi_match(struct > > diff_options *o, > > { > > int i; > > char *got_match = xca

Re: [PATCH 04/11] hashmap_entry: detect improper initialization

2019-08-27 Thread Eric Wong
Johannes Schindelin wrote: > Hi Eric, > > On Mon, 26 Aug 2019, Eric Wong wrote: > > > By renaming the "hash" field to "_hash", it's easy to spot > > improper initialization of hashmap_entry structs which > > can leave "hashmap_entr

Re: [RFC PATCH 0/5] Remove git-filter-branch from git.git; host it elsewhere

2019-08-27 Thread Eric Wong
Elijah Newren wrote: > Some highlevel notes on the patches: > > * Patches 1&2: are good cleanups & performance wins regardless of > whether the rest of the series is taken Agreed. Though weren't we moving away from pipes in tests because failures could go unnoticed? (I haven't been payin

[PATCH 06/11] hashmap_add takes "struct hashmap_entry *"

2019-08-25 Thread Eric Wong
This is less error-prone than "void *" as the compiler now detects invalid types being passed. Signed-off-by: Eric Wong --- attr.c | 2 +- blame.c | 2 +- builtin/describe.c | 2 +- builtin/difftool.c | 6 +++--- builtin/fetch.c

[PATCH 11/11] hashmap_get_next returns "struct hashmap_entry *"

2019-08-25 Thread Eric Wong
This is a step towards removing the requirement for hashmap_entry being the first field of a struct. Signed-off-by: Eric Wong --- diff.c | 19 --- diffcore-rename.c | 11 +++ hashmap.c | 2 +- hashmap.h | 12

[PATCH 10/11] introduce container_of macro

2019-08-25 Thread Eric Wong
ent and to allow more compile-time type checking. This macro already exists in our source as "list_entry" in list.h and making "list_entry" an alias to "container_of" as the Linux kernel has done is a possibility. Signed-off-by: Eric Wong --- git-compat-util.h | 10 +

[PATCH 09/11] hashmap_put takes "struct hashmap_entry *"

2019-08-25 Thread Eric Wong
This is less error-prone than "void *" as the compiler now detects invalid types being passed. Signed-off-by: Eric Wong --- builtin/fast-export.c | 2 +- hashmap.c | 2 +- hashmap.h | 2 +- merge-recursive.c | 4 ++-- oidmap.c| 2

[PATCH 07/11] hashmap_get takes "const struct hashmap_entry *"

2019-08-25 Thread Eric Wong
This is less error-prone than "const void *" as the compiler now detects invalid types being passed. Signed-off-by: Eric Wong --- attr.c| 2 +- blame.c | 6 +++--- builtin/difftool.c| 5 +++-- builtin/fast-export.c | 2 +- config.c | 2

[PATCH 01/11] diff: use hashmap_entry_init on moved_entry.ent

2019-08-25 Thread Eric Wong
Otherwise, the hashmap_entry.next field appears to remain uninitialized, which can lead to problems when add_lines_to_move_detection calls hashmap_add. I found this through manual inspection when converting hashmap_add callers to take "struct hashmap_entry *". Signed-off-by:

[PATCH 00/11] hashmap: bugfixes, safety fixes, and WIP improvements

2019-08-25 Thread Eric Wong
-svn.git hashmap-wip-v1 for you to fetch changes up to 4d9857917670218cba447caddec15a2734c86e2c: hashmap_get_next returns "struct hashmap_entry *" (2019-08-26 02:25:35 +) Eric Wong (11): diff: use

[PATCH 08/11] hashmap_remove takes "const struct hashmap_entry *"

2019-08-25 Thread Eric Wong
This is less error-prone than "const void *" as the compiler now detects invalid types being passed. Signed-off-by: Eric Wong --- blame.c| 2 +- hashmap.c | 3 ++- hashmap.h | 2 +- merge-recursive.c | 2 +- name-hash.c| 4 ++-- packfile.c

[PATCH 02/11] packfile: use hashmap_entry in delta_base_cache_entry

2019-08-25 Thread Eric Wong
hashmap_entry struct without data corruption. This has the beneficial side effect of reducing the size of a delta_base_cache_entry from 104 bytes to 72 bytes on 64-bit systems. Signed-off-by: Eric Wong --- packfile.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/packfile.

[PATCH 04/11] hashmap_entry: detect improper initialization

2019-08-25 Thread Eric Wong
By renaming the "hash" field to "_hash", it's easy to spot improper initialization of hashmap_entry structs which can leave "hashmap_entry.next" uninitialized. Signed-off-by: Eric Wong --- builtin/fast-export.c | 5 +++-- hash

[PATCH 03/11] hashmap_entry_init takes "struct hashmap_entry *"

2019-08-25 Thread Eric Wong
C compilers do type checking to make life easier for us. So rely on that and update all hashmap_entry_init callers to take "struct hashmap_entry *" to avoid future bugs while improving safety and readability. Signed-off-by: Eric Wong --- attr.c | 4 ++-

[PATCH 05/11] hashmap_get_next takes "const struct hashmap_entry *"

2019-08-25 Thread Eric Wong
This is less error-prone than "const void *" as the compiler now detects invalid types being passed. Signed-off-by: Eric Wong --- diff.c | 5 +++-- diffcore-rename.c | 2 +- hashmap.c | 5 +++-- hashmap.h | 3 ++- name-hash.c

Re: RFC: Proposing git-filter-repo for inclusion in git.git

2019-08-22 Thread Eric Wong
Elijah Newren wrote: > * Remove git-filter-branch from git.git. Mention in the release > notes where people can go to get it.[1] > > filter-branch is not merely a slow or difficult-to-use tool, it's one > that *fosters* mistakes by making it hard to get things right in > several different ways

Re: [PATCH v2 2/5] fetch: Add the "--fetch-jobs" option

2019-08-13 Thread Eric Wong
Palmer Dabbelt wrote: > diff --git a/builtin/fetch.c b/builtin/fetch.c > index 8aa6a0caf1ab..fa12ad44e7d9 100644 > --- a/builtin/fetch.c > +++ b/builtin/fetch.c > +static int next_remote_to_fetch(struct child_process *cp, > + struct strbuf *out, > +

Re: Surprising use of memory and time when repacking mozilla's gecko repository

2019-07-04 Thread Eric Wong
Mike Hommey wrote: > I'm puzzled by the fact writing objects is so much faster with 1 thread. I/O contention in the multi-threaded cases? "public-inbox-index" (reading from git, writing to Xapian+SQLite) on a dev machine got slow because core count exceeded what SATA could handle and had to cap

[PATCH 2/1] repack: warn if bitmaps are explicitly enabled with keep files

2019-06-29 Thread Eric Wong
r explicitly enables bitmaps, we should warn if .keep files exist or are specified via --keep-pack Signed-off-by: Eric Wong --- builtin/repack.c | 8 t/t7700-repack.sh | 16 2 files changed, 24 insertions(+) diff --git a/builtin/repack.c b/builtin/repack.c index 73250b2

[PATCH v2] repack: disable bitmaps-by-default if .keep files exist

2019-06-29 Thread Eric Wong
SZEDER Gábor wrote: > On Fri, Jun 28, 2019 at 07:02:11AM +, Eric Wong wrote: > > diff --git a/t/t7700-repack.sh b/t/t7700-repack.sh > > index 86d05160a3..0acde3b1f8 100755 > > --- a/t/t7700-repack.sh > > +++ b/t/t7700-repack.sh > > @@ -239,4 +239,14 @@ te

[PATCH] repack: disable bitmaps-by-default if .keep files exist

2019-06-28 Thread Eric Wong
Jeff King wrote: > On Sun, Jun 23, 2019 at 06:08:25PM +, Eric Wong wrote: > > > > I'm not sure of the right solution. For maximal backwards-compatibility, > > > the default for bitmaps could become "if not bare and if there are no > > > .keep files&

TLS on news.public-inbox.org [was: may be unstable]

2019-06-24 Thread Eric Wong
Eric Wong wrote: > Hopefully I didn't break anything, stress testing some stuff > and my own Internet connection is intermittent :< STARTTLS is now available on port 119, and NNTPS on 563. I think it works... :x No idea if it's actually secure or not; but it might help get

Re: 2.22.0 repack -a duplicating pack contents

2019-06-23 Thread Eric Wong
Jeff King wrote: > On Sun, Jun 23, 2019 at 04:54:50PM +0200, Ævar Arnfjörð Bjarmason wrote: > > > I haven't looked at this for more than a couple of minutes (and don't > > have more time now), but this is almost certainly due to 36eba0323d > > ("repack: enable bitmaps by default on bare repos", 2

nntp://news.public-inbox.org/ may be unstable

2019-06-21 Thread Eric Wong
Hopefully I didn't break anything, stress testing some stuff and my own Internet connection is intermittent :<

Re: [PATCH] send-email: remove documented requirement for Net::SMTP::SSL

2019-05-27 Thread Eric Wong
Ævar Arnfjörð Bjarmason wrote: > On Tue, May 28 2019, Eric Wong wrote: > > Todd Zullinger wrote: > >> Something like: > >> > >> diff --git i/git-send-email.perl w/git-send-email.perl > >> index 24859a7bc3..84ac03994d 100755 > >> --

Re: [PATCH] send-email: remove documented requirement for Net::SMTP::SSL

2019-05-27 Thread Eric Wong
Todd Zullinger wrote: > I wonder if it's (separately from this change) worth > adjusting the conditional which sets $use_net_smtp_ssl to > use "Net::SMTP->can('starttls')" rather than a strict > version check? (It might not be if using 'can' is too > fragile or would only benefit the Red Hat 7 pa

Re: [PATCH] send-email: remove documented requirement for Net::SMTP::SSL

2019-05-27 Thread Eric Wong
Ævar Arnfjörð Bjarmason wrote: > On Mon, May 27 2019, Eric Wong wrote: > > Chris Mayo wrote: > >> git-send-email uses the TLS support in the Net::SMTP core module from > >> recent versions of Perl. Documenting the minimum version is complex > >> because of sep

Re: [PATCH] send-email: remove documented requirement for Net::SMTP::SSL

2019-05-27 Thread Eric Wong
Chris Mayo wrote: > git-send-email uses the TLS support in the Net::SMTP core module from > recent versions of Perl. Documenting the minimum version is complex > because of separate numbering for Perl (5.21.5~169), Net:SMTP (2.34) > and libnet (3.01). Version numbers from commit: > bfbfc9a953 ("se

[PATCH v2] server-info: do not list unlinked packs

2019-05-23 Thread Eric Wong
Jeff King wrote: > On Thu, May 23, 2019 at 08:59:59AM +, Eric Wong wrote: > > > > We never delete entries from the in-memory packed_git list; a reprepare > > > only adds to the list. You'd need to teach update_server_info() to > > > ignore packs which ar

[PATCH] server-info: do not list unlinked packs

2019-05-23 Thread Eric Wong
Jeff King wrote: > On Wed, May 15, 2019 at 08:38:39PM +, Eric Wong wrote: > > > I've also noticed objects/info/packs contains stale entries > > after repack/gc runs on current git. > > > > Tried adding reprepare_packed_git before update_server_info, &

[WIP] repack leaving stale entries in objects/info/packs

2019-05-15 Thread Eric Wong
I've also noticed objects/info/packs contains stale entries after repack/gc runs on current git. Tried adding reprepare_packed_git before update_server_info, but that didn't seem to work; so maybe something isn't cleared. Might have time to investigate more this week, might not... diff --git a/bu

[PATCH 2/1] server-info: conditionally update on fetch

2019-05-14 Thread Eric Wong
the new `updated_refs' counter to update server info files iff info/refs already exists. Note: this depends on Ævar's WIP in: https://public-inbox.org/git/87ftphw7mv@evledraar.gmail.com/ Signed-off-by: Eric Wong --- builtin/fetch.c| 3 +++ server-info.c

Re: [PATCH] get_oid: handle NULL repo->index

2019-05-14 Thread Eric Wong
Jeff King wrote: > +++ b/sha1-name.c > @@ -1837,7 +1837,7 @@ static enum get_oid_result > get_oid_with_context_1(struct repository *repo, > if (flags & GET_OID_RECORD_PATH) > oc->path = xstrdup(cp); > > - if (!repo->index->cache) > + i

  1   2   3   4   5   6   7   8   9   10   >