Re: What's cooking in git.git (Aug 2016, #08; Wed, 24)

2016-08-31 Thread Jacob Keller
On Tue, Aug 30, 2016 at 10:10 PM, Stefan Beller  wrote:
>>
>> * sb/submodule-clone-rr (2016-08-17) 8 commits
>>  - clone: recursive and reference option triggers submodule alternates
>>  - clone: implement optional references
>>  - clone: clarify option_reference as required
>>  - clone: factor out checking for an alternate path
>>  - submodule--helper update-clone: allow multiple references
>>  - submodule--helper module-clone: allow multiple references
>>  - t7408: merge short tests, factor out testing method
>>  - t7408: modernize style
>>
>>  I spotted a last-minute bug in v5, which is not a very good sign
>>  (it shows that nobody is reviewing).  Any more comments?
>>
>>
>
> Jacob Keller reviewed that series as announced in
>
> https://public-inbox.org/git/CA+P7+xpE=GoFWfdzmT+k=zku8+yjeh-aomsfutjjjwfha1h...@mail.gmail.com/#t
>
> and concluded it is fine as in
>
> https://public-inbox.org/git/ca+p7+xrokr0zgidqfuvpn+-j_wdjkauropcnpgvjzhafc12...@mail.gmail.com/
>
> Thanks,
> Stefan

Yep.

Thanks,
Jake


Re: What's cooking in git.git (Aug 2016, #08; Wed, 24)

2016-08-30 Thread Stefan Beller
>
> * sb/submodule-clone-rr (2016-08-17) 8 commits
>  - clone: recursive and reference option triggers submodule alternates
>  - clone: implement optional references
>  - clone: clarify option_reference as required
>  - clone: factor out checking for an alternate path
>  - submodule--helper update-clone: allow multiple references
>  - submodule--helper module-clone: allow multiple references
>  - t7408: merge short tests, factor out testing method
>  - t7408: modernize style
>
>  I spotted a last-minute bug in v5, which is not a very good sign
>  (it shows that nobody is reviewing).  Any more comments?
>
>

Jacob Keller reviewed that series as announced in

https://public-inbox.org/git/CA+P7+xpE=GoFWfdzmT+k=zku8+yjeh-aomsfutjjjwfha1h...@mail.gmail.com/#t

and concluded it is fine as in

https://public-inbox.org/git/ca+p7+xrokr0zgidqfuvpn+-j_wdjkauropcnpgvjzhafc12...@mail.gmail.com/

Thanks,
Stefan


Re: What's cooking in git.git (Aug 2016, #08; Wed, 24)

2016-08-26 Thread Junio C Hamano
Johannes Schindelin  writes:

> On Wed, 24 Aug 2016, Junio C Hamano wrote:
>
>> * rt/help-unknown (2016-08-18) 2 commits
>>  - help: make option --help open man pages only for Git commands
>>  - help: introduce option --command-only
>> 
>>  "git nosuchcommand --help" said "No manual entry for gitnosuchcommand",
>>  which was not intuitive, given that "git nosuchcommand" said "git:
>>  'nosuchcommand' is not a git command".
>> 
>>  Waiting for the review discussion to settle.
>
> Not only that. For a week now, two of my build jobs have been failing (the
> one testing `pu` verbatim and the one testing Git for Windows' patches
> rebased on top of `pu`) because the test does not actually test what was
> just built, but relies on the Git man pages to be installed.
>
> So it needs more than just the review discussion to settle.

Ah, sorry for being inaccurate.

A topic may not be ready to be merged down to the next integration
branch before being re-rolled.  I say "Waiting for a reroll" when I
saw review comments and responses have produced enough material to
go into a reroll and the ball is in the submitter's court.  While
the review is still ongoing, I just label it differently to as a
reminder to myself that it is premature for me to jump up and down
and demand "Can we have a reroll pretty-please now?"  This was in
that latter kind when I labelled it.

I think the reviews on the topic has settled and I should have
marked it as "Waiting for a reroll", but during the prerelease
period, I do not have time to pay too much attention on things
outside 'master' and fix-up topics that are moving through 'next'
to 'master' aiming to become part of the upcoming release, so the
marking was left behind [*1*].  My bad.


[Footnotes]

