Re: What's cooking in git.git (Oct 2016, #06; Mon, 24)

[Johannes Schindelin]

Hi Hannes,

On Tue, 25 Oct 2016, Johannes Sixt wrote:

> Am 25.10.2016 um 20:13 schrieb Stefan Beller:
> > On Tue, Oct 25, 2016 at 10:15 AM, Junio C Hamano  wrote:
> > >  - the "off-by-one fix" part of sb/submodule-ignore-trailing-slash
> > >needs to be in the upcoming release but the "trailing /. in base
> > >should not affect the resolution of ../relative/path" part that
> > >is still under discussion can wait.  Which means we'd need a few
> > >more !MINGW prerequisites in the tests by -rc0.
> > >[...]
> >
> > So maybe instead of adding !MINGW we rather want to apply
> > https://public-inbox.org/git/2908451e-4273-8826-8989-5572263cc...@kdbg.org/
> > instead for now?
> 
> I was about to submit this very patch again, and only then saw your message.
> So, yes, that's what I propose, too.
> 
> Dscho, does this patch fix the test failures that you observed, too?
> Unfortunately, it goes against our endeavor to reduce subshells.

I am fine with the patch, even if I did not have a chance to test it yet
(ran out of time today).

Ciao,
Dscho

Re: What's cooking in git.git (Oct 2016, #06; Mon, 24)

[Johannes Sixt]

Am 25.10.2016 um 20:13 schrieb Stefan Beller:

On Tue, Oct 25, 2016 at 10:15 AM, Junio C Hamano  wrote:

 - the "off-by-one fix" part of sb/submodule-ignore-trailing-slash
   needs to be in the upcoming release but the "trailing /. in base
   should not affect the resolution of ../relative/path" part that
   is still under discussion can wait.  Which means we'd need a few
   more !MINGW prerequisites in the tests by -rc0.
[...]


So maybe instead of adding !MINGW we rather want to apply
https://public-inbox.org/git/2908451e-4273-8826-8989-5572263cc...@kdbg.org/
instead for now?


I was about to submit this very patch again, and only then saw your 
message. So, yes, that's what I propose, too.


Dscho, does this patch fix the test failures that you observed, too? 
Unfortunately, it goes against our endeavor to reduce subshells.


-- Hannes

Re: What's cooking in git.git (Oct 2016, #06; Mon, 24)

[Junio C Hamano]

Jeff King  writes:

> On Mon, Oct 24, 2016 at 06:09:00PM -0700, Junio C Hamano wrote:
>
>>  - lt/abbrev-auto and its follow-up jk/abbrev-auto are about auto
>>scaling the default abbreviation length when Git produces a short
>>object name to adjust to the modern times.  Peff noticed one
>>fallout from it recently and its fix jc/abbrev-auto is not yet in
>>'next'.  I would not be surprised if there are other uncovered
>>fallouts remaining in the code, but at the same time, I expect
>>they are all cosmetic kind that do not affect correctness, so I
>>am inclined to include all of them in the upcoming release.
>
> Yeah, I'd agree any fallouts are likely to be purely cosmetic (and if
> there _is_ some script broken by this, it was an accident waiting to
> happen as soon as it was used in a repo with a partial hash collision).
>
> I'm still not sure if people will balk just at the increased length in
> all of their output. I think I'm finally starting to get used to it. :)

I am finally getting used to it.  At this point, I think the
transition plan would be to tell them to set core.abbrev to
whatever default they like.

>> * jc/abbrev-auto (2016-10-22) 4 commits
>>  - transport: compute summary-width dynamically
>>  - transport: allow summary-width to be computed dynamically
>>  - fetch: pass summary_width down the callchain
>>  - transport: pass summary_width down the callchain
>>  (this branch uses jk/abbrev-auto and lt/abbrev-auto.)
>> 
>>  "git push" and "git fetch" reports from what old object to what new
>>  object each ref was updated, using abbreviated refnames, and they
>>  attempt to align the columns for this and other pieces of
>>  information.  The way these codepaths compute how many display
>>  columns to allocate for the object names portion of this output has
>>  been updated to match the recent "auto scale the default
>>  abbreviation length" change.
>> 
>>  Will merge to 'next'.
>
> In case it was not obvious, I think this topic is good-to-go. And
> clearly any decision on lt/abbrev-auto should apply to this one, too. I
> notice you built it on jk/abbrev-auto, though, which is listed as
> "undecided". That's fine by me, but I think it would technically hold
> this topic hostage. You might want to adjust that before merging to
> next.

