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

[Johannes Schindelin]

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.
> > 
> []
> > | sort >expect_2.oids &&
> > -   test "$(wc -l  > +   test_line_count = 8 expect_2.oids &&
> > git -C src blame master -- file.1.txt >expect.blame
> > '
> 
> 
> The problem seems to be the '"' around wc, this would work:
> test $(wc -l  
> 
> What do you guys think a about a lint test like this:
> 
> diff --git a/t/check-non-portable-shell.pl b/t/check-non-portable-shell.pl
> index 03dc9d2852..9ebf65c26f 100755
> --- a/t/check-non-portable-shell.pl
> +++ b/t/check-non-portable-shell.pl
> @@ -21,6 +21,7 @@ while (<>) {
>   /^\s*declare\s+/ and err 'arrays/declare not portable';
>   /^\s*[^#]\s*which\s/ and err 'which is not portable (please use type)';
>   /\btest\s+[^=]*==/ and err '"test a == b" is not portable (please use 
> =)';
> + /\bwc -l.*"\s*=/ and err '`"$(wc -l)"` is not portable, please use 
> `$(wc -l)`';
>   /\bexport\s+[A-Za-z0-9_]*=/ and err '"export FOO=bar" is not portable 
> (please use FOO=bar && expo

Please suggest `test_line_count` instead.

Ciao,
Dscho

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

[Torsten Bögershausen]

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  + test_line_count = 8 expect_2.oids &&
>   git -C src blame master -- file.1.txt >expect.blame
> '


The problem seems to be the '"' around wc, this would work:
test $(wc -l ) {
/^\s*declare\s+/ and err 'arrays/declare not portable';
/^\s*[^#]\s*which\s/ and err 'which is not portable (please use type)';
/\btest\s+[^=]*==/ and err '"test a == b" is not portable (please use 
=)';
+   /\bwc -l.*"\s*=/ and err '`"$(wc -l)"` is not portable, please use 
`$(wc -l)`';
/\bexport\s+[A-Za-z0-9_]*=/ and err '"export FOO=bar" is not portable 
(please use FOO=bar && expo

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

[Todd Zullinger]

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 fa573f8cdb..6d673de90c 100755
--- i/t/t5616-partial-clone.sh
+++ w/t/t5616-partial-clone.sh
@@ -19,7 +19,7 @@ test_expect_success 'setup normal src repo' '
git -C src ls-files -s file.$n.txt >>temp
done &&
awk -f print_2.awk expect_1.oids &&
-   test "$(wc -l expect.blame
'

@@ -100,7 +100,7 @@ test_expect_success 'partial fetch inherits filter 
settings' '
# it should be in a new packfile (since the promisor boundary is
# currently a packfile, it should not get unpacked upon receipt.)
test_expect_success 'verify diff causes dynamic object fetch' '
-   test "$(wc -l observed.oids &&
cat observed.oids &&
-   test "$(wc -l 

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

[Junio C Hamano]

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 Travis CI code into dedicated scripts, 
> 2017-09-10) change might have broken that somehow...

But the puzzling thing is that commit is in 'maint' as well as 'pu'.

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

[Junio C Hamano]

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)

[Jeff Hostetler]

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 GETTEXT_POISON text, as it
seems to just abort while trying to run t6120.

Ciao,
Johannes



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.

Jeff

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

[Lars Schneider]

> 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 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 while trying to run t6120.
>> 
>> I thought the verbose logs from the test might be useful, but looking
>> at the travis output for that job[1], there's an unrelated problem
>> preventing the ci/print-test-failures.sh script from running properly:
>> 
>>   $ ci/print-test-failures.sh
>>   cat: t/test-results/t1304-default-acl.exit: Permission denied
>>   
>>   t/test-results/t1304-default-acl.out...
>>   
>>   cat: t/test-results/t1304-default-acl.out: Permission denied
>> 
>> [1] https://travis-ci.org/git/git/jobs/312551595#L2185
>> 
>> I didn't see the same failure for other build targets at a glance, so
>> the permission issue might only be a problem for the linux32 builds.
> 
> Curious.  
> 
> 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 Travis CI code into dedicated scripts, 
2017-09-10) change might have broken that somehow...

See this comment:

# If this script runs inside a docker container, then all commands are
# usually executed as root. Consequently, the host user might not be
# able to access the test output files.
# If a host user id is given, then create a user "ci" with the host user
# id to make everything accessible to the host user.

https://github.com/git/git/blob/95ec6b1b3393eb6e26da40c565520a8db9796e9f/ci/run-linux32-build.sh#L16-L20

- Lars

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

[Junio C Hamano]

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 the GETTEXT_POISON text, as it
>> seems to just abort while trying to run t6120.
>
> I thought the verbose logs from the test might be useful, but looking
> at the travis output for that job[1], there's an unrelated problem
> preventing the ci/print-test-failures.sh script from running properly:
>
>$ ci/print-test-failures.sh
>cat: t/test-results/t1304-default-acl.exit: Permission denied
>
>t/test-results/t1304-default-acl.out...
>
>cat: t/test-results/t1304-default-acl.out: Permission denied
>
> [1] https://travis-ci.org/git/git/jobs/312551595#L2185
>
> I didn't see the same failure for other build targets at a glance, so
> the permission issue might only be a problem for the linux32 builds.

Curious.  

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...

I wouldn't be surprised if Git::Error change is causing t9001
failure, as that can explain why 'pu' is different.

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

[Todd Zullinger]

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 while trying to run t6120.


I thought the verbose logs from the test might be useful, but looking
at the travis output for that job[1], there's an unrelated problem
preventing the ci/print-test-failures.sh script from running properly:

   $ ci/print-test-failures.sh
   cat: t/test-results/t1304-default-acl.exit: Permission denied
   
   t/test-results/t1304-default-acl.out...
   
   cat: t/test-results/t1304-default-acl.out: Permission denied

[1] https://travis-ci.org/git/git/jobs/312551595#L2185

I didn't see the same failure for other build targets at a glance, so
the permission issue might only be a problem for the linux32 builds.

--
Todd
~~
A diplomat is a person who can tell you to go to Hell in such a way
that you actually look forward to the trip.
   -- Anonymous

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

[Johannes Schindelin]

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 contents that does
> > not use CRLF as line endings, which has been corrected.
> > 
> > Will merge to 'next'.
> > 
> 
> Looks like t0027-auto-crlf.sh is failing on Windows:
> https://travis-ci.org/git/git/jobs/312135514
> 
> Could that patch be related?

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 while trying to run t6120.

Ciao,
Johannes

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

[Junio C Hamano]

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)

[Torsten Bögershausen]

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 does
>> not use CRLF as line endings, which has been corrected.
>>
>> Will merge to 'next'.
>>
> 
> 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.

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

[Lars Schneider]

> 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 corrected.
> 
> Will merge to 'next'.
> 

Looks like t0027-auto-crlf.sh is failing on Windows:
https://travis-ci.org/git/git/jobs/312135514

Could that patch be related?

- Lars

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

[Junio C Hamano]

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
>>  which the user can specify which 'unique' line to be used as
>>  anchoring points.
>
> Is there anything I can do to progress this?

I had an impression that there weren't any major outstanding issues.
Such topics will move at their own pace and the only thing somebody
could do to expedite is to somehow block other topics in flight so
that we have to worry about smaller number of topics ;-)

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

[Jonathan Tan]

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 as
>  anchoring points.

Is there anything I can do to progress this? Johannes Schindelin wrote
that he is in favor of this feature [1]. He also remarked on the fact
that the anchors are not freed [2], but I have replied [3] that it seems
that diff arguments are not freed in general (so there would be no good
place to put the freeing statements).

[1] 
https://public-inbox.org/git/alpine.DEB.2.21.1.1712011447550.98586@virtualbox/
[2] 
https://public-inbox.org/git/alpine.DEB.2.21.1.1711300134560.6482@virtualbox/
[3] 
https://public-inbox.org/git/20171130152605.1b775e9cc2ddd7f917424...@google.com/

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

[Elijah Newren]

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 likely that x/d added in the meantime would also
>  want to move to z/d by taking the hint that the entire directory
>  'x' moved to 'z'.

It appears that you're still using V3 of my directory rename detection
series; I got some feedback from Stefan and Johannes on that series
(including compilation failures on Windows) and believe I have
addressed all of it in V4, which can be found here:
   https://public-inbox.org/git/20171129014237.32570-1-new...@gmail.com/

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

[Jeff Hostetler]

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 'next'.

  JeffH said that jh/object-filtering needs further polishing a bit
  before graduating to 'master', so it would be appreciated if this
  can also be rolled into such an incremental update.


