On Wed, Mar 13 2019, Jeff King wrote:
> On Wed, Mar 13, 2019 at 12:47:51PM +0100, Thomas Braun wrote:
>
>> > Reading Thomas's email again, that might actually have been what he was
>> > recommending. If so, sorry for the confusion. And I agree that's a valid
>> > solution.
>>
>> Yes that is what
On Wed, Mar 13, 2019 at 12:47:51PM +0100, Thomas Braun wrote:
> > Reading Thomas's email again, that might actually have been what he was
> > recommending. If so, sorry for the confusion. And I agree that's a valid
> > solution.
>
> Yes that is what I tried to explain. Looks like it was lost in t
Am 12.03.2019 um 11:51 schrieb Jeff King:
> On Tue, Mar 12, 2019 at 04:27:57PM +0900, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>>> The problem to me is not that the steps that a developer has to do, but
>>> rather that we are dependent on the upstream project to make a simple
>>> fix (whic
On Tue, Mar 12, 2019 at 01:09:42PM +0100, Ævar Arnfjörð Bjarmason wrote:
> > To be clear, I do sympathize with the notion that not pulling things
> > in-tree keeps our relationship with upstream more disciplined, and that
> > has value. I'm just not altogether clear how much it's really hurt us
>
On Tue, Mar 12 2019, Jeff King wrote:
> On Tue, Mar 12, 2019 at 09:53:41AM +0100, Ævar Arnfjörð Bjarmason wrote:
>
>> There's a at least a couple of aspects to this.
>>
>> One is whether we should have the submodule in
>> sha1collisiondetection/. I agree that's probably a bad idea now
>> per-se.
On Tue, Mar 12, 2019 at 09:53:41AM +0100, Ævar Arnfjörð Bjarmason wrote:
> There's a at least a couple of aspects to this.
>
> One is whether we should have the submodule in
> sha1collisiondetection/. I agree that's probably a bad idea now
> per-se. Honestly I wasn't expecting the answer when I s
On Tue, Mar 12, 2019 at 04:27:57PM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > The problem to me is not that the steps that a developer has to do, but
> > rather that we are dependent on the upstream project to make a simple
> > fix (which they may not agree to do, or may take a long
On Mon, Mar 11 2019, Jeff King wrote:
> On Mon, Mar 11, 2019 at 07:15:12PM +0100, Thomas Braun wrote:
>
>> Am 11.03.2019 um 12:58 schrieb Duy Nguyen:
>> > On Mon, Mar 11, 2019 at 10:48 AM Jeff King wrote:
>> >> And AFAIK there is no good way to
>> >> modify the submodule-provided content as par
Jeff King writes:
> The problem to me is not that the steps that a developer has to do, but
> rather that we are dependent on the upstream project to make a simple
> fix (which they may not agree to do, or may take a long time to do).
Yeah. In practice, I think the recommended way to work for a
On Mon, Mar 11, 2019 at 07:15:12PM +0100, Thomas Braun wrote:
> Am 11.03.2019 um 12:58 schrieb Duy Nguyen:
> > On Mon, Mar 11, 2019 at 10:48 AM Jeff King wrote:
> >> And AFAIK there is no good way to
> >> modify the submodule-provided content as part of the build. Why do we
> >> even have the sub
On Mon, Mar 11, 2019 at 06:40:21AM -0400, Jeffrey Walton wrote:
> > So anyway, I think this needs a patch to the upstream sha1dc project.
>
> https://github.com/cr-marcstevens/sha1collisiondetection/issues/47
Thanks, it looks like the turnaround on that may be pretty quick. Once
it's merged ther
Am 11.03.2019 um 12:58 schrieb Duy Nguyen:
> On Mon, Mar 11, 2019 at 10:48 AM Jeff King wrote:
>> And AFAIK there is no good way to
>> modify the submodule-provided content as part of the build. Why do we
>> even have the submodule again? ;P
>
> Because of dogfooding of course. This is an interes
On Mon, Mar 11, 2019 at 10:48 AM Jeff King wrote:
> And AFAIK there is no good way to
> modify the submodule-provided content as part of the build. Why do we
> even have the submodule again? ;P
Because of dogfooding of course. This is an interesting use case
though. I wonder if people often want
On Sun, Mar 10, 2019 at 11:37 PM Jeff King wrote:
>
> On Mon, Mar 11, 2019 at 11:00:25AM +0900, Junio C Hamano wrote:
>
> > Jeffrey Walton writes:
> >
> > > I think this is the patch for sha1dc/sha1.c . It stops using unaligned
> > > accesses by default, but still honors SHA1DC_FORCE_UNALIGNED_AC
On Mon, Mar 11, 2019 at 11:00:25AM +0900, Junio C Hamano wrote:
> Jeffrey Walton writes:
>
> > I think this is the patch for sha1dc/sha1.c . It stops using unaligned
> > accesses by default, but still honors SHA1DC_FORCE_UNALIGNED_ACCESS
> > for those who want it. Folks who want the undefined be
On Sat, Mar 09, 2019 at 07:34:15AM -0500, Jeffrey Walton wrote:
> > It would probably help to know what commit you're building.
> > The verbose test output would also be useful, e.g.:
>
> I built with CFLAGS += -fsanitize=undefined. It looks like the
> misaligned accesses generate UBsan findings,
On Sun, Mar 10, 2019 at 10:00 PM Junio C Hamano wrote:
>
> Jeffrey Walton writes:
>
> > I think this is the patch for sha1dc/sha1.c . It stops using unaligned
> > accesses by default, but still honors SHA1DC_FORCE_UNALIGNED_ACCESS
> > for those who want it. Folks who want the undefined behavior h
Jeffrey Walton writes:
> I think this is the patch for sha1dc/sha1.c . It stops using unaligned
> accesses by default, but still honors SHA1DC_FORCE_UNALIGNED_ACCESS
> for those who want it. Folks who want the undefined behavior have to
> do something special.
Hmph, I somehow thought that folks
On Sat, Mar 9, 2019 at 7:34 AM Jeffrey Walton wrote:
>
> On Fri, Mar 8, 2019 at 12:43 PM Todd Zullinger wrote:
> >
> > Jeffrey Walton wrote:
> > > Fedora 29, x86_64. One failed self test:
> > >
> > > *** t0021-conversion.sh ***
> > [...]
> > > not ok 13 - disable filter with empty override
> > >
On Fri, Mar 8, 2019 at 12:43 PM Todd Zullinger wrote:
>
> Jeffrey Walton wrote:
> > Fedora 29, x86_64. One failed self test:
> >
> > *** t0021-conversion.sh ***
> [...]
> > not ok 13 - disable filter with empty override
> > #
> > # test_config_global filter.disable.smudge false &&
>
Hi,
Jeffrey Walton wrote:
> Fedora 29, x86_64. One failed self test:
>
> *** t0021-conversion.sh ***
[...]
> not ok 13 - disable filter with empty override
> #
> # test_config_global filter.disable.smudge false &&
> # test_config_global filter.disable.clean false &&
>
Fedora 29, x86_64. One failed self test:
*** t0021-conversion.sh ***
ok 1 - setup
ok 2 - check
ok 3 - expanded_in_repo
ok 4 - filter shell-escaped filenames
ok 5 - required filter should filter data
ok 6 - required filter smudge failure
ok 7 - required filter clean failure
ok 8 - filtering large i
22 matches
Mail list logo