*1* It follows that it would not be unusual if the tip of 'pu' does
not even build during the time.  Being able to test it does not
contribute much to catching the remaining bug in the release
candidates and I'd really like to see all of us paying more
attention to the tip of 'master'.  A statement "With topic X
that is still in 'next', A works" is not all that interesting
unless it is accompanied by "And A used to work in the previous
release, but broken in 'master'." at this point in a development
cycle.


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: What's cooking in git.git (Aug 2016, #08; Wed, 24)

2016-08-26 Thread Johannes Schindelin
Hi Junio,

On Wed, 24 Aug 2016, Junio C Hamano wrote:

> * rt/help-unknown (2016-08-18) 2 commits
>  - help: make option --help open man pages only for Git commands
>  - help: introduce option --command-only
> 
>  "git nosuchcommand --help" said "No manual entry for gitnosuchcommand",
>  which was not intuitive, given that "git nosuchcommand" said "git:
>  'nosuchcommand' is not a git command".
> 
>  Waiting for the review discussion to settle.

Not only that. For a week now, two of my build jobs have been failing (the
one testing `pu` verbatim and the one testing Git for Windows' patches
rebased on top of `pu`) because the test does not actually test what was
just built, but relies on the Git man pages to be installed.

So it needs more than just the review discussion to settle.

Ciao,
Dscho
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: What's cooking in git.git (Aug 2016, #08; Wed, 24)

2016-08-24 Thread Junio C Hamano
Jeff King  writes:

> On Wed, Aug 24, 2016 at 02:16:02PM -0700, Junio C Hamano wrote:
>
>> * jk/pack-objects-optim-mru (2016-08-11) 4 commits
>>   (merged to 'next' on 2016-08-11 at c0a7dae)
>>  + pack-objects: use mru list when iterating over packs
>>  + pack-objects: break delta cycles before delta-search phase
>>  + sha1_file: make packed_object_info public
>>  + provide an initializer for "struct object_info"
>> 
>>  "git pack-objects" in a repository with many packfiles used to
>>  spend a lot of time looking for/at objects in them; the accesses to
>>  the packfiles are now optimized by checking the most-recently-used
>>  packfile first.
>> 
>>  Will hold to see if people scream.
>
> Just a note that we've been running with this at GitHub on all of our
> servers for a bit over a week, and no screaming yet. That's not
> necessarily proof of anything, but it does make the audience of "people"
> a bit bigger than just "next", as we run quite a few invocations of
> pack-objects in a day.
>
> I don't think that changes anything in the near future, since this is
> obviously not for v2.10, but barring any complaints, it's probably a
> reasonable topic to consider for the version after (and of course I'll
> relay any issues we come across on our servers).

Yeah, that "Will hold" is primarily me being lazy [*1*] during the
-rc period when updating the "What's cooking".  After following the
"break delta cycles" patch carefully, I am no longer worried about
this topic.  It should be in 'master' early in the next cycle, among
other topics that are competently done.

> I'm planning to deploy the delta-cache topic soon, too, so that should
> give it some good exercise.

Good.  Thanks.


[Footnote]

*1* ... and a bit more careful, as any "Will merge to 'next'" thing
gets marked as "Will merge to 'master'" by default and having any
entry under "Will merge to 'master'" in "Meta/cook -w" report tempts
me to merge them even during -rc period.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: What's cooking in git.git (Aug 2016, #08; Wed, 24)

2016-08-24 Thread Jeff King
On Wed, Aug 24, 2016 at 02:16:02PM -0700, Junio C Hamano wrote:

> * jk/pack-objects-optim-mru (2016-08-11) 4 commits
>   (merged to 'next' on 2016-08-11 at c0a7dae)
>  + pack-objects: use mru list when iterating over packs
>  + pack-objects: break delta cycles before delta-search phase
>  + sha1_file: make packed_object_info public
>  + provide an initializer for "struct object_info"
> 
>  "git pack-objects" in a repository with many packfiles used to
>  spend a lot of time looking for/at objects in them; the accesses to
>  the packfiles are now optimized by checking the most-recently-used
>  packfile first.
> 
>  Will hold to see if people scream.

Just a note that we've been running with this at GitHub on all of our
servers for a bit over a week, and no screaming yet. That's not
necessarily proof of anything, but it does make the audience of "people"
a bit bigger than just "next", as we run quite a few invocations of
pack-objects in a day.

I don't think that changes anything in the near future, since this is
obviously not for v2.10, but barring any complaints, it's probably a
reasonable topic to consider for the version after (and of course I'll
relay any issues we come across on our servers).

I'm planning to deploy the delta-cache topic soon, too, so that should
give it some good exercise.

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html