On August 16, 2019 5:00 PM, Junio C Hamano wrote:
> The latest feature release Git v2.23.0 is now available at the usual places.
> It
> is comprised of 505 non-merge commits since v2.22.0, contributed by 77
> people, 26 of which are new faces.
We are having a transient failure in t0021. It runs
Thanks, a bunch Junio! :)
On 14:00 Fri 16 Aug 2019, Junio C Hamano wrote:
The latest feature release Git v2.23.0 is now available at the
usual places. It is comprised of 505 non-merge commits since
v2.22.0, contributed by 77 people, 26 of which are new faces.
The tarballs are found at:
ht
The latest feature release Git v2.23.0 is now available at the
usual places. It is comprised of 505 non-merge commits since
v2.22.0, contributed by 77 people, 26 of which are new faces.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/
The following public repositories
On August 9, 2019 5:24 PM, I wrote:
> On 12:29 Fri 09 Aug 2019, Junio C Hamano wrote:
> > >A release candidate Git v2.23.0-rc2 is now available for testing at
> > >the usual places. It is comprised of 483 non-merge commits since
> > >v2.22.0, contributed by 67 people, 24 of which are new faces.
>
Team,
On Fri, 9 Aug 2019, Junio C Hamano wrote:
> A release candidate Git v2.23.0-rc2 is now available for testing
> at the usual places. It is comprised of 483 non-merge commits
> since v2.22.0, contributed by 67 people, 24 of which are new faces.
>
> The tarballs are found at:
>
> https://
On 12:29 Fri 09 Aug 2019, Junio C Hamano wrote:
> >A release candidate Git v2.23.0-rc2 is now available for testing at the
> >usual places. It is comprised of 483 non-merge commits since v2.22.0,
> >contributed by 67 people, 24 of which are new faces.
> >
> >The tarballs are found at:
> >
> >h
Thanks, Junio! will dig in.
On 12:29 Fri 09 Aug 2019, Junio C Hamano wrote:
A release candidate Git v2.23.0-rc2 is now available for testing
at the usual places. It is comprised of 483 non-merge commits
since v2.22.0, contributed by 67 people, 24 of which are new faces.
The tarballs are fo
A release candidate Git v2.23.0-rc2 is now available for testing
at the usual places. It is comprised of 483 non-merge commits
since v2.22.0, contributed by 67 people, 24 of which are new faces.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/testing/
The following pu
Team,
On Fri, 2 Aug 2019, Junio C Hamano wrote:
> A release candidate Git v2.23.0-rc1 is now available for testing
> at the usual places. It is comprised of 471 non-merge commits
> since v2.22.0, contributed by 63 people, 23 of which are new faces.
>
> The tarballs are found at:
>
> https://
A release candidate Git v2.23.0-rc1 is now available for testing
at the usual places. It is comprised of 471 non-merge commits
since v2.22.0, contributed by 63 people, 23 of which are new faces.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/testing/
The following pu
On Fri, Aug 02, 2019 at 09:53:55AM -0700, Junio C Hamano wrote:
> Jonathan Nieder writes:
>
> > We'll also want to update the docs. And as Todd suggests, we should
> > cover how to disable mailmap in tests.
> >
> > Signed-off-by: Jonathan Nieder
> > ---
>
> I avoided the "don't bother initial
Jonathan Nieder writes:
> We'll also want to update the docs. And as Todd suggests, we should
> cover how to disable mailmap in tests.
>
> Signed-off-by: Jonathan Nieder
> ---
I avoided the "don't bother initializing use_mailmap_config to
unknown" simplification, but I guess the change is clea
Junio C Hamano wrote:
> I suspect that you may have misread the "is interactive" bit in the
> original; that was used only to decide if we are going to warn.
Ah. That was indeed confusing. Anyway, it's nice to see the complexity
go away.
[...]
> +++ b/builtin/log.c
[...]
> @@ -214,12 +204,8 @@
Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Jeff King writes:
>>
+ if (mailmap < 0)
mailmap = 0;
- }
>>>
>>> This should be "mailmap = 1" to match the commit message, no? (Which
>>> also implies we may want a new test).
>>
[...]
> +test_expect_success 'log.mai
Junio C Hamano writes:
> Jeff King writes:
>
>>> + if (mailmap < 0)
>>> mailmap = 0;
>>> - }
>>
>> This should be "mailmap = 1" to match the commit message, no? (Which
>> also implies we may want a new test).
>
> Gaa, of course.
-- >8 --
From: Junio C Hamano
Date: Thu, 1 Aug 20
Jeff King writes:
>> +if (mailmap < 0)
>> mailmap = 0;
>> -}
>
> This should be "mailmap = 1" to match the commit message, no? (Which
> also implies we may want a new test).
Gaa, of course.
> I'd also be OK with leaving it at "0" for now, making a note of the
> upcoming cha
Hi Bryan,
On Wed, 31 Jul 2019, Bryan Turner wrote:
> On Wed, Jul 31, 2019 at 5:43 AM Johannes Schindelin
> wrote:
> >
> > Hi,
> >
> > On Mon, 29 Jul 2019, Junio C Hamano wrote:
> >
> > > An early preview release Git v2.23.0-rc0 is now available for
> > > testing at the usual places. It is compr
Hi,
On Wed, 31 Jul 2019, Ariadne Conill wrote:
> Hello,
>
> On Wed, Jul 31, 2019 at 10:21 PM Junio C Hamano wrote:
> >
> > Jeff King writes:
> >
> > > This seems OK to me, though I kind of wonder if anybody really wants
> > > "auto". Unlike log.decorate, which changes the syntax, there is no re
On Thu, Aug 01, 2019 at 08:45:54AM -0700, Junio C Hamano wrote:
> While I think "revert to hardcoded default" may be a good idea, I do
> not think the hardcoded default you implemented that changes the
> behaviour based on the output destination makes much sense. If I
> want to eradicate jun...@c
Hello,
On Thu, Aug 1, 2019 at 10:46 AM Junio C Hamano wrote:
>
> Jonathan Nieder writes:
>
> > Although as Dscho mentions, it's particularly irritating because it is
> > not part of the paginated output.
> > ...
> > Let's bite the bullet and jump straight to --use-mailmap in case (4).
> >
> > Wh
Jonathan Nieder writes:
> Although as Dscho mentions, it's particularly irritating because it is
> not part of the paginated output.
> ...
> Let's bite the bullet and jump straight to --use-mailmap in case (4).
>
> While at it, add a new log.mailmap setting "auto" that can be used to
> explicitly
Hello,
On Wed, Jul 31, 2019 at 10:21 PM Junio C Hamano wrote:
>
> Jeff King writes:
>
> > This seems OK to me, though I kind of wonder if anybody really wants
> > "auto". Unlike log.decorate, which changes the syntax, there is no real
> > reason to avoid mailmap when somebody else is parsing the
Jeff King writes:
> This seems OK to me, though I kind of wonder if anybody really wants
> "auto". Unlike log.decorate, which changes the syntax, there is no real
> reason to avoid mailmap when somebody else is parsing the output. And I
> could imagine it is especially confusing if:
>
> git log
On Wed, Jul 31, 2019 at 08:38:14PM -0500, Ariadne Conill wrote:
> > Something like:
> >
> > Author: A U Thor
> > Original-Author: I M Mailmapped
> >
> > gives even more information while leaving the "Author:" line untouched.
> > But in introducing a new line, it may also be breaking somebody
Hello,
On Wed, Jul 31, 2019 at 8:00 PM Jeff King wrote:
>
> On Wed, Jul 31, 2019 at 05:21:25PM -0700, Jonathan Nieder wrote:
>
> > Although as Dscho mentions, it's particularly irritating because it is
> > not part of the paginated output.
> >
> > I wonder if the ideal might not be to trigger it
Jeff King wrote:
> This seems OK to me, though I kind of wonder if anybody really wants
> "auto".
Sure. It's just the usual way of handling the lack of support for an
"unset" directive in git's config syntax (for example, if a script
author wants to test the default behavior).
Thanks,
Jonathan
On Wed, Jul 31, 2019 at 5:43 AM Johannes Schindelin
wrote:
>
> Hi,
>
> On Mon, 29 Jul 2019, Junio C Hamano wrote:
>
> > An early preview release Git v2.23.0-rc0 is now available for
> > testing at the usual places. It is comprised of 420 non-merge
> > commits since v2.22.0, contributed by 62 peop
On Wed, Jul 31, 2019 at 05:21:25PM -0700, Jonathan Nieder wrote:
> Although as Dscho mentions, it's particularly irritating because it is
> not part of the paginated output.
>
> I wonder if the ideal might not be to trigger it more selectively, when
> the output actually changed due to a reflog e
Hello,
On Wed, Jul 31, 2019 at 7:21 PM Jonathan Nieder wrote:
>
> Jeff King wrote:
>
> > I think part of what my annoyance is responding to (and your willingness
> > to just squelch this for everybody) is that switching this particular
> > default isn't really that big a deal, that it requires an
Jeff King wrote:
> I think part of what my annoyance is responding to (and your willingness
> to just squelch this for everybody) is that switching this particular
> default isn't really that big a deal, that it requires annoying people
> on every single "git log" invocation. Perhaps we would be b
On Wed, Jul 31, 2019 at 02:43:10PM +0200, Johannes Schindelin wrote:
> And a corresponding Git for Windows v2.23.0-rc0 can be found here:
>
> https://github.com/git-for-windows/git/releases/tag/v2.23.0-rc0.windows.1
>
> Please test!
>
> One (slightly annoying) issue I found already is that a `g
Jeff King writes:
> And here it is for reference with the matching change in test-oidmap,
> and the adjustments necessary for the test scripts (from master, not
> from my earlier patch). I think I prefer the simpler "just sort it all"
> version I posted with the commit message.
Yeah, let's go wi
Jeff King writes:
> So regardless of the endian thing above, it probably does make sense for
> any hashmap iteration output to be sorted before comparing. That goes
> for t0011, too; it doesn't have this endian thing, but it looks to be
> relying on hash order that could change if we swapped out
Hi,
On Mon, 29 Jul 2019, Junio C Hamano wrote:
> An early preview release Git v2.23.0-rc0 is now available for
> testing at the usual places. It is comprised of 420 non-merge
> commits since v2.22.0, contributed by 62 people, 23 of which are
> new faces.
>
> The tarballs are found at:
>
> ht
Jeff King wrote:
> On Tue, Jul 30, 2019 at 09:59:17PM -0400, Todd Zullinger wrote:
>> At the risk of showing my complete lack of knowledge about
>> these tests, I was wondering if the order mattered for the
>> other tests in t0011 and t0016.
[...]
>> You've got a more comprehensive patch and a prop
On Wed, Jul 31, 2019 at 06:06:02AM +0200, René Scharfe wrote:
> Am 31.07.19 um 05:27 schrieb Jeff King:
> > One thing that makes it all a bit funky is that the "put" lines also
> > output the old value (which is what all those NULLs) are. And I think
> > that solves my "value3" puzzlement from ear
Am 31.07.19 um 05:27 schrieb Jeff King:
> One thing that makes it all a bit funky is that the "put" lines also
> output the old value (which is what all those NULLs) are. And I think
> that solves my "value3" puzzlement from earlier. It is not part of the
> iteration at all, but rather the result o
On Tue, Jul 30, 2019 at 11:27:35PM -0400, Jeff King wrote:
> That would perhaps be clearer if the "hashmap" tool actually did the
> sorting itself (so we'd sort _just_ the iteration, not the whole
> output). Something like this, though I'm on the fence about whether it
> is worth it:
> [...]
And
On Tue, Jul 30, 2019 at 09:59:17PM -0400, Todd Zullinger wrote:
> At the risk of showing my complete lack of knowledge about
> these tests, I was wondering if the order mattered for the
> other tests in t0011 and t0016. I had assumed it didn't and
> had something like this for testing (and a simi
Jeff King wrote:
> On Tue, Jul 30, 2019 at 08:59:33PM -0400, Jeff King wrote:
>
>>> OTOH, this is not just any hashmap, but an oidmap, and I could imagine
>>> that there might be use cases where it would be beneficial if the
>>> iteration order were to match the oid order (but don't know whether w
On Tue, Jul 30, 2019 at 09:23:36PM -0400, Jeff King wrote:
> test_expect_success 'iterate (case insensitive)' '
> -
> -test_hashmap "put key1 value1
> -put key2 value2
> -put fooBarFrotz value3
> -iterate" "NULL
> -NULL
> -NULL
> -fooBarFrotz value3
> -key2 value2
> -key1 value1" ignorecase
By t
On Tue, Jul 30, 2019 at 08:59:33PM -0400, Jeff King wrote:
> > OTOH, this is not just any hashmap, but an oidmap, and I could imagine
> > that there might be use cases where it would be beneficial if the
> > iteration order were to match the oid order (but don't know whether we
> > actually have s
On Tue, Jul 30, 2019 at 10:56:24PM +0200, SZEDER Gábor wrote:
> > Ah, of course. Our oid hashing is done by just picking off the first
> > bytes of the sha1, and it doesn't care about endianness (because these
> > are just internal-to-memory hashes).
>
> Yeah.
>
> > We _could_ reconcile that lik
On Tue, Jul 30, 2019 at 04:02:03PM -0400, Jeff King wrote:
> On Tue, Jul 30, 2019 at 03:49:38PM -0400, Todd Zullinger wrote:
>
> > > Subtest 6 had an ordering issue. We do not know whether
> > > the problem is the code or the test result not keeping up
> > > with the code changes.
> > >
> > > ---
Jeff King writes:
> @@ -116,19 +116,11 @@ unsigned int memihash_cont(unsigned int hash_seed,
> const void *buf, size_t len);
> * Converts a cryptographic hash (e.g. SHA-1) into an int-sized hash code
> * for use in hash tables. Cryptographic hashes are supposed to have
> * uniform distribu
On July 30, 2019 3:50 PM, Todd Zullinger wrote:
> To: Randall S. Becker
> Cc: 'Junio C Hamano' ; Christian Couder
> ; SZEDER Gábor ; Jeff
> King ; git@vger.kernel.org; git-
> packag...@googlegroups.com
> Subject: Re: [ANNOUNCE] Git v2.23.0-rc0 - Initial test
On July 30, 2019 3:45 PM, Jeff King wrote:
> To: Randall S. Becker
> Cc: 'Junio C Hamano' ; git@vger.kernel.org; git-
> packag...@googlegroups.com
> Subject: Re: [ANNOUNCE] Git v2.23.0-rc0 - Initial test failures on NonStop
>
> On Tue, Jul 30, 2019 at 01:08:37PM -0
On Tue, Jul 30, 2019 at 03:49:38PM -0400, Todd Zullinger wrote:
> > Subtest 6 had an ordering issue. We do not know whether
> > the problem is the code or the test result not keeping up
> > with the code changes.
> >
> > --- expect 2019-07-30 16:56:36 +
> > +++ actual 2019-07-30 16:5
Hi,
[added Christian, SZEDER, and Jeff to Cc as author and
helpers on the newly-added t0016-oidmap]
Randall S. Becker wrote:
> A preview of the situation with testing 2.23.0.rc0 on
> NonStop is not great. We have had some new failures right
> off the bat on our NonStop platforms. This is a previe
On Tue, Jul 30, 2019 at 01:08:37PM -0400, Randall S. Becker wrote:
> t0016: oidmap
>
> Subtest 6 had an ordering issue. We do not know whether the problem is the
> code or the test result not keeping up with the code changes.
> --- expect 2019-07-30 16:56:36 +
> +++ actual 2019-07-
"Randall S. Becker" writes:
> On July 30, 2019 1:32 PM, Junio C Hamano wrote:
>>
>> I wonder if a tool like sparse can help us catch a pattern that feeds
> errno to
>> "%d" format.
>> ...
> Seems reasonable. Better than trying to use strerror(), which previously
> (I'm not sure whether it was t
On July 30, 2019 1:32 PM, Junio C Hamano wrote:
> "Randall S. Becker" writes:
>
> > t0066: dir-iterator
> >
> > Subtest 4 depends on a non-portable error code. ENOENT is not
> guaranteed ...
> > Subtest 5 also depends on a non-portable error code. ENOTDIR is not
gua...
>
> Yikes, and sorry. I'v
Hi, Junio and Randall
On Tue, Jul 30, 2019 at 2:31 PM Junio C Hamano wrote:
>
> "Randall S. Becker" writes:
>
> > t0066: dir-iterator
> >
> > Subtest 4 depends on a non-portable error code. ENOENT is not guaranteed ...
> > Subtest 5 also depends on a non-portable error code. ENOTDIR is not gua..
"Randall S. Becker" writes:
> t0066: dir-iterator
>
> Subtest 4 depends on a non-portable error code. ENOENT is not guaranteed ...
> Subtest 5 also depends on a non-portable error code. ENOTDIR is not gua...
Yikes, and sorry. I've become somewhat complacent after relying on
how good our other r
Hi All,
A preview of the situation with testing 2.23.0.rc0 on NonStop is not great. We
have had some new failures right off the bat on our NonStop platforms. This is
a preview of what we find within the first bit of testing. The tests run a long
time, so more to come.
t0016: oidmap
Subtest 6
An early preview release Git v2.23.0-rc0 is now available for
testing at the usual places. It is comprised of 420 non-merge
commits since v2.22.0, contributed by 62 people, 23 of which are
new faces.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/testing/
The followi
56 matches
Mail list logo