I am planning to merge both lt/* and jk/*; I should have said it
more clearly.

Thanks.

Re: What's cooking in git.git (Oct 2016, #06; Mon, 24)

[Junio C Hamano]

Stefan Beller  writes:

> Ok. The first 2 patches are in good shape for this cycle, though.

I thought both of you knew we are in agreement on that by now, but
yes, the off-by-one fix needs to be in the upcoming release.

> So maybe instead of adding !MINGW we rather want to apply
> https://public-inbox.org/git/2908451e-4273-8826-8989-5572263cc...@kdbg.org/
> instead for now?

That sounds good to me.

The "/." thing we would want to come to agreement during the
upcoming feature freeze and it would be very good if we can push the
result out early in the next cycle, but I feel that it is premature
for the upcoming release.

Thanks.

Re: What's cooking in git.git (Oct 2016, #06; Mon, 24)

[Jeff King]

On Mon, Oct 24, 2016 at 06:09:00PM -0700, Junio C Hamano wrote:

>  - lt/abbrev-auto and its follow-up jk/abbrev-auto are about auto
>scaling the default abbreviation length when Git produces a short
>object name to adjust to the modern times.  Peff noticed one
>fallout from it recently and its fix jc/abbrev-auto is not yet in
>'next'.  I would not be surprised if there are other uncovered
>fallouts remaining in the code, but at the same time, I expect
>they are all cosmetic kind that do not affect correctness, so I
>am inclined to include all of them in the upcoming release.

Yeah, I'd agree any fallouts are likely to be purely cosmetic (and if
there _is_ some script broken by this, it was an accident waiting to
happen as soon as it was used in a repo with a partial hash collision).

I'm still not sure if people will balk just at the increased length in
all of their output. I think I'm finally starting to get used to it. :)

> * jc/abbrev-auto (2016-10-22) 4 commits
>  - transport: compute summary-width dynamically
>  - transport: allow summary-width to be computed dynamically
>  - fetch: pass summary_width down the callchain
>  - transport: pass summary_width down the callchain
>  (this branch uses jk/abbrev-auto and lt/abbrev-auto.)
> 
>  "git push" and "git fetch" reports from what old object to what new
>  object each ref was updated, using abbreviated refnames, and they
>  attempt to align the columns for this and other pieces of
>  information.  The way these codepaths compute how many display
>  columns to allocate for the object names portion of this output has
>  been updated to match the recent "auto scale the default
>  abbreviation length" change.
> 
>  Will merge to 'next'.

In case it was not obvious, I think this topic is good-to-go. And
clearly any decision on lt/abbrev-auto should apply to this one, too. I
notice you built it on jk/abbrev-auto, though, which is listed as
"undecided". That's fine by me, but I think it would technically hold
this topic hostage. You might want to adjust that before merging to
next.

-Peff

Re: What's cooking in git.git (Oct 2016, #06; Mon, 24)

[Stefan Beller]

On Tue, Oct 25, 2016 at 10:15 AM, Junio C Hamano  wrote:
> Stefan Beller  writes:
>
>> One of the initial ways to work around the bugfix was to
>>
>> git clone . root # <- add in this step and it works again.
>> git clone root super
>>
>> but instead I will do the preparation for the 'super' project not
>> in '.' but in 'root', just called differently ("super_remote" ?)
>>
>> An additional new test for cloning from '.' will be introduced, too.
>>
>> I plan on working on that with highest priority for git after finishing
>> some attr stuff that I currently have open. So expect a patch (or two)
>> this week.
>
> Hmph, I personally would prefer to defer the "correct behaviour for
> /." part for the next cycle, which is why I wrote:

Ok. The first 2 patches are in good shape for this cycle, though.
And the /. thing will wait until next cycle then, i.e. I can drop priority
as I wish

>
>  - the "off-by-one fix" part of sb/submodule-ignore-trailing-slash
>needs to be in the upcoming release but the "trailing /. in base
>should not affect the resolution of ../relative/path" part that
>is still under discussion can wait.  Which means we'd need a few
>more !MINGW prerequisites in the tests by -rc0.
>
> at the beginning of the message you are responding to, and I also
> thought that was consistent and in agreement with what you said
> earlier in 
> 
>
>> On Sat, Oct 22, 2016 at 10:11 AM, Junio C Hamano  wrote:
>>
>> >
>> > There isn't enough time to include this topic in the upcoming
>> > release within the current https://tinyurl.com/gitCal calendar,
>> > however, which places the final on Nov 11th.
>> >
>> > I am wondering if it makes sense to delay 2.11 by moving the final
>> > by 4 weeks to Dec 9th.
>> >
>> > Thoughts?
>> >
>> > Speaking of what to and not to include in the upcoming release, we
>> > do want to include Stefan's off-by-one fix to the submodule-helper,
>> > but that is blocked on Windows end due to the test.
>>
>> I'd be happy either way, i.e. we could revert that fix and make a release?
>> AFAICT, Windows only has broken tests, not broken functionality with that
>> submodule bug fix.
>
> to which I responded in 

and you said:
> It of course needs help from
> Windows folks to validate the results.

So maybe instead of adding !MINGW we rather want to apply
https://public-inbox.org/git/2908451e-4273-8826-8989-5572263cc...@kdbg.org/
instead for now?

Re: What's cooking in git.git (Oct 2016, #06; Mon, 24)

[Junio C Hamano]

Stefan Beller  writes:

> One of the initial ways to work around the bugfix was to
>
> git clone . root # <- add in this step and it works again.
> git clone root super
>
> but instead I will do the preparation for the 'super' project not
> in '.' but in 'root', just called differently ("super_remote" ?)
>
> An additional new test for cloning from '.' will be introduced, too.
>
> I plan on working on that with highest priority for git after finishing
> some attr stuff that I currently have open. So expect a patch (or two)
> this week.

Hmph, I personally would prefer to defer the "correct behaviour for
/." part for the next cycle, which is why I wrote:

 - the "off-by-one fix" part of sb/submodule-ignore-trailing-slash
   needs to be in the upcoming release but the "trailing /. in base
   should not affect the resolution of ../relative/path" part that
   is still under discussion can wait.  Which means we'd need a few
   more !MINGW prerequisites in the tests by -rc0.

at the beginning of the message you are responding to, and I also
thought that was consistent and in agreement with what you said
earlier in 

> On Sat, Oct 22, 2016 at 10:11 AM, Junio C Hamano  wrote:
> 
> >
> > There isn't enough time to include this topic in the upcoming
> > release within the current https://tinyurl.com/gitCal calendar,
> > however, which places the final on Nov 11th.
> >
> > I am wondering if it makes sense to delay 2.11 by moving the final
> > by 4 weeks to Dec 9th.
> >
> > Thoughts?
> >
> > Speaking of what to and not to include in the upcoming release, we
> > do want to include Stefan's off-by-one fix to the submodule-helper,
> > but that is blocked on Windows end due to the test.
> 
> I'd be happy either way, i.e. we could revert that fix and make a release?
> AFAICT, Windows only has broken tests, not broken functionality with that
> submodule bug fix.

to which I responded in 

> If you are referring the "trailing /. should not make difference
> when resolving ../relative/path" change with "rever that fix", I
> think that may be a reasonable way to proceed.  Even though that
> change is a bugfix (at least from the point of view by me and j6t in
> the recent discussion), it is a behaviour change that we would want
> to see feedback from existing submodule users and deserves a longer
> gestation period.  And that part is not yet in 'next' yet ;-)
> 
> > If we want a longer gestation period, we'd ideally merge it to master
> > just after a release, such that we "cook" it in master without having
> > it in any release (we had a similar discussion for the diff heuristics 
> > IIRC).
> 
> Yes.  
> 
> It would mean that we would need a separate patch that adds the
> !MINGW prerequisite to some tests to what is on 'next', as the early
> patches on sb/submodule-ignore-trailing-slash~ that fixes off-by-one
> is the right thing to do either way.  It of course needs help from
> Windows folks to validate the results.

So...

Re: What's cooking in git.git (Oct 2016, #06; Mon, 24)

[Stefan Beller]

On Mon, Oct 24, 2016 at 6:09 PM, Junio C Hamano  wrote:
>
> * sb/submodule-ignore-trailing-slash (2016-10-18) 3 commits
>  . submodule--helper: normalize funny urls
>   (merged to 'next' on 2016-10-11 at e37425ed17)
>  + submodule: ignore trailing slash in relative url
>  + submodule: ignore trailing slash on superproject URL
>
>  A minor regression fix for "git submodule".
>
>  It seems that POSIX emulation layer of Windows is not cooperating;
>  this may have to wait (or tentatively reverted in Windows port) for
>  the resolution of the issue.
>
>  cf. 
>  cf. 
>
>  What's the current state of this topic?

The first 2 patches actually fix a bug users run into, and I these are
fine for general consumption IMHO.

The third patch only breaks tests as our test suite is holding it wrong.
I was bike shedding on the list and yak shaving here to come up with
the correct fix for the test suite.

One of the initial ways to work around the bugfix was to

git clone . root # <- add in this step and it works again.
git clone root super

but instead I will do the preparation for the 'super' project not
in '.' but in 'root', just called differently ("super_remote" ?)

An additional new test for cloning from '.' will be introduced, too.

I plan on working on that with highest priority for git after finishing
some attr stuff that I currently have open. So expect a patch (or two)
this week.

Thanks,
Stefan

What's cooking in git.git (Oct 2016, #06; Mon, 24)

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

Originally I planed to start concluding this cycle today, but
waiting for the conclusion of a few test breakages on Windows, I
didn't tag -rc0 today.

Here are my current thinking on the notable topics.

 - the "off-by-one fix" part of sb/submodule-ignore-trailing-slash
   needs to be in the upcoming release but the "trailing /. in base
   should not affect the resolution of ../relative/path" part that
   is still under discussion can wait.  Which means we'd need a few
   more !MINGW prerequisites in the tests by -rc0.

 - js/prepare-sequencer topic is not yet in 'next' but it would be a
   nice-to-have in the upcoming release if we can.  It does not yet
   touch "rebase -i", but does touch the sequencer code that is used
   in cherry-pick and revert, so I'd prefer to cook it for at least
   a week and half in 'next' before merging.

 - ls/filter-process topic has been in 'next' with one known test
   breakage on Windows, whose resolution ls/git-open-cloexec is
   close to its final shape.  Perhaps we can cook them for at least
   a week and half in 'next' and have it in the upcoming release.

 - ex/deprecate-empty-pathspec-as-match-all topic that makes it
   illegal to say 'git add ""' when you mean 'git add .' has been in
   'next' for more than a cycle.  I am inclined to merge it in the
   upcoming release.

 - jc/merge-drop-old-syntax is relatively new in 'next' after all
   known in-tree dependents have been updated.  I am planning to
   keep it cooking in 'next' but add a backward incompatibility
   notice to the release notes to the upcoming release.

 - lt/abbrev-auto and its follow-up jk/abbrev-auto are about auto
   scaling the default abbreviation length when Git produces a short
   object name to adjust to the modern times.  Peff noticed one
   fallout from it recently and its fix jc/abbrev-auto is not yet in
   'next'.  I would not be surprised if there are other uncovered
   fallouts remaining in the code, but at the same time, I expect
   they are all cosmetic kind that do not affect correctness, so I
   am inclined to include all of them in the upcoming release.

I plan to merge other smallish topics that have been in 'next' to
'master' soonish, and relabel the remainder that have been labeled
as "Will merge to 'master'" to "Will hold" and keep cooking them in
'next'.  For this reason, please do not take the "Will merge to
'master'" label too literally in this issue of "What's cooking"
report.  It is always true that the label only means "the topic will
be in 'master' eventually", not "the topic will be in the upcoming
release", but in this issue that is even more true than usual.

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]

* jk/tap-verbose-fix (2016-10-24) 4 commits
  (merged to 'next' on 2016-10-24 at 5073a4de2d)
 + test-lib: bail out when "-v" used under "prove"
  (merged to 'next' on 2016-10-21 at 592679411c)
 + travis: use --verbose-log test option
 + test-lib: add --verbose-log option
 + test-lib: handle TEST_OUTPUT_DIRECTORY with spaces

 The Travis CI configuration we ship ran the tests with --verbose
 option but this risks non-TAP output that happens to be "ok" to be
 misinterpreted as TAP signalling a test that passed.  This resulted
 in unnecessary failure.  This has been corrected by introducing a
 new mode to run our tests in the test harness to send the verbose
 output separately to the log file.

 Will merge to 'master'.


* po/fix-doc-merge-base-illustration (2016-10-21) 1 commit
  (merged to 'next' on 2016-10-21 at ac6f04a6c5)
 + doc: fix merge-base ASCII art tab spacing

 Some AsciiDoc formatter mishandles a displayed illustration with
 tabs in it.  Adjust a few of them in merge-base documentation to
 work around them.

 Will merge to 'master'.


* jc/abbrev-auto (2016-10-22) 4 commits
 - transport: compute summary-width dynamically
 - transport: allow summary-width to be computed dynamically
 - fetch: pass summary_width down the callchain
 - transport: pass summary_width down the callchain
 (this branch uses jk/abbrev-auto and lt/abbrev-auto.)

 "git push" and "git fetch" reports from what old object to what new
 object each ref was updated, using abbreviated refnames, and they
 attempt to align the columns for this and other pieces of
 information.  The way these codepaths compute how many display
 columns to allocate for the object names portion of this output has
 been updated to match the recent "auto scale the default
 abbreviation length" change.

 Will merge to 'next'.


* jc/reset-unmerge (2016-10-24) 1 commit
 - reset: