Martin Langhoff wrote:
> Hi folks,
>
> Long time no see! Importing a 3GB (~25K revs, tons of files) SVN repo
> I hit the gc error:
>
> warning: There are too many unreachable loose objects; run 'git prune'
> to remove them.
> gc --auto: command returned error: 255
GC can be annoying when that h
Jeff King wrote:
> Pruning generally has to traverse the whole commit graph in order to
> see which objects are reachable. This is the exact problem that
> reachability bitmaps were meant to solve, so let's use them (if they're
> available, of course).
Perhaps this is good impetus for doing bitma
Jeff King wrote:
> On Sat, Mar 09, 2019 at 02:49:44AM +, Eric Wong wrote:
> > It would make life easier for people new to hosting git servers
> > (and hopefully reduce centralization :)
>
> I do think they're a net win for people hosting git servers. But if
> tha
/
> On Tue, Mar 12, 2019 at 03:13:03AM +, Eric Wong wrote:
> > @@ -343,11 +343,15 @@ int cmd_repack(int argc, const char **argv, const
> > char *prefix)
> > (unpack_unreachable || (pack_everything & LOOSEN_UNREACHABLE)))
> > die(_("--keep-
Jeff King wrote:
> On Wed, Mar 13, 2019 at 01:51:33AM +, Eric Wong wrote:
>
> > But I did find Ævar's forgotten gitperformance doc and thread
> > where the topic was brought up:
> >
> > https://public-inbox.org/git/20170403211644.26814-1-ava...@gm
George Spelvin wrote nothing...
Did you mis-send or did vger eat your message?
Doesn't seem to be a problem with public-inbox.org,
same for gmane and marc.info:
nntp://news.gmane.org/201903190646.x2j6krwe017...@sdf.org
https://marc.info/?i=201903190646.x2j6krwe017...@sdf.org
mail-archive.com d
Jeff King wrote:
> On Fri, Mar 22, 2019 at 09:21:14AM +0100, Wolfgang Denk wrote:
>
> > Dear Jeff,
> >
> > In message <20190322071231.ga26...@sigill.intra.peff.net> you wrote:
> > >
> > > However, so does the parent of 17966c0a63d. So I don't know if the
> > > u-boot-efi repo is just broken, or
Heinrich Schuchardt wrote:
> On 3/22/19 5:50 PM, Eric Wong wrote:
> > I couldn't reproduce an error after porting your patch to
> > master (commit 041f5ea1cf987a40 "The third batch"):
> > https://80x24.org/spew/20190322163449.25362-...@80x24.org/raw
> >
Heinrich Schuchardt wrote:
> Yes, git HEAD + said patch works with this command:
> git -c http.followRedirects=true clone http://git.denx.de/u-boot-efi.git
>
> http.followRedirects is documented in man 1 git-config.
>
> Why would git prior to 17966c0a63d25b1cc2dd1e98d30873e643bd581f~1 work
> wi
Junio C Hamano wrote:
> Well, having said all that, I do not think I personally mind if
> ./configure learned to include a "compile small program and run it
> to determine byte order on the build machine" as part of "we make a
> reasonable effort" as long as it cleanly excludes cross building
> ca
Ævar Arnfjörð Bjarmason wrote:
> Add a --send-delay option with a corresponding sendemail.smtpSendDelay
> configuration variable. When set to e.g. 2, this causes send-email to
> sleep 2 seconds before sending the next E-Mail. We'll only sleep
> between sends, not before the first send, or after th
Jeff King wrote:
> On Tue, Aug 14, 2018 at 12:47:59PM -0700, Stefan Beller wrote:
> > With the advent of public inbox, this is easy to obtain?
>
> For our project, yes. But I was thinking of a tool that could be used
> for other projects, too.
Nothing prevents public-inbox from being adopted by
You're very welcome, Johannes. And I'm hoping to have a few
more goodies live this fall/winter for public-inbox :>
Jeff King wrote:
> I've thought about mirroring it to a public server as well, just for
> redundancy. But without the same domain, I'm not sure it would be all
> that useful as a community resource.
I wouldn't get too attached to the domain, "public-inbox.org" is
too long for my tastes anyways.
Jonathan Nieder wrote:
> Jeff King wrote:
>
> > I guess I just wonder if I set up a mirror on another domain, would
> > anybody actually _use_ it? I'd think most people would just go to
> > public-inbox.org as the de facto URL.
>
> If it's faster than public-inbox.org and you don't mind the traf
Jeff King wrote:
> On Wed, Aug 29, 2018 at 10:02:43AM +, Eric Wong wrote:
> > Anyways I hope to teach public-inbox to auto-linkify Message-ID-looking
> > strings "" into URLs for domain-portability,
> > (but it's ambiguous with email addresses). But yeah
Jonathan Nieder wrote:
> Eric Wong wrote:
> > Jonathan Nieder wrote:
> >> Jeff King wrote:
>
> >>> I guess I just wonder if I set up a mirror on another domain, would
> >>> anybody actually _use_ it? I'd think most people would just go to
> &
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,
> +
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
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
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
---
attr.c| 2 +-
blame.c | 6 +++---
builtin/difftool.c| 5 +++--
builtin/fast-export.c | 2 +-
config.c | 2
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 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
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
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
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
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
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
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
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
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
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
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:
> >
>
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...
>
>
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
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:
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
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
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
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
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
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 -
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:
> 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 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
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
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
:
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
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 ++--
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
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 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
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 ++-
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
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?
>
&
Andreas Heiduk wrote:
> The email address in --authors-file and --authors-prog can be empty but
> git-svn translated it into a syntethic email address in the form
> $USERNAME@$REPO_UUID. Now git-svn behaves like git-commit: If the email
> is explicitly set to the empty string, the commit does not
Andreas Heiduk wrote:
> Am 19.03.2018 um 00:04 schrieb Eric Wong:
> > Andreas Heiduk wrote:
> >> The email address in --authors-file and --authors-prog can be empty but
> >> git-svn translated it into a syntethic email address in the form
> >> $USERNAME@$REP
Ævar Arnfjörð Bjarmason wrote:
> Good point. I also see that (via git log --author=Ævar --grep='^\[PATCH
> ') that this series itself arrived out of order (0 -> 2 -> 1), but I
> don't know to what extent public-inbox itself might be batching things.
public-inbox doesn't batch, aside from when the
Thanks for the update. The patch itself looks good, but I
noticed one --show-item isn't supported on SVN 1.8.10 for me.
I've tested the following on both SVN 1.8.10 and 1.9.5:
--- a/t/t9138-git-svn-authors-prog.sh
+++ b/t/t9138-git-svn-authors-prog.sh
@@ -83,7 +83,8 @@ test_expect_success 'autho
Andreas Heiduk wrote:
> Am 05.04.2018 um 09:51 schrieb Eric Wong:
> > Can you confirm it's OK for you? Thanks.
>
> Looks good, works for me.
>
> Do you squash this patch with with my commit or do you need a reroll?
Nope, no need to reroll. Pushed to my repo fo
Ævar Arnfjörð Bjarmason wrote:
> See https://public-inbox.org/git/86h8oobl36@phe.ftfl.ca/ for the
> original report.
Thanks for taking a look at this. Also https://bugs.debian.org/894997
> --- a/perl/Git.pm
> +++ b/perl/Git.pm
> @@ -554,7 +554,7 @@ sub get_record {
> my ($fh, $rs) = @
Ævar Arnfjörð Bjarmason wrote:
> On Fri, Apr 06 2018, Eric Wong wrote:
> > Ævar Arnfjörð Bjarmason wrote:
> >
> >> --- a/perl/Git.pm
> >> +++ b/perl/Git.pm
> >> @@ -554,7 +554,7 @@ sub get_record {
> >>my ($fh, $rs) = @_;
> >>lo
David Davis wrote:
> Hello, I have the following git send-email command:
>
> git send-email -5 --quiet --thread --no-chain-reply-to --compose
> --subject='Recent Base Prototype Changes Summary'
> --to=davisda...@google.com --from=davisda...@google.com
>
> It's sending emails but as 5 individual
401 - 500 of 955 matches
Mail list logo
