Re: What's cooking in git.git (Dec 2017, #01; Mon, 4)

Hi Torsten, On Sat, 9 Dec 2017, Torsten Bögershausen wrote: > On Thu, Dec 07, 2017 at 04:33:12PM -0500, Todd Zullinger wrote: > > Jeff Hostetler wrote: > > >I'm looking at t5616 now on my mac. > > >Looks like the MAC doesn't like my line counting in the tests. > > >I'll fix in my next version. >

Re: What's cooking in git.git (Dec 2017, #01; Mon, 4)

On Thu, Dec 07, 2017 at 04:33:12PM -0500, Todd Zullinger wrote: > Jeff Hostetler wrote: > >I'm looking at t5616 now on my mac. > >Looks like the MAC doesn't like my line counting in the tests. > >I'll fix in my next version. > [] > | sort >expect_2.oids && > - test "$(wc -l

Re: What's cooking in git.git (Dec 2017, #01; Mon, 4)

Jeff Hostetler wrote: I'm looking at t5616 now on my mac. Looks like the MAC doesn't like my line counting in the tests. I'll fix in my next version. Perhaps that's as simple as using the test_line_counts helper? diff --git i/t/t5616-partial-clone.sh w/t/t5616-partial-clone.sh index

Re: What's cooking in git.git (Dec 2017, #01; Mon, 4)

Lars Schneider writes: >> The acl stuff hasn't changed for a long time and I do not think of a >> reason offhand why the test should behave differently between say >> 'maint' and 'pu', yet 'maint' is passing while 'pu' is not... > > My recent 657343a602 (travis-ci: move

Re: What's cooking in git.git (Dec 2017, #01; Mon, 4)

Jeff Hostetler writes: > I'm looking at t5616 now on my mac. > Looks like the MAC doesn't like my line counting in the tests. Ah, of course, test "$(wc -l)" = number would not work over there we have "test_line_count" helper exactly for that purose.

Re: What's cooking in git.git (Dec 2017, #01; Mon, 4)

On 12/7/2017 10:48 AM, Johannes Schindelin wrote: Hi, [...] That is not the only thing going wrong: https://travis-ci.org/git/git/builds/312551566 It would seem that t9001 is broken on Linux32, t5616 is broken on macOS, and something really kinky is going on with the

Re: What's cooking in git.git (Dec 2017, #01; Mon, 4)

> On 07 Dec 2017, at 21:50, Junio C Hamano wrote: > > Todd Zullinger writes: > >> Johannes Schindelin wrote: >>> That is not the only thing going wrong: >>> >>> https://travis-ci.org/git/git/builds/312551566 >>> >>> It would seem that t9001 is broken

Re: What's cooking in git.git (Dec 2017, #01; Mon, 4)

Todd Zullinger writes: > Johannes Schindelin wrote: >> That is not the only thing going wrong: >> >> https://travis-ci.org/git/git/builds/312551566 >> >> It would seem that t9001 is broken on Linux32, t5616 is broken on macOS, >> and something really kinky is going on with

Re: What's cooking in git.git (Dec 2017, #01; Mon, 4)

Johannes Schindelin wrote: That is not the only thing going wrong: https://travis-ci.org/git/git/builds/312551566 It would seem that t9001 is broken on Linux32, t5616 is broken on macOS, and something really kinky is going on with the GETTEXT_POISON text, as it seems to just abort

Re: What's cooking in git.git (Dec 2017, #01; Mon, 4)

Hi, On Wed, 6 Dec 2017, Lars Schneider wrote: > > > On 04 Dec 2017, at 22:46, Junio C Hamano wrote: > > > > > > * tb/check-crlf-for-safe-crlf (2017-11-27) 1 commit > > - convert: tighten the safe autocrlf handling > > > > The "safe crlf" check incorrectly triggered for

Re: What's cooking in git.git (Dec 2017, #01; Mon, 4)

Torsten Bögershausen writes: >> Looks like t0027-auto-crlf.sh is failing on Windows: >> https://travis-ci.org/git/git/jobs/312135514 >> >> Could that patch be related? >> >> - Lars >> > Chances are high, I will have a look. > Thanks for noticing. Thanks.

Re: What's cooking in git.git (Dec 2017, #01; Mon, 4)

On 2017-12-06 16:14, Lars Schneider wrote: > >> On 04 Dec 2017, at 22:46, Junio C Hamano wrote: >> >> >> * tb/check-crlf-for-safe-crlf (2017-11-27) 1 commit >> - convert: tighten the safe autocrlf handling >> >> The "safe crlf" check incorrectly triggered for contents that

Re: What's cooking in git.git (Dec 2017, #01; Mon, 4)

> On 04 Dec 2017, at 22:46, Junio C Hamano wrote: > > > * tb/check-crlf-for-safe-crlf (2017-11-27) 1 commit > - convert: tighten the safe autocrlf handling > > The "safe crlf" check incorrectly triggered for contents that does > not use CRLF as line endings, which has been

Re: What's cooking in git.git (Dec 2017, #01; Mon, 4)

Jonathan Tan writes: > On Mon, 04 Dec 2017 13:46:43 -0800 > Junio C Hamano wrote: > >> * jt/diff-anchored-patience (2017-11-28) 1 commit >> - diff: support anchoring line(s) >> >> "git diff" learned a variant of the "--patience" algorithm, to >>

Re: What's cooking in git.git (Dec 2017, #01; Mon, 4)

On Mon, 04 Dec 2017 13:46:43 -0800 Junio C Hamano wrote: > * jt/diff-anchored-patience (2017-11-28) 1 commit > - diff: support anchoring line(s) > > "git diff" learned a variant of the "--patience" algorithm, to > which the user can specify which 'unique' line to be used

Re: What's cooking in git.git (Dec 2017, #01; Mon, 4)

On Mon, Dec 4, 2017 at 1:46 PM, Junio C Hamano wrote: > * en/rename-directory-detection (2017-11-21) 33 commits > Rename detection logic in "diff" family that is used in "merge" has > learned to guess when all of x/a, x/b and x/c have moved to z/a, > z/b and z/c, it is

Re: What's cooking in git.git (Dec 2017, #01; Mon, 4)

On 12/4/2017 4:46 PM, Junio C Hamano wrote: * cc/object-filtering-typofix (2017-12-04) 1 commit - list-objects-filter-options: fix 'keword' typo in comment (this branch uses jh/object-filtering; is tangled with jh/fsck-promisors and jh/partial-clone.) Typofix for a topic already in

What's cooking in git.git (Dec 2017, #01; Mon, 4)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear in any of the integration branches, but I am still holding onto them. You can find the changes