* Re: What's cooking in git.git (Sep 2021, #02; Wed, 8)
2021-09-08 15:38 What's cooking in git.git (Sep 2021, #02; Wed, 8) Junio C Hamano
@ 2021-09-08 16:24 ` Taylor Blau
2021-09-08 19:23 ` Junio C Hamano
2021-09-08 21:27 ` Jeff King
2021-09-08 16:55 ` Azeem Bande-Ali
` (11 subsequent siblings)
12 siblings, 2 replies; 25+ messages in thread
From: Taylor Blau @ 2021-09-08 16:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Wed, Sep 08, 2021 at 08:38:55AM -0700, Junio C Hamano wrote:
> * tb/pack-finalize-ordering (2021-09-07) 2 commits
> - builtin/repack.c: move `.idx` files into place last
> - pack-write.c: rename `.idx` file into place last
>
> The order in which various files that make up a single (conceptual)
> packfile has been reevaluated and straightened up. This matters in
> correctness, as an incomplete set of files must not be shown to a
> running Git.
>
> Will merge to 'next'?
Ævar has a series [1] that complements this one nicely, so I would be
happy to see them both queued.
I had some suggestions inline, but I don't feel strongly about whether
or not they are implemented.
Thanks,
Taylor
[1]: https://lore.kernel.org/git/cover-v2-0.4-0000000000-20210908T003631Z-avarab@gmail.com/
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: What's cooking in git.git (Sep 2021, #02; Wed, 8)
2021-09-08 16:24 ` Taylor Blau
@ 2021-09-08 19:23 ` Junio C Hamano
2021-09-09 1:02 ` Taylor Blau
2021-09-08 21:27 ` Jeff King
1 sibling, 1 reply; 25+ messages in thread
From: Junio C Hamano @ 2021-09-08 19:23 UTC (permalink / raw)
To: Taylor Blau; +Cc: git
Taylor Blau <me@ttaylorr.com> writes:
> On Wed, Sep 08, 2021 at 08:38:55AM -0700, Junio C Hamano wrote:
>> * tb/pack-finalize-ordering (2021-09-07) 2 commits
>> - builtin/repack.c: move `.idx` files into place last
>> - pack-write.c: rename `.idx` file into place last
>>
>> The order in which various files that make up a single (conceptual)
>> packfile has been reevaluated and straightened up. This matters in
>> correctness, as an incomplete set of files must not be shown to a
>> running Git.
>>
>> Will merge to 'next'?
>
> Ævar has a series [1] that complements this one nicely, so I would be
> happy to see them both queued.
>
> I had some suggestions inline, but I don't feel strongly about whether
> or not they are implemented.
I hate to see multiple folks "competing" in the overlapping area,
each getting reviews and responding or not responding at their own
pace. That would force me to keep track of which one is which and
what their doneness are independently.
Do you mind if I nominate you the team leader to come up with a
single series that is polished to be mergeable to 'next'?
Thanks.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: What's cooking in git.git (Sep 2021, #02; Wed, 8)
2021-09-08 19:23 ` Junio C Hamano
@ 2021-09-09 1:02 ` Taylor Blau
0 siblings, 0 replies; 25+ messages in thread
From: Taylor Blau @ 2021-09-09 1:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Taylor Blau, git
On Wed, Sep 08, 2021 at 12:23:57PM -0700, Junio C Hamano wrote:
> Taylor Blau <me@ttaylorr.com> writes:
>
> > On Wed, Sep 08, 2021 at 08:38:55AM -0700, Junio C Hamano wrote:
> >> * tb/pack-finalize-ordering (2021-09-07) 2 commits
> >> - builtin/repack.c: move `.idx` files into place last
> >> - pack-write.c: rename `.idx` file into place last
> >>
> >> The order in which various files that make up a single (conceptual)
> >> packfile has been reevaluated and straightened up. This matters in
> >> correctness, as an incomplete set of files must not be shown to a
> >> running Git.
> >>
> >> Will merge to 'next'?
> >
> > Ævar has a series [1] that complements this one nicely, so I would be
> > happy to see them both queued.
> >
> > I had some suggestions inline, but I don't feel strongly about whether
> > or not they are implemented.
>
> I hate to see multiple folks "competing" in the overlapping area,
> each getting reviews and responding or not responding at their own
> pace. That would force me to keep track of which one is which and
> what their doneness are independently.
>
> Do you mind if I nominate you the team leader to come up with a
> single series that is polished to be mergeable to 'next'?
Not at all; sorry that I missed your email before submitting a v2 of the
earlier series.
Ævar seems to have combined them while I was eating dinner, but I'll
coordinate with him and send out a unified result for you to queue up.
Thanks,
Taylor
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: What's cooking in git.git (Sep 2021, #02; Wed, 8)
2021-09-08 16:24 ` Taylor Blau
2021-09-08 19:23 ` Junio C Hamano
@ 2021-09-08 21:27 ` Jeff King
1 sibling, 0 replies; 25+ messages in thread
From: Jeff King @ 2021-09-08 21:27 UTC (permalink / raw)
To: Taylor Blau; +Cc: Junio C Hamano, git
On Wed, Sep 08, 2021 at 12:24:09PM -0400, Taylor Blau wrote:
> On Wed, Sep 08, 2021 at 08:38:55AM -0700, Junio C Hamano wrote:
> > * tb/pack-finalize-ordering (2021-09-07) 2 commits
> > - builtin/repack.c: move `.idx` files into place last
> > - pack-write.c: rename `.idx` file into place last
> >
> > The order in which various files that make up a single (conceptual)
> > packfile has been reevaluated and straightened up. This matters in
> > correctness, as an incomplete set of files must not be shown to a
> > running Git.
> >
> > Will merge to 'next'?
>
> Ævar has a series [1] that complements this one nicely, so I would be
> happy to see them both queued.
>
> I had some suggestions inline, but I don't feel strongly about whether
> or not they are implemented.
I think regardless of Ævar's related patches, we'd want to see a re-roll
of yours that touches index-pack's final(), too.
-Peff
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: What's cooking in git.git (Sep 2021, #02; Wed, 8)
2021-09-08 15:38 What's cooking in git.git (Sep 2021, #02; Wed, 8) Junio C Hamano
2021-09-08 16:24 ` Taylor Blau
@ 2021-09-08 16:55 ` Azeem Bande-Ali
2021-09-08 19:20 ` Junio C Hamano
2021-09-08 17:50 ` Philippe Blain
` (10 subsequent siblings)
12 siblings, 1 reply; 25+ messages in thread
From: Azeem Bande-Ali @ 2021-09-08 16:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Wed, Sep 8, 2021 at 11:39 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> * ab/help-autocorrect-prompt (2021-08-14) 1 commit
> - help.c: help.autocorrect=prompt waits for user action
>
> The logic for auto-correction of misspelt subcommands learned to go
> interactive when the help.autocorrect configuration variable is set
> to true.
>
> Will merge to 'next'.
Just a minor issue with the description: help.autocorrect will have to
be set to "prompt" for this setting to work.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: What's cooking in git.git (Sep 2021, #02; Wed, 8)
2021-09-08 16:55 ` Azeem Bande-Ali
@ 2021-09-08 19:20 ` Junio C Hamano
0 siblings, 0 replies; 25+ messages in thread
From: Junio C Hamano @ 2021-09-08 19:20 UTC (permalink / raw)
To: Azeem Bande-Ali; +Cc: git
Azeem Bande-Ali <me@azeemba.com> writes:
> On Wed, Sep 8, 2021 at 11:39 AM Junio C Hamano <gitster@pobox.com> wrote:
>>
>> * ab/help-autocorrect-prompt (2021-08-14) 1 commit
>> - help.c: help.autocorrect=prompt waits for user action
>>
>> The logic for auto-correction of misspelt subcommands learned to go
>> interactive when the help.autocorrect configuration variable is set
>> to true.
>>
>> Will merge to 'next'.
>
> Just a minor issue with the description: help.autocorrect will have to
> be set to "prompt" for this setting to work.
I think this was already pointed out in an earlier edition of the
What's cooking report, but I simply forgot to update it.
Sorry, and thanks.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: What's cooking in git.git (Sep 2021, #02; Wed, 8)
2021-09-08 15:38 What's cooking in git.git (Sep 2021, #02; Wed, 8) Junio C Hamano
2021-09-08 16:24 ` Taylor Blau
2021-09-08 16:55 ` Azeem Bande-Ali
@ 2021-09-08 17:50 ` Philippe Blain
2021-09-08 21:57 ` Derrick Stolee
` (9 subsequent siblings)
12 siblings, 0 replies; 25+ messages in thread
From: Philippe Blain @ 2021-09-08 17:50 UTC (permalink / raw)
To: Junio C Hamano, git
Hi Junio,
Le 2021-09-08 à 11:38, Junio C Hamano a écrit :
>
> * pb/test-use-user-env (2021-09-07) 3 commits
> - test-lib-functions: keep user's debugger config files and TERM in 'debug'
> - test-lib-functions: optionally keep HOME, TERM and SHELL in 'test_pause'
> - test-lib-functions: use 'TEST_SHELL_PATH' in 'test_pause'
>
> Teach test_pause and test_debug to allow using the HOME and TERM
> environment variables the user usually uses.
The name of the debug helper is 'debug', not 'test_debug' ;)
Also, technically with my v5 'debug' does not use the full $HOME but
just $HOME/.[g|ll]dbinit, but for this merge message I guess it does
not matter much, and I don't have anything better to propose :)
>
> Will merge to 'next'?
>
From my part I think it's ready, I think I've adressed all feedback.
Thanks,
Philippe.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: What's cooking in git.git (Sep 2021, #02; Wed, 8)
2021-09-08 15:38 What's cooking in git.git (Sep 2021, #02; Wed, 8) Junio C Hamano
` (2 preceding siblings ...)
2021-09-08 17:50 ` Philippe Blain
@ 2021-09-08 21:57 ` Derrick Stolee
2021-09-09 14:23 ` Elijah Newren
2021-09-09 2:59 ` Ramsay Jones
` (8 subsequent siblings)
12 siblings, 1 reply; 25+ messages in thread
From: Derrick Stolee @ 2021-09-08 21:57 UTC (permalink / raw)
To: Junio C Hamano, git, Elijah Newren
On 9/8/2021 11:38 AM, Junio C Hamano wrote:> * ds/sparse-index-ignored-files (2021-09-07) 10 commits
> - sparse-checkout: clear tracked sparse dirs
> - sparse-index: add SPARSE_INDEX_MEMORY_ONLY flag
> - attr: be careful about sparse directories
> - sparse-checkout: create helper methods
> - sparse-index: use WRITE_TREE_MISSING_OK
> - sparse-index: silently return when cache tree fails
> - unpack-trees: fix nested sparse-dir search
> - sparse-index: silently return when not using cone-mode patterns
> - t7519: rewrite sparse index test
> - Merge branch 'ds/add-with-sparse-index' into ds/sparse-index-ignored-files
> (this branch is used by sg/test-split-index-fix.)
>
> In cone mode, the sparse-index codepath learned to remove ignored
> files (like build artifacts) outside the sparse cone, allowing the
> entire directory outside the sparse cone to be removed, which is
> especially useful when the sparse patterns change.
>
> Will merge to 'next'?
I think this one is ready to go. Elijah chimed in on the latest
version, too.
This also means that perhaps we could start tracking the sparse
index integrations with merge, rebase, cherry-pick, and revert [1]?
This series has also had quite a bit of review, but the latest
version has not had an ack.
[1] https://lore.kernel.org/git/pull.1019.v3.git.1631100241.gitgitgadget@gmail.com
I also plan to send a new version of the --sparse RFC [2], which
is based on [1]. I don't want to get too far ahead of what the
community has capacity to review.
[2] https://lore.kernel.org/git/pull.1018.git.1629842085.gitgitgadget@gmail.com/
Thanks,
-Stolee
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: What's cooking in git.git (Sep 2021, #02; Wed, 8)
2021-09-08 21:57 ` Derrick Stolee
@ 2021-09-09 14:23 ` Elijah Newren
0 siblings, 0 replies; 25+ messages in thread
From: Elijah Newren @ 2021-09-09 14:23 UTC (permalink / raw)
To: Derrick Stolee; +Cc: Junio C Hamano, Git Mailing List
On Wed, Sep 8, 2021 at 2:57 PM Derrick Stolee <stolee@gmail.com> wrote:
>
> On 9/8/2021 11:38 AM, Junio C Hamano wrote:> * ds/sparse-index-ignored-files (2021-09-07) 10 commits
> > - sparse-checkout: clear tracked sparse dirs
> > - sparse-index: add SPARSE_INDEX_MEMORY_ONLY flag
> > - attr: be careful about sparse directories
> > - sparse-checkout: create helper methods
> > - sparse-index: use WRITE_TREE_MISSING_OK
> > - sparse-index: silently return when cache tree fails
> > - unpack-trees: fix nested sparse-dir search
> > - sparse-index: silently return when not using cone-mode patterns
> > - t7519: rewrite sparse index test
> > - Merge branch 'ds/add-with-sparse-index' into ds/sparse-index-ignored-files
> > (this branch is used by sg/test-split-index-fix.)
> >
> > In cone mode, the sparse-index codepath learned to remove ignored
> > files (like build artifacts) outside the sparse cone, allowing the
> > entire directory outside the sparse cone to be removed, which is
> > especially useful when the sparse patterns change.
> >
> > Will merge to 'next'?
>
> I think this one is ready to go. Elijah chimed in on the latest
> version, too.
Yep, looks good to me.
> This also means that perhaps we could start tracking the sparse
> index integrations with merge, rebase, cherry-pick, and revert [1]?
> This series has also had quite a bit of review, but the latest
> version has not had an ack.
>
> [1] https://lore.kernel.org/git/pull.1019.v3.git.1631100241.gitgitgadget@gmail.com
v2 was already nearly ready to go, with just some very minor comments
and questions. Your email responses to individual patches explained
most of the remaining bits, leaving just the typo, which you corrected
in v3. So, I went ahead and put my Reviewed-by on it.
If this series had been picked up by Junio and listed in the "What's
cooking" email, I'd suggest it was also ready for next.
> I also plan to send a new version of the --sparse RFC [2], which
> is based on [1]. I don't want to get too far ahead of what the
> community has capacity to review.
>
> [2] https://lore.kernel.org/git/pull.1018.git.1629842085.gitgitgadget@gmail.com/
Sorry for not responding. I found a simple typo but wanted to have
something more to say than just that. I was happy with what looked
like the high level direction, and then noticed that Matheus was
giving you lots of good comments and he understood some of the details
better than me. I'll try to find some time to review when you send
the re-roll.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: What's cooking in git.git (Sep 2021, #02; Wed, 8)
2021-09-08 15:38 What's cooking in git.git (Sep 2021, #02; Wed, 8) Junio C Hamano
` (3 preceding siblings ...)
2021-09-08 21:57 ` Derrick Stolee
@ 2021-09-09 2:59 ` Ramsay Jones
2021-09-09 17:45 ` Junio C Hamano
2021-09-09 11:03 ` js/scalar, was " Johannes Schindelin
` (7 subsequent siblings)
12 siblings, 1 reply; 25+ messages in thread
From: Ramsay Jones @ 2021-09-09 2:59 UTC (permalink / raw)
To: Junio C Hamano, git
On 08/09/2021 16:38, Junio C Hamano wrote:
test t5319-multi-pack-index.sh on 'seen' has been failing for
several days, so I had a quick look tonight. This issue relates
to the following two topics:
> * jb/midx-revindex-fix (2021-08-23) 1 commit
> - multi-pack-index: fix *.rev cleanups with --object-dir
>
> An implementation in "multi-pack-index write" that takes object
> directory inconsistently used that and the object store of the
> default repository, causing segfaults and possibly corrupting
> repositories.
>
> On hold.
> cf. <xmqqo89jbf49.fsf@gitster.g>
>
...
> * tb/multi-pack-bitmaps (2021-09-01) 27 commits
> - p5326: perf tests for MIDX bitmaps
> - p5310: extract full and partial bitmap tests
> - midx: respect 'GIT_TEST_MULTI_PACK_INDEX_WRITE_BITMAP'
> - t7700: update to work with MIDX bitmap test knob
> - t5319: don't write MIDX bitmaps in t5319
> - t5310: disable GIT_TEST_MULTI_PACK_INDEX_WRITE_BITMAP
> - t0410: disable GIT_TEST_MULTI_PACK_INDEX_WRITE_BITMAP
> - t5326: test multi-pack bitmap behavior
> - t/helper/test-read-midx.c: add --checksum mode
> - t5310: move some tests to lib-bitmap.sh
> - pack-bitmap: write multi-pack bitmaps
> - pack-bitmap: read multi-pack bitmaps
> - pack-bitmap.c: avoid redundant calls to try_partial_reuse
> - pack-bitmap.c: introduce 'bitmap_is_preferred_refname()'
> - pack-bitmap.c: introduce 'nth_bitmap_object_oid()'
> - pack-bitmap.c: introduce 'bitmap_num_objects()'
> - midx: avoid opening multiple MIDXs when writing
> - midx: close linked MIDXs, avoid leaking memory
> - midx: infer preferred pack when not given one
> - midx: reject empty `--preferred-pack`'s
> - midx: clear auxiliary .rev after replacing the MIDX
> - midx: fix `*.rev` cleanups with `--object-dir`
> - midx: disallow running outside of a repository
> - Documentation: describe MIDX-based bitmaps
> - pack-bitmap-write.c: free existing bitmaps
> - pack-bitmap-write.c: gracefully fail to write non-closed bitmaps
> - pack-bitmap.c: harden 'test_bitmap_walk()' to check type bitmaps
>
> The reachability bitmap file used to be generated only for a single
> pack, but now we've learned to generate bitmaps for history that
> span across multiple packfiles.
>
> Will merge to 'next'.
The merge commit 24cade3ceb ("Merge branch 'jb/midx-revindex-fix' into seen",
2021-09-07) basically takes two versions of the same patch and keeps both
versions of the same test. The two patches are:
- c575d4a2d9 ("multi-pack-index: fix *.rev cleanups with --object-dir",
2021-08-23)
- 426c00e454 ("midx: fix `*.rev` cleanups with `--object-dir`", 2021-08-31)
(the second patch is from the 'tb/multi-pack-bitmaps' branch).
The second patch even includes an acknowledgment of 'Original-patch-by:
Johannes Berg <johannes@sipsolutions.net>' (ie the first patch).
$ ./t5319-multi-pack-index.sh -i -v
...
expecting success of 5319.19 'multi-pack-index *.rev cleanup with --object-dir':
...
ok 19 - multi-pack-index *.rev cleanup with --object-dir
expecting success of 5319.20 'multi-pack-index *.rev cleanup with --object-dir':
...
fatal: not a git repository (or any of the parent directories): .git
...
$
The 'fatal' message is issued by a call to 'nongit git multi-pack-index ... write'
command, which implies that 'git multi-pack-index' dies when not run from
a repository. When the original patch was written, that command would not
have died, so somewhere between v2.33.0 and 'seen' (maybe as part of the
'tb/multi-pack-bitmaps' branch, I haven't looked), that was changed and
that test no longer works.
If I had to change that test to take account of that change in behaviour,
then it would look pretty much the same as the new test in Taylor's commit
(and which can now be seen as test #19 above).
So, a solution would be to simply drop 'jb/midx-revindex-fix', since it
has effectively been incorporated into Taylor's branch. You could also
go the other way around, drop commit 426c00e454 from Taylor's branch and
fix up the test in Johannes's patch ... :-P
Well, I only had a quick look so (hopefully) I haven't missed something
obvious!
ATB,
Ramsay Jones
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: What's cooking in git.git (Sep 2021, #02; Wed, 8)
2021-09-09 2:59 ` Ramsay Jones
@ 2021-09-09 17:45 ` Junio C Hamano
0 siblings, 0 replies; 25+ messages in thread
From: Junio C Hamano @ 2021-09-09 17:45 UTC (permalink / raw)
To: Ramsay Jones; +Cc: git
Ramsay Jones <ramsay@ramsayjones.plus.com> writes:
> On 08/09/2021 16:38, Junio C Hamano wrote:
>
> test t5319-multi-pack-index.sh on 'seen' has been failing for
> several days, so I had a quick look tonight. This issue relates
> to the following two topics:
> ...
> The merge commit 24cade3ceb ("Merge branch 'jb/midx-revindex-fix' into seen",
> 2021-09-07) basically takes two versions of the same patch and keeps both
> versions of the same test. The two patches are:
> ...
> The second patch even includes an acknowledgment of 'Original-patch-by:
> Johannes Berg <johannes@sipsolutions.net>' (ie the first patch).
You're right.
Thanks for helping me straighten the mess.
^ permalink raw reply [flat|nested] 25+ messages in thread
* js/scalar, was Re: What's cooking in git.git (Sep 2021, #02; Wed, 8)
2021-09-08 15:38 What's cooking in git.git (Sep 2021, #02; Wed, 8) Junio C Hamano
` (4 preceding siblings ...)
2021-09-09 2:59 ` Ramsay Jones
@ 2021-09-09 11:03 ` Johannes Schindelin
2021-09-10 8:52 ` Junio C Hamano
2021-09-09 11:05 ` rs/range-diff-avoid-segfault-with-I, " Johannes Schindelin
` (6 subsequent siblings)
12 siblings, 1 reply; 25+ messages in thread
From: Johannes Schindelin @ 2021-09-09 11:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Hi Junio,
On Wed, 8 Sep 2021, Junio C Hamano wrote:
> * js/scalar (2021-09-03) 15 commits
> - scalar: accept -C and -c options before the subcommand
> - scalar: implement the `version` command
> - scalar: implement the `delete` command
> - scalar: teach 'reconfigure' to optionally handle all registered enlistments
> - scalar: allow reconfiguring an existing enlistment
> - scalar: implement the `run` command
> - scalar: teach 'clone' to support the --single-branch option
> - scalar: implement the `clone` subcommand
> - scalar: implement 'scalar list'
> - scalar: let 'unregister' handle a deleted enlistment directory gracefully
> - scalar: 'unregister' stops background maintenance
> - scalar: 'register' sets recommended config and starts maintenance
> - scalar: create test infrastructure
> - scalar: start documenting the command
> - scalar: create a rudimentary executable
>
> Add pieces from "scalar" to contrib/.
Thank you for picking it up. It seems as if the reviews are starting to
decrease to a point where I could imagine that we can start talking about
how to refactor things to start bringing the benefits to Git proper.
For what it's worth, I maintain a branch thicket on top of this branch
that has the remaining Scalar parts, both those parts that I still intend
to upstream as well as those parts that will most likely stay in
microsoft/git (e.g. the GVFS protocol-related parts, as it was decided
long ago that the VFS bits won't make it into Git proper, and
microsoft/git only needs these bits for compatibility with Azure Repos).
Here is the CI/PR run of that branch:
https://github.com/dscho/git/actions/runs/1216858695
And much more interesting is the run of the full Scalar Functional Tests
suite: https://github.com/dscho/git/actions/runs/1216858693
(Both pass, of course.)
Ciao,
Dscho
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: js/scalar, was Re: What's cooking in git.git (Sep 2021, #02; Wed, 8)
2021-09-09 11:03 ` js/scalar, was " Johannes Schindelin
@ 2021-09-10 8:52 ` Junio C Hamano
0 siblings, 0 replies; 25+ messages in thread
From: Junio C Hamano @ 2021-09-10 8:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Wed, 8 Sep 2021, Junio C Hamano wrote:
>
>> * js/scalar (2021-09-03) 15 commits
>> ...
>>
>> Add pieces from "scalar" to contrib/.
>
> Thank you for picking it up. It seems as if the reviews are starting to
> decrease to a point where I could imagine that we can start talking about
> how to refactor things to start bringing the benefits to Git proper.
For now I've given all what I thought about the patches I looked at,
and I think a handful other folks made comments on them. I am not
keeping track of which comments have not yet been addressed, but it
seems that we hopefully do not need more than a couple more rounds.
^ permalink raw reply [flat|nested] 25+ messages in thread
* rs/range-diff-avoid-segfault-with-I, was Re: What's cooking in git.git (Sep 2021, #02; Wed, 8)
2021-09-08 15:38 What's cooking in git.git (Sep 2021, #02; Wed, 8) Junio C Hamano
` (5 preceding siblings ...)
2021-09-09 11:03 ` js/scalar, was " Johannes Schindelin
@ 2021-09-09 11:05 ` Johannes Schindelin
2021-09-09 11:08 ` js/retire-preserve-merges, " Johannes Schindelin
` (5 subsequent siblings)
12 siblings, 0 replies; 25+ messages in thread
From: Johannes Schindelin @ 2021-09-09 11:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Hi Junio,
On Wed, 8 Sep 2021, Junio C Hamano wrote:
> * rs/range-diff-avoid-segfault-with-I (2021-09-07) 1 commit
> - range-diff: avoid segfault with -I
>
> "git range-diff -I... <range> <range>" segfaulted, which has been
> corrected.
>
> Will merge to 'next'?
Sounds good to me,
Dscho
^ permalink raw reply [flat|nested] 25+ messages in thread
* js/retire-preserve-merges, was Re: What's cooking in git.git (Sep 2021, #02; Wed, 8)
2021-09-08 15:38 What's cooking in git.git (Sep 2021, #02; Wed, 8) Junio C Hamano
` (6 preceding siblings ...)
2021-09-09 11:05 ` rs/range-diff-avoid-segfault-with-I, " Johannes Schindelin
@ 2021-09-09 11:08 ` Johannes Schindelin
2021-09-10 5:00 ` Junio C Hamano
2021-09-09 11:08 ` mr/bisect-in-c-4, " Johannes Schindelin
` (4 subsequent siblings)
12 siblings, 1 reply; 25+ messages in thread
From: Johannes Schindelin @ 2021-09-09 11:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Hi Junio,
On Wed, 8 Sep 2021, Junio C Hamano wrote:
> * js/retire-preserve-merges (2021-09-07) 11 commits
> - sequencer: restrict scope of a formerly public function
> - rebase: remove a no-longer-used function
> - rebase: stop mentioning the -p option in comments
> - rebase: remove obsolete code comment
> - rebase: drop the internal `rebase--interactive` command
> - git-svn: drop support for `--preserve-merges`
> - rebase: drop support for `--preserve-merges`
> - pull: remove support for `--rebase=preserve`
> - tests: stop testing `git rebase --preserve-merges`
> - remote: warn about unhandled branch.<name>.rebase values
> - t5520: do not use `pull.rebase=preserve`
>
> The "--preserve-merges" option of "git rebase" has been removed.
>
> Will merge to 'next'?
I think so, given the rate of reviews still trickling in tending toward
zero.
We probably want to keep it in `next` for quite a while, too, to make sure
that people get the memo.
Ciao,
Dscho
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: js/retire-preserve-merges, was Re: What's cooking in git.git (Sep 2021, #02; Wed, 8)
2021-09-09 11:08 ` js/retire-preserve-merges, " Johannes Schindelin
@ 2021-09-10 5:00 ` Junio C Hamano
0 siblings, 0 replies; 25+ messages in thread
From: Junio C Hamano @ 2021-09-10 5:00 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi Junio,
>
> On Wed, 8 Sep 2021, Junio C Hamano wrote:
>
>> * js/retire-preserve-merges (2021-09-07) 11 commits
>> - sequencer: restrict scope of a formerly public function
>> - rebase: remove a no-longer-used function
>> - rebase: stop mentioning the -p option in comments
>> - rebase: remove obsolete code comment
>> - rebase: drop the internal `rebase--interactive` command
>> - git-svn: drop support for `--preserve-merges`
>> - rebase: drop support for `--preserve-merges`
>> - pull: remove support for `--rebase=preserve`
>> - tests: stop testing `git rebase --preserve-merges`
>> - remote: warn about unhandled branch.<name>.rebase values
>> - t5520: do not use `pull.rebase=preserve`
>>
>> The "--preserve-merges" option of "git rebase" has been removed.
>>
>> Will merge to 'next'?
>
> I think so, given the rate of reviews still trickling in tending toward
> zero.
We need to be careful about making our decision on such a trend.
For a later iteration, the lack of comments does not give us much
information. It can happen if all the comments have adequately been
addressed, but it also can happen if none of the suggestions given
in earlier rounds are addressed---the reviewers can easily give up
and leave.
I think I've followed the topic well enough to tell that it is the
former for this instance (i.e. the patches have been polished well
enough). Let's merge to 'next' so that we can keep it there long
enough.
Thanks.
> We probably want to keep it in `next` for quite a while, too, to make sure
> that people get the memo.
>
> Ciao,
> Dscho
^ permalink raw reply [flat|nested] 25+ messages in thread
* mr/bisect-in-c-4, was Re: What's cooking in git.git (Sep 2021, #02; Wed, 8)
2021-09-08 15:38 What's cooking in git.git (Sep 2021, #02; Wed, 8) Junio C Hamano
` (7 preceding siblings ...)
2021-09-09 11:08 ` js/retire-preserve-merges, " Johannes Schindelin
@ 2021-09-09 11:08 ` Johannes Schindelin
2021-09-10 5:07 ` Junio C Hamano
2021-09-09 11:13 ` lh/systemd-timers, " Johannes Schindelin
` (3 subsequent siblings)
12 siblings, 1 reply; 25+ messages in thread
From: Johannes Schindelin @ 2021-09-09 11:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Hi Junio,
On Wed, 8 Sep 2021, Junio C Hamano wrote:
> * mr/bisect-in-c-4 (2021-09-02) 6 commits
> - bisect--helper: retire `--bisect-next-check` subcommand
> - bisect--helper: reimplement `bisect_run` shell
> - bisect--helper: reimplement `bisect_visualize()`shell function in C
> - run-command: make `exists_in_PATH()` non-static
> - t6030-bisect-porcelain: add test for bisect visualize
> - t6030-bisect-porcelain: add tests to control bisect run exit cases
>
> Rewrite of "git bisect" in C continues.
From my point of view, this is ready for `next`.
Ciao,
Dscho
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: mr/bisect-in-c-4, was Re: What's cooking in git.git (Sep 2021, #02; Wed, 8)
2021-09-09 11:08 ` mr/bisect-in-c-4, " Johannes Schindelin
@ 2021-09-10 5:07 ` Junio C Hamano
2021-09-10 9:33 ` Johannes Schindelin
0 siblings, 1 reply; 25+ messages in thread
From: Junio C Hamano @ 2021-09-10 5:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Miriam Rubio
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Wed, 8 Sep 2021, Junio C Hamano wrote:
>
>> * mr/bisect-in-c-4 (2021-09-02) 6 commits
>> - bisect--helper: retire `--bisect-next-check` subcommand
>> - bisect--helper: reimplement `bisect_run` shell
>> - bisect--helper: reimplement `bisect_visualize()`shell function in C
>> - run-command: make `exists_in_PATH()` non-static
>> - t6030-bisect-porcelain: add test for bisect visualize
>> - t6030-bisect-porcelain: add tests to control bisect run exit cases
>>
>> Rewrite of "git bisect" in C continues.
>
> From my point of view, this is ready for `next`.
You agreed that redirection with dup2()'s in [5/6] was good enough
for now [*1*], but in that case, we need to add a few fflush(stdout)
around the dup2() dance [*2*].
So this is not quite ready for 'next' yet, although it is almost
there, I'd think.
[References]
*1* https://lore.kernel.org/git/nycvar.QRO.7.76.6.2109090922310.55@tvgsbejvaqbjf.bet/
*2* https://lore.kernel.org/git/xmqqtuj2h7cp.fsf@gitster.g/
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: mr/bisect-in-c-4, was Re: What's cooking in git.git (Sep 2021, #02; Wed, 8)
2021-09-10 5:07 ` Junio C Hamano
@ 2021-09-10 9:33 ` Johannes Schindelin
0 siblings, 0 replies; 25+ messages in thread
From: Johannes Schindelin @ 2021-09-10 9:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Miriam Rubio
Hi Junio,
On Thu, 9 Sep 2021, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Wed, 8 Sep 2021, Junio C Hamano wrote:
> >
> >> * mr/bisect-in-c-4 (2021-09-02) 6 commits
> >> - bisect--helper: retire `--bisect-next-check` subcommand
> >> - bisect--helper: reimplement `bisect_run` shell
> >> - bisect--helper: reimplement `bisect_visualize()`shell function in C
> >> - run-command: make `exists_in_PATH()` non-static
> >> - t6030-bisect-porcelain: add test for bisect visualize
> >> - t6030-bisect-porcelain: add tests to control bisect run exit cases
> >>
> >> Rewrite of "git bisect" in C continues.
> >
> > From my point of view, this is ready for `next`.
>
> You agreed that redirection with dup2()'s in [5/6] was good enough
> for now [*1*], but in that case, we need to add a few fflush(stdout)
> around the dup2() dance [*2*].
>
> So this is not quite ready for 'next' yet, although it is almost
> there, I'd think.
Oh right, I fogot about the `fflush()` stuff.
Thanks,
Dscho
>
>
> [References]
>
> *1* https://lore.kernel.org/git/nycvar.QRO.7.76.6.2109090922310.55@tvgsbejvaqbjf.bet/
>
> *2* https://lore.kernel.org/git/xmqqtuj2h7cp.fsf@gitster.g/
>
^ permalink raw reply [flat|nested] 25+ messages in thread
* lh/systemd-timers, was Re: What's cooking in git.git (Sep 2021, #02; Wed, 8)
2021-09-08 15:38 What's cooking in git.git (Sep 2021, #02; Wed, 8) Junio C Hamano
` (8 preceding siblings ...)
2021-09-09 11:08 ` mr/bisect-in-c-4, " Johannes Schindelin
@ 2021-09-09 11:13 ` Johannes Schindelin
2021-09-09 11:15 ` ar/submodule-add-more, " Johannes Schindelin
` (2 subsequent siblings)
12 siblings, 0 replies; 25+ messages in thread
From: Johannes Schindelin @ 2021-09-09 11:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 575 bytes --]
Hi Junio,
On Wed, 8 Sep 2021, Junio C Hamano wrote:
> * lh/systemd-timers (2021-09-07) 3 commits
> - maintenance: add support for systemd timers on Linux
> - maintenance: `git maintenance run` learned `--scheduler=<scheduler>`
> - cache.h: Introduce a generic "xdg_config_home_for(…)" function
>
> "git maintenance" scheduler learned to use systemd timers as a
> possible backend.
>
> Will merge to 'next'.
Yes!
And since you merged down `js/maintenance-launchctl-fix` to `master`
already, I guess I won't be rebasing it on top.
Ciao,
Dscho
^ permalink raw reply [flat|nested] 25+ messages in thread
* ar/submodule-add-more, was Re: What's cooking in git.git (Sep 2021, #02; Wed, 8)
2021-09-08 15:38 What's cooking in git.git (Sep 2021, #02; Wed, 8) Junio C Hamano
` (9 preceding siblings ...)
2021-09-09 11:13 ` lh/systemd-timers, " Johannes Schindelin
@ 2021-09-09 11:15 ` Johannes Schindelin
2021-09-10 5:30 ` Junio C Hamano
2021-09-09 11:18 ` Ævar Arnfjörð Bjarmason
2021-09-09 14:12 ` Elijah Newren
12 siblings, 1 reply; 25+ messages in thread
From: Johannes Schindelin @ 2021-09-09 11:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Hi Junio,
On Wed, 8 Sep 2021, Junio C Hamano wrote:
> * ar/submodule-add-more (2021-08-10) 10 commits
> - submodule--helper: rename compute_submodule_clone_url()
> - submodule--helper: remove resolve-relative-url subcommand
> - submodule--helper: remove add-config subcommand
> - submodule--helper: remove add-clone subcommand
> - submodule--helper: convert the bulk of cmd_add() to C
> - dir: libify and export helper functions from clone.c
> - submodule--helper: remove repeated code in sync_submodule()
> - submodule--helper: refactor resolve_relative_url() helper
> - submodule--helper: add options for compute_submodule_clone_url()
> - Merge branch 'ar/submodule-add-config' into ar/submodule-add
> (this branch uses ar/submodule-add-config.)
>
> More parts of "git submoudle add" has been rewritten in C.
>
> Will merge to 'next'.
If you use the description in the release notes, please
`s/submoudle/submodule/` first.
Thanks,
Dscho
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: ar/submodule-add-more, was Re: What's cooking in git.git (Sep 2021, #02; Wed, 8)
2021-09-09 11:15 ` ar/submodule-add-more, " Johannes Schindelin
@ 2021-09-10 5:30 ` Junio C Hamano
0 siblings, 0 replies; 25+ messages in thread
From: Junio C Hamano @ 2021-09-10 5:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi Junio,
>
> On Wed, 8 Sep 2021, Junio C Hamano wrote:
>
>> * ar/submodule-add-more (2021-08-10) 10 commits
>> - submodule--helper: rename compute_submodule_clone_url()
>> - submodule--helper: remove resolve-relative-url subcommand
>> - submodule--helper: remove add-config subcommand
>> - submodule--helper: remove add-clone subcommand
>> - submodule--helper: convert the bulk of cmd_add() to C
>> - dir: libify and export helper functions from clone.c
>> - submodule--helper: remove repeated code in sync_submodule()
>> - submodule--helper: refactor resolve_relative_url() helper
>> - submodule--helper: add options for compute_submodule_clone_url()
>> - Merge branch 'ar/submodule-add-config' into ar/submodule-add
>> (this branch uses ar/submodule-add-config.)
>>
>> More parts of "git submoudle add" has been rewritten in C.
>>
>> Will merge to 'next'.
>
> If you use the description in the release notes, please
> `s/submoudle/submodule/` first.
Thank you.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: What's cooking in git.git (Sep 2021, #02; Wed, 8)
2021-09-08 15:38 What's cooking in git.git (Sep 2021, #02; Wed, 8) Junio C Hamano
` (10 preceding siblings ...)
2021-09-09 11:15 ` ar/submodule-add-more, " Johannes Schindelin
@ 2021-09-09 11:18 ` Ævar Arnfjörð Bjarmason
2021-09-09 14:12 ` Elijah Newren
12 siblings, 0 replies; 25+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2021-09-09 11:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, SZEDER Gábor
On Wed, Sep 08 2021, Junio C Hamano wrote:
As usual, updates on my topics & related:
First, I realize you're busy & I have a lot of things outstanding, but
just for completeness, trivial one-patch topics I submitted recently
that you didn't pick up. I think all of these are rather simple &
straightforward bug fixes / improvements:
* fetch-negotiator: call BUG() on API misuse, don't segfault:
<patch-1.1-f1da49de63-20210727T000203Z-avarab@gmail.com>
(https://lore.kernel.org/git/patch-1.1-f1da49de63-20210727T000203Z-avarab@gmail.com/)
* http.c: use error_errno(), not error() after fopen() failure:
<patch-1.1-ad71faa6da-20210727T000657Z-avarab@gmail.com>
(https://lore.kernel.org/git/patch-1.1-ad71faa6da-20210727T000657Z-avarab@gmail.com/)
* stash: print the correct usage on "git stash [push] --invalid-option":
<patch-1.1-47c582f1218-20210901T111930Z-avarab@gmail.com>:
https://lore.kernel.org/git/patch-1.1-47c582f1218-20210901T111930Z-avarab@gmail.com/
And then this 2-patch and slightly more complex series to make "git
<built-in> -h" output prettily aligned:
* parse-options: properly align continued usage output:
<cover-0.2-00000000000-20210901T110917Z-avarab@gmail.com>:
https://lore.kernel.org/git/cover-0.2-00000000000-20210901T110917Z-avarab@gmail.com/
Notes on picke-dup serieses below:
> * ab/no-more-check-bindir (2021-09-07) 1 commit
> Will merge to 'next'.
> * ab/send-email-config-fix (2021-09-07) 1 commit
> Will merge to 'next' and then to 'master'.
> Will merge to 'next'.
Thanks!
>> * ab/reverse-midx-optim (2021-09-07) 1 commit
> - pack-write: skip *.rev work when not writing *.rev
Already merged to "next" I see, thanks!
> * ab/sanitize-leak-ci (2021-09-07) 3 commits
Per your comment about this & my reply at
https://lore.kernel.org/git/87sfyfgtfh.fsf@evledraar.gmail.com/ & not
having heard back from Emily...
> * es/config-based-hooks (2021-08-19) 7 commits
> [...]
> - Merge branch 'ab/config-based-hooks-base' into es/config-based-hooks
> (this branch uses ab/config-based-hooks-base.)
>
> Revamp the hooks subsystem to allow multiple of them to trigger
> upon the same event and control via the configuration variables.
>
> Expecting a reroll
> but ab/config-based-hooks-base needs to be in a better shape first.
> cf. <87v93wflm0.fsf@evledraar.gmail.com>
> cf. <87tuj7xhqo.fsf@evledraar.gmail.com>
... I'll submit my version of this on top of my not-yet-picked-up (due
to a conflict with this stale topic) ab/config-based-hooks-base, pending
Emily's canonical version of that..
> * jh/builtin-fsmonitor (2021-09-03) 37 commits
> [...]
> Expecting a reroll post 2.33 release.
Per your "I may start discarding too ancient topics to nudge the authors
to resubmit updates to them" above I've got one one-patch series cleanup
that's been blocked by a conflict with this for a long time. Perhaps a
candidate for ejection until the re-roll materializes?
> * ab/fsck-unexpected-type (2021-09-07) 22 commits
> [...]
>
> "git fsck" has been taught to report mismatch between expected and
> actual types of an object better.
>
> Needs review.
Indeed, any takers? It's been cooking for a long time and I think it
should be well tested / mature at this point, but if there's no takers I
might need to split it up and submit it incrementally. I haven't thought
of a way to do that that doesn't make it more confusing, e.g. just the
tests or just some of the prep work is a "bridge to nowhere" without the
end parts of it...
> * gh/gitweb-branch-sort (2021-06-10) 1 commit
> - gitweb: use HEAD as secondary sort key in git_get_heads_list()
>
> Tie-break branches that point at the same object in the list of
> branches on GitWeb to show the one pointed at by HEAD early.
>
> Will merge to 'next'.
Nice!
> * js/retire-preserve-merges (2021-09-07) 11 commits
> [...]
> The "--preserve-merges" option of "git rebase" has been removed.
>
> Will merge to 'next'?
I agree that that would be nice, and re
https://lore.kernel.org/git/nycvar.QRO.7.76.6.2109091307070.59@tvgsbejvaqbjf.bet/
think it would be fine for that to happen sooner than later, but if
Johannes would prefer to wait a while...
> * ab/gc-log-rephrase (2021-09-02) 1 commit
> Will merge to 'master'.
> * ab/mailmap-leakfix (2021-08-31) 1 commit
> Will merge to 'master'.
> * ba/object-info (2021-08-31) 1 commit
> Will merge to 'master'.
Thanks!
> * ab/commit-graph-usage (2021-08-30) 7 commits
> [...]
> Will merge to 'master'.
Thanks, I've got some more parse_options() fixes waiting on this.
> * ab/ls-remote-packet-trace (2021-08-24) 1 commit
> Will merge to 'master'.
> * ab/rebase-fatal-fatal-fix (2021-08-24) 1 commit
> Will merge to 'master'.
Thanks!
> * ab/refs-errno-cleanup (2021-08-25) 4 commits
> - refs: make errno output explicit for refs_resolve_ref_unsafe
> - refs: explicitly return failure_errno from parse_loose_ref_contents
> - branch tests: test for errno propagating on failing read
> - refs: add failure_errno to refs_read_raw_ref() signature
> (this branch uses ab/refs-files-cleanup and hn/refs-errno-cleanup.)
>
> The "remainder" of hn/refs-errno-cleanup topic.
It would be nice to get some movement on this and the dependant topics,
per my https://lore.kernel.org/git/8735qnax0o.fsf@evledraar.gmail.com/
> * ab/retire-advice-config (2021-08-25) 4 commits
> [...]
> Will merge to 'master'.
Thanks. I've also got some more advice fixes waiting on this.
> * js/maintenance-launchctl-fix (2021-08-24) 2 commits
> [...]
> Will merge to 'master'.
Merged already I see, I have a trivial fix-on-top at
https://lore.kernel.org/git/patch-1.1-93adb856b0c-20210909T012244Z-avarab@gmail.com/
> * jv/pkt-line-batch (2021-09-01) 2 commits
> - upload-pack: use stdio in send_ref callbacks
> - pkt-line: add stdio packet write functions
>
> Reduce number of write(2) system calls while sending the
> ref advertisement.
>
> Will merge to 'next'?
LGTM!
> * ab/unbundle-progress (2021-09-07) 4 commits
> - bundle: show progress on "unbundle"
> - index-pack: add --progress-title option
> - bundle API: change "flags" to be "extra_index_pack_args"
> - bundle API: start writing API documentation
>
> Add progress display to "git bundle unbundle".
>
> Will merge to 'next'?
I think so, the last re-roll was small, reduced net complexity, and
addressed all outstanding feedback.
> * ab/lib-subtest (2021-08-05) 11 commits
> - test-lib tests: assert 1 exit code, not non-zero
> - test-lib tests: refactor common part of check_sub_test_lib_test*()
> - test-lib tests: avoid subshell for "test_cmp" for readability
> - test-lib tests: assert no copy/pasted mock test code
> - test-lib tests: get rid of copy/pasted mock test code
> - test-lib tests: don't provide a description for the sub-tests
> - test-lib tests: stop using a subshell in write_sub_test_lib_test()
> - test-lib tests: split up "write and run" into two functions
> - test-lib tests: move "run_sub_test" to a new lib-subtest.sh
> - Merge branch 'ps/t0000-output-directory-fix' into ab/lib-subtest
> - Merge branch 'jk/t0000-subtests-fix' into ab/lib-subtest
>
> Updates to the tests in t0000 to test the test framework.
Would be nice to get movement on this, any takers for reviews? Perhaps I
should re-submit it.
> * ab/only-single-progress-at-once (2021-07-23) 8 commits
> - progress.c: add & assert a "global_progress" variable
> - pack-bitmap-write.c: add a missing stop_progress()
> - progress.c: add temporary variable from progress struct
> - progress.c: stop eagerly fflush(stderr) when not a terminal
> - progress.c: call progress_interval() from progress_test_force_update()
> - progress.c: move signal handler functions lower
> - progress.c tests: test some invalid usage
> - progress.c tests: make start/stop verbs on stdin
>
> Further tweaks on progress API.
>
> On hold.
> cf. <20210901050406.GB76263@szeder.dev>
SZEDER: Any hints as to what that issue is or how to reproduce it?
> * ab/progress-users-adjust-counters (2021-08-25) 2 commits
> - entry: show finer-grained counter in "Filtering content" progress line
> - commit-graph: fix bogus counter in "Scanning merged commits" progress line
>
> The code to show progress indicator in a few codepaths did not
> cover between 0-100%, which has been corrected.
>
> Will merge to 'next'?
Sounds good, I re-rolled this at
https://lore.kernel.org/git/cover-v4-0.2-00000000000-20210909T010722Z-avarab@gmail.com/
to fix a relatively trivial and new conflict with "master", t omake that
easier.
> * ab/make-tags-cleanup (2021-08-05) 5 commits
> [...]
> Build clean-up for "make tags" and friends.
>
> Will merge to 'next'?
I think it's ready & has all previous feedback addressed.
> * ab/config-based-hooks-base (2021-08-03) 36 commits
> [...]
> (this branch is used by es/config-based-hooks.)
>
> Restructuring of (a subset of) Emily's config-based-hooks series,
> to demonstrate that a series can be presented as a more logical and
> focused progression.
>
> Waiting for reviews.
Per note on es/config-based-hooks above this is the v4 that's replaced
by my not-yet-picked-up due to conflict with es/config-based-hooks v5.
> * ab/serve-cleanup (2021-08-05) 10 commits
> - upload-pack: document and rename --advertise-refs
> - serve.[ch]: remove "serve_options", split up --advertise-refs code
> - {upload,receive}-pack tests: add --advertise-refs tests
> - serve.c: move version line to advertise_capabilities()
> - serve: move transfer.advertiseSID check into session_id_advertise()
> - serve.[ch]: don't pass "struct strvec *keys" to commands
> - serve: use designated initializers
> - transport: use designated initializers
> - transport: rename "fetch" in transport_vtable to "fetch_refs"
> - serve: mark has_capability() as static
>
> Code clean-up around "git serve".
>
> Will merge to 'next'?
That would be very nice, I think it's received thorough reviews of the
relevant parts that still remain, and the whole "config callback"
mechanism people were on the fence about has been entirely ejected.
> * ab/pack-objects-stdin (2021-07-09) 5 commits
> - pack-objects.c: make use of REV_INFO_STDIN_LINE_PROCESS
> - pack-objects.c: do stdin parsing via revision.c's API
> - revision.[ch]: add a "handle_stdin_line" API
> - revision.h: refactor "disable_stdin" and "read_from_stdin"
> - upload-pack: run is_repository_shallow() before setup_revisions()
>
> Introduce handle_stdin_line callback to revision API and uses it.
>
> Waiting for reviews.
Per https://lore.kernel.org/git/8735qnax0o.fsf@evledraar.gmail.com/ I'd
prefer to have this reviewed & go in in isolation, but per the note
there if there's no interest perhaps I'll re-submit a larger version of
this that implements the "refs and tips on stdin to git bundle" that I
created this for.
> * ab/refs-files-cleanup (2021-08-25) 13 commits
> - refs/files: remove unused "errno != ENOTDIR" condition
> - refs/files: remove unused "errno == EISDIR" code
> - refs/files: remove unused "oid" in lock_ref_oid_basic()
> - refs API: remove OID argument to reflog_expire()
> - reflog expire: don't lock reflogs using previously seen OID
> - refs/files: add a comment about refs_reflog_exists() call
> - refs: make repo_dwim_log() accept a NULL oid
> - refs/debug: re-indent argument list for "prepare"
> - refs/files: remove unused "skip" in lock_raw_ref() too
> - refs/files: remove unused "extras/skip" in lock_ref_oid_basic()
> - refs: drop unused "flags" parameter to lock_ref_oid_basic()
> - refs/files: remove unused REF_DELETING in lock_ref_oid_basic()
> - refs/packet: add missing BUG() invocations to reflog callbacks
> (this branch is used by ab/refs-errno-cleanup and hn/refs-errno-cleanup.)
>
> Continued work on top of the hn/refs-errno-cleanup topic.
>
>
> * hn/refs-errno-cleanup (2021-08-25) 4 commits
> - refs: make errno output explicit for read_raw_ref_fn
> - refs/files-backend: stop setting errno from lock_ref_oid_basic
> - refs: remove EINVAL errno output from specification of read_raw_ref_fn
> - refs file backend: move raceproof_create_file() here
> (this branch is used by ab/refs-errno-cleanup; uses ab/refs-files-cleanup.)
>
> Futz with the way 'errno' is relied on in the refs API to carry the
> failure modes up the callchain.
I think these should be ready for merger down, also per the note in last
week's What's Cooking at
https://lore.kernel.org/git/8735qnax0o.fsf@evledraar.gmail.com/
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: What's cooking in git.git (Sep 2021, #02; Wed, 8)
2021-09-08 15:38 What's cooking in git.git (Sep 2021, #02; Wed, 8) Junio C Hamano
` (11 preceding siblings ...)
2021-09-09 11:18 ` Ævar Arnfjörð Bjarmason
@ 2021-09-09 14:12 ` Elijah Newren
12 siblings, 0 replies; 25+ messages in thread
From: Elijah Newren @ 2021-09-09 14:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
A few comments on some topics from other folks...
On Wed, Sep 8, 2021 at 8:40 AM Junio C Hamano <gitster@pobox.com> wrote:
> * pb/test-use-user-env (2021-09-07) 3 commits
> - test-lib-functions: keep user's debugger config files and TERM in 'debug'
> - test-lib-functions: optionally keep HOME, TERM and SHELL in 'test_pause'
> - test-lib-functions: use 'TEST_SHELL_PATH' in 'test_pause'
>
> Teach test_pause and test_debug to allow using the HOME and TERM
> environment variables the user usually uses.
>
> Will merge to 'next'?
Sounds good to me; I'm happy with the latest series.
> * js/retire-preserve-merges (2021-09-07) 11 commits
> - sequencer: restrict scope of a formerly public function
> - rebase: remove a no-longer-used function
> - rebase: stop mentioning the -p option in comments
> - rebase: remove obsolete code comment
> - rebase: drop the internal `rebase--interactive` command
> - git-svn: drop support for `--preserve-merges`
> - rebase: drop support for `--preserve-merges`
> - pull: remove support for `--rebase=preserve`
> - tests: stop testing `git rebase --preserve-merges`
> - remote: warn about unhandled branch.<name>.rebase values
> - t5520: do not use `pull.rebase=preserve`
>
> The "--preserve-merges" option of "git rebase" has been removed.
>
> Will merge to 'next'?
I came a bit late to the party, but skimmed over the series as well.
I'm very happy with the cleanups. The direction of the patches looks
good in general, and didn't spot any problems in my spot checking.
Merging down sounds good to me.
> * ds/sparse-index-ignored-files (2021-09-07) 10 commits
> - sparse-checkout: clear tracked sparse dirs
> - sparse-index: add SPARSE_INDEX_MEMORY_ONLY flag
> - attr: be careful about sparse directories
> - sparse-checkout: create helper methods
> - sparse-index: use WRITE_TREE_MISSING_OK
> - sparse-index: silently return when cache tree fails
> - unpack-trees: fix nested sparse-dir search
> - sparse-index: silently return when not using cone-mode patterns
> - t7519: rewrite sparse index test
> - Merge branch 'ds/add-with-sparse-index' into ds/sparse-index-ignored-files
> (this branch is used by sg/test-split-index-fix.)
>
> In cone mode, the sparse-index codepath learned to remove ignored
> files (like build artifacts) outside the sparse cone, allowing the
> entire directory outside the sparse cone to be removed, which is
> especially useful when the sparse patterns change.
>
> Will merge to 'next'?
I've reviewed each of the rounds in detail and I'm happy with this
one; I think it's ready.
^ permalink raw reply [flat|nested] 25+ messages in thread