I've pulled this into my branch and will include it in my V6 update.
Thanks
jeff

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

[Junio C Hamano]

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 described here in the integration branches
of the repositories listed at

http://git-blame.blogspot.com/p/git-public-repositories.html

--
[New Topics]

* ab/simplify-perl-makefile (2017-12-04) 1 commit
 - Makefile: replace perl/Makefile.PL with simple make rules

 The build procedure for perl/ part has been greatly simplified by
 weaning ourselves off of MakeMaker.


* 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 'next'.

 JeffH said that jh/object-filtering needs further polishing a bit
 before graduating to 'master', so it would be appreciated if this
 can also be rolled into such an incremental update.


* cc/skip-to-optional-val (2017-12-04) 4 commits
 - diff: use skip_to_optional_val_default()
 - diff: use skip_to_optional_val()
 - index-pack: use skip_to_optional_val()
 - git-compat-util: introduce skip_to_optional_val()

 Introduce a helper to simplify code to parse a common pattern that
 expects either "--key" or "--key=".

 This may want a final reroll to make it harder to misuse by
 allowing NULL at the valp part of the argument.
 cf. 
 cf. 


* lb/rebase-i-short-command-names (2017-12-04) 9 commits
 - t3404: add test case for abbreviated commands
 - rebase -i: learn to abbreviate command names
 - rebase -i -x: add exec commands via the rebase--helper
 - rebase -i: update functions to use a flags parameter
 - rebase -i: replace reference to sha1 with oid
 - rebase -i: refactor transform_todo_ids
 - rebase -i: set commit to null in exec commands
 - Documentation: use preferred name for the 'todo list' script
 - Documentation: move rebase.* configs to new file

 Allow a single-letter command name in the "rebase -i" todo list.

 This may want a final reroll to avoid adding new reference to insn
 where todo is the more modern term, among other minor things.
 cf. 


* ra/prompt-eread-fix (2017-12-04) 2 commits
 - git-prompt: fix reading files with windows line endings
 - git-prompt: make __git_eread intended use explicit

 Update the shell prompt script (in contrib/) to strip trailing CR
 from strings read from various "state" files.

 Proposed log messages of both commits may need small fixes.
 cf. 
 cf. 


* ds/for-each-file-in-obj-micro-optim (2017-12-04) 1 commit
 - sha1_file: use strbuf_add() instead of strbuf_addf()

 The code to iterate over loose object files got optimized.

 Will merge to 'next'.

--
[Stalled]

* jc/merge-symlink-ours-theirs (2017-09-26) 1 commit
 - merge: teach -Xours/-Xtheirs to symbolic link merge

 "git merge -Xours/-Xtheirs" learned to use our/their version when
 resolving a conflicting updates to a symbolic link.

 Needs review.


* mg/merge-base-fork-point (2017-09-17) 3 commits
 - merge-base: find fork-point outside partial reflog
 - merge-base: return fork-point outside reflog
 - t6010: test actual test output

 "merge-base --fork-point $branch $commit" is used to guess on which
 commit among the commits that were once at the tip of the $branch the
 $commit was built on top of, and it learns these historical tips from
 the reflog of the $branch.  When the true fork-point is lost due to
 pruning of old reflog entries, the command does not give any output,
 because it has no way to guess correctly and does not want to mislead
 the user with a wrong guess.

 The command has been updated to give the best but not known to be
 correct guess, based on a hope that a merge-base between $commit and a
 virtual merge across all the reflog entries that still are available
 for $branch may still be a closer to the true fork-point than the
 merge-base between $commit and the current tip of the $branch.

 This may have to be offered by an additional option, to allow the
 users that are prepared to see a potentially incorrect guess to opt
 into the feature, without affecting the current callers that may not
 be prepared to accept a guess that is not known to be correct.

 What's the doneness of this one?


* jk/drop-ancient-curl (2017-08-09) 5 commits
 - http: #error on too-old curl
 - curl: remove ifdef'd code never used with curl >=7.19.4
 - http: drop support for curl < 7.19.4
 - http: drop support for curl < 7.16.0
 - http: drop support for curl < 7.11.1

 Some code in