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.
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
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
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
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
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
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
> > -
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:
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
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?
>
&
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
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
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.
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
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 ++-
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
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 +++
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
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
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 +++--
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
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
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
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
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
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
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
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
-
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 +-
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
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 ++--
:
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
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
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
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
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.
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
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 -
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
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
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
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
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
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
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 ++
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 +
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
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
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
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
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
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 ++-
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
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
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.
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
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:
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
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
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...
>
>
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:
> >
>
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
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
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
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
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
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
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
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
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
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
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
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 +
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
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
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:
-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
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
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.
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
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 ++-
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
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
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,
> +
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
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
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
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&
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
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
Hopefully I didn't break anything, stress testing some stuff
and my own Internet connection is intermittent :<
Æ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
> >> --
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
Æ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
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
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
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,
&
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
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
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 - 100 of 955 matches
Mail list logo