* Re: What's cooking in git.git (Dec 2022, #05; Wed, 14)
2022-12-14 9:59 What's cooking in git.git (Dec 2022, #05; Wed, 14) Junio C Hamano
@ 2022-12-14 10:44 ` Junio C Hamano
2022-12-14 19:46 ` Taylor Blau
2022-12-14 15:09 ` Derrick Stolee
` (9 subsequent siblings)
10 siblings, 1 reply; 21+ messages in thread
From: Junio C Hamano @ 2022-12-14 10:44 UTC (permalink / raw)
To: git
Junio C Hamano <gitster@pobox.com> writes:
> In the past, I tried to re-examine all the topics in 'next' myself
> to pick and choose the ones to be kept before rewinding and
> rebuilding 'next' after each release, which took me a while. This
> time, to share the burden to expedite the process, I'll reset 'next'
> to 'master' without any topics merged, and rely on input from list
> participants.
>
> The topics that used to be in 'next' are all marked as "Will merge
> back to 'next'", but people can tell me to give them a chance to
> reboot their topics, instead of piling "oops, that was wrong" fixes
> on top, while I wait for such an input for the coming days.
What is involved in "re-examine to pick and choose the ones to be
kept" was to go to the original thread (which should not be too
hard, as Taylor has maintained the "source:" line in the report well
during my absense) see general consensus and the reason behind the
consensus back then still applies today. So another way people can
help the process is to say something like "After re-reading the
https://lore.kernel.org/git/$THIS thread, and particularly reading
$THAT message from $TRUSTWORTHY_REVIEWER, what the $TOPIC wants to
do and how it does it are both sensible."
No self promotion, though ;-)
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: What's cooking in git.git (Dec 2022, #05; Wed, 14)
2022-12-14 10:44 ` Junio C Hamano
@ 2022-12-14 19:46 ` Taylor Blau
0 siblings, 0 replies; 21+ messages in thread
From: Taylor Blau @ 2022-12-14 19:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Wed, Dec 14, 2022 at 07:44:23PM +0900, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > In the past, I tried to re-examine all the topics in 'next' myself
> > to pick and choose the ones to be kept before rewinding and
> > rebuilding 'next' after each release, which took me a while. This
> > time, to share the burden to expedite the process, I'll reset 'next'
> > to 'master' without any topics merged, and rely on input from list
> > participants.
> >
> > The topics that used to be in 'next' are all marked as "Will merge
> > back to 'next'", but people can tell me to give them a chance to
> > reboot their topics, instead of piling "oops, that was wrong" fixes
> > on top, while I wait for such an input for the coming days.
>
> What is involved in "re-examine to pick and choose the ones to be
> kept" was to go to the original thread (which should not be too
> hard, as Taylor has maintained the "source:" line in the report well
> during my absense) see general consensus and the reason behind the
> consensus back then still applies today.
Since it wasn't obvious to me, I figure it is worth mentioning that the
effort to maintain these source lines can be done via the "amlog" notes,
which are automatically filled in when applying new patches from the
list via your post-applypatch hook.
The relevant parts being:
message_id="$(...)"
if test -n "$message_id" && head=$(git rev-parse --verify HEAD 2>/dev/null)
then
echo "$head $message_id" >>"$GIT_DIR"/am.log &&
(
GIT_NOTES_REF=refs/notes/amlog
export GIT_NOTES_REF
git notes add -f -m "Message-Id: $message_id" "$head"
)
fi
I just made sure to push `refs/notes/amlog` up when doing new push-outs.
The rest (including the "source:" lines in the WC reports) was made easy
by your Meta/cook script.
Thanks,
Taylor
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: What's cooking in git.git (Dec 2022, #05; Wed, 14)
2022-12-14 9:59 What's cooking in git.git (Dec 2022, #05; Wed, 14) Junio C Hamano
2022-12-14 10:44 ` Junio C Hamano
@ 2022-12-14 15:09 ` Derrick Stolee
2022-12-14 23:50 ` Junio C Hamano
2022-12-14 19:09 ` Jeff Hostetler
` (8 subsequent siblings)
10 siblings, 1 reply; 21+ messages in thread
From: Derrick Stolee @ 2022-12-14 15:09 UTC (permalink / raw)
To: Junio C Hamano, git, Eric Sunshine, Jacob Keller
On 12/14/2022 4:59 AM, Junio C Hamano wrote:
> * ds/omit-trailing-hash-in-index (2022-12-13) 4 commits
> - features: feature.manyFiles implies fast index writes
> - test-lib-functions: add helper for trailing hash
> - read-cache: add index.skipHash config option
> - hashfile: allow skipping the hash function
>
> Introduce an optional configuration to allow the trailing hash that
> protects the index file from bit flipping.
>
> Will merge to 'next'.
> source: <pull.1439.v2.git.1670862677.gitgitgadget@gmail.com>
There are some outstanding comments on expanding the documentation
and commit messages, so I'm intending to send a v3 later this week.
Please hold off from merging to 'next' until then.
Thanks,
-Stolee
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: What's cooking in git.git (Dec 2022, #05; Wed, 14)
2022-12-14 15:09 ` Derrick Stolee
@ 2022-12-14 23:50 ` Junio C Hamano
0 siblings, 0 replies; 21+ messages in thread
From: Junio C Hamano @ 2022-12-14 23:50 UTC (permalink / raw)
To: Derrick Stolee; +Cc: git, Eric Sunshine, Jacob Keller
Derrick Stolee <derrickstolee@github.com> writes:
> On 12/14/2022 4:59 AM, Junio C Hamano wrote:
>
>> * ds/omit-trailing-hash-in-index (2022-12-13) 4 commits
>> - features: feature.manyFiles implies fast index writes
>> - test-lib-functions: add helper for trailing hash
>> - read-cache: add index.skipHash config option
>> - hashfile: allow skipping the hash function
>>
>> Introduce an optional configuration to allow the trailing hash that
>> protects the index file from bit flipping.
>>
>> Will merge to 'next'.
>> source: <pull.1439.v2.git.1670862677.gitgitgadget@gmail.com>
>
> There are some outstanding comments on expanding the documentation
> and commit messages, so I'm intending to send a v3 later this week.
> Please hold off from merging to 'next' until then.
Thanks, will comply.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: What's cooking in git.git (Dec 2022, #05; Wed, 14)
2022-12-14 9:59 What's cooking in git.git (Dec 2022, #05; Wed, 14) Junio C Hamano
2022-12-14 10:44 ` Junio C Hamano
2022-12-14 15:09 ` Derrick Stolee
@ 2022-12-14 19:09 ` Jeff Hostetler
2022-12-14 23:50 ` Junio C Hamano
2022-12-14 19:18 ` Jeff Hostetler
` (7 subsequent siblings)
10 siblings, 1 reply; 21+ messages in thread
From: Jeff Hostetler @ 2022-12-14 19:09 UTC (permalink / raw)
To: Junio C Hamano, git
On 12/14/22 4:59 AM, Junio C Hamano wrote:
> * jh/fsmonitor-darwin-modernize (2022-12-05) 1 commit
> - fsmonitor: eliminate call to deprecated FSEventStream function
>
> Stop using deprecated macOS API in fsmonitor.
>
> Will merge back to 'next'.
> source:<pull.1436.git.1669991072393.gitgitgadget@gmail.com>
Stefan Sundin noticed a typo in my commit message:
>Typo here, MacOS 13 is Ventura not Ventana.
I'll send a V2 shortly (and it will include your paragraph
about Apple and deprecated APIs).
Thanks,
Jeff
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: What's cooking in git.git (Dec 2022, #05; Wed, 14)
2022-12-14 19:09 ` Jeff Hostetler
@ 2022-12-14 23:50 ` Junio C Hamano
0 siblings, 0 replies; 21+ messages in thread
From: Junio C Hamano @ 2022-12-14 23:50 UTC (permalink / raw)
To: Jeff Hostetler; +Cc: git
Jeff Hostetler <git@jeffhostetler.com> writes:
> On 12/14/22 4:59 AM, Junio C Hamano wrote:
>> * jh/fsmonitor-darwin-modernize (2022-12-05) 1 commit
>> - fsmonitor: eliminate call to deprecated FSEventStream function
>> Stop using deprecated macOS API in fsmonitor.
>> Will merge back to 'next'.
>> source:<pull.1436.git.1669991072393.gitgitgadget@gmail.com>
>
>
> Stefan Sundin noticed a typo in my commit message:
>>Typo here, MacOS 13 is Ventura not Ventana.
>
> I'll send a V2 shortly (and it will include your paragraph
> about Apple and deprecated APIs).
Thanks, will hold.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: What's cooking in git.git (Dec 2022, #05; Wed, 14)
2022-12-14 9:59 What's cooking in git.git (Dec 2022, #05; Wed, 14) Junio C Hamano
` (2 preceding siblings ...)
2022-12-14 19:09 ` Jeff Hostetler
@ 2022-12-14 19:18 ` Jeff Hostetler
2022-12-15 22:37 ` Junio C Hamano
2022-12-15 9:14 ` ag/merge-strategies-in-c (was: What's cooking in git.git (Dec 2022, #05; Wed, 14)) Ævar Arnfjörð Bjarmason
` (6 subsequent siblings)
10 siblings, 1 reply; 21+ messages in thread
From: Jeff Hostetler @ 2022-12-14 19:18 UTC (permalink / raw)
To: Junio C Hamano, git
On 12/14/22 4:59 AM, Junio C Hamano wrote:
> * jh/t7527-unflake-by-forcing-cookie (2022-12-02) 1 commit
> - fsmonitor: fix race seen in t7527
>
> Make fsmonitor more robust to avoid the flakiness seen in t7527.
>
> Will merge back to 'next'.
> source:<pull.1437.git.1669937534944.gitgitgadget@gmail.com>
>
There was no discussion on this item and nothing needs to be
revisited, so it could go as is.
Thanks,
Jeff
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: What's cooking in git.git (Dec 2022, #05; Wed, 14)
2022-12-14 19:18 ` Jeff Hostetler
@ 2022-12-15 22:37 ` Junio C Hamano
0 siblings, 0 replies; 21+ messages in thread
From: Junio C Hamano @ 2022-12-15 22:37 UTC (permalink / raw)
To: Jeff Hostetler; +Cc: git
Jeff Hostetler <git@jeffhostetler.com> writes:
> On 12/14/22 4:59 AM, Junio C Hamano wrote:
>> * jh/t7527-unflake-by-forcing-cookie (2022-12-02) 1 commit
>> - fsmonitor: fix race seen in t7527
>> Make fsmonitor more robust to avoid the flakiness seen in t7527.
>> Will merge back to 'next'.
>> source:<pull.1437.git.1669937534944.gitgitgadget@gmail.com>
>>
>
> There was no discussion on this item and nothing needs to be
> revisited, so it could go as is.
No discussion is not a good news, though.
Always using cookie files means we no longer sometimes use them and
sometimes not---which means fewer variations to think about and in
general is a good thing.
As you explain in the last paragraph of the proposed log message, if
the test caught a bug introduced by a premature optimization that
was not-well-thought-out, the test served its purpose very well.
Good.
Let's mark it as "Will merge to 'next'" again.
Thanks.
^ permalink raw reply [flat|nested] 21+ messages in thread
* ag/merge-strategies-in-c (was: What's cooking in git.git (Dec 2022, #05; Wed, 14))
2022-12-14 9:59 What's cooking in git.git (Dec 2022, #05; Wed, 14) Junio C Hamano
` (3 preceding siblings ...)
2022-12-14 19:18 ` Jeff Hostetler
@ 2022-12-15 9:14 ` Ævar Arnfjörð Bjarmason
2022-12-15 12:55 ` Phillip Wood
2022-12-15 9:33 ` ab/remove--super-prefix & ab/submodule-no-abspath " Ævar Arnfjörð Bjarmason
` (5 subsequent siblings)
10 siblings, 1 reply; 21+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2022-12-15 9:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Alban Gruin, Taylor Blau
On Wed, Dec 14 2022, Junio C Hamano wrote:
> * ag/merge-strategies-in-c (2022-08-10) 14 commits
> . sequencer: use the "octopus" strategy without forking
> . sequencer: use the "resolve" strategy without forking
> . merge: use the "octopus" strategy without forking
> . merge: use the "resolve" strategy without forking
> . merge-octopus: rewrite in C
> . merge-recursive: move better_branch_name() to merge.c
> . merge-resolve: rewrite in C
> . merge-one-file: rewrite in C
> . update-index: move add_cacheinfo() to read-cache.c
> . merge-index: add a new way to invoke `git-merge-one-file'
> . merge-index: drop the index
> . merge-index: libify merge_one_path() and merge_all()
> . t6060: add tests for removed files
> . t6060: modify multiple files to expose a possible issue with merge-index
>
> An attempt to rewrite remaining merge strategies from shell to C.
>
> Tired of waiting for too long.
> source: <20220809185429.20098-1-alban.gruin@gmail.com>
I submitted a v9 of this during Taylor's maintainership, but it fell
between the cracks. I've submitted a rebased-on-master v10 now (there
were some conflicts):
https://lore.kernel.org/git/cover-v10-00.12-00000000000-20221215T084803Z-avarab@gmail.com/
It's just the "prep" patches, the real meaty part is converting the
merge drivers, which will come after. Some of the performance numbers
for those are really impressive...
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: ag/merge-strategies-in-c (was: What's cooking in git.git (Dec 2022, #05; Wed, 14))
2022-12-15 9:14 ` ag/merge-strategies-in-c (was: What's cooking in git.git (Dec 2022, #05; Wed, 14)) Ævar Arnfjörð Bjarmason
@ 2022-12-15 12:55 ` Phillip Wood
2022-12-15 15:32 ` Ævar Arnfjörð Bjarmason
0 siblings, 1 reply; 21+ messages in thread
From: Phillip Wood @ 2022-12-15 12:55 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason, Junio C Hamano
Cc: git, Alban Gruin, Taylor Blau
On 15/12/2022 09:14, Ævar Arnfjörð Bjarmason wrote:
>
> On Wed, Dec 14 2022, Junio C Hamano wrote:
>
>> * ag/merge-strategies-in-c (2022-08-10) 14 commits
>> . sequencer: use the "octopus" strategy without forking
>> . sequencer: use the "resolve" strategy without forking
>> . merge: use the "octopus" strategy without forking
>> . merge: use the "resolve" strategy without forking
>> . merge-octopus: rewrite in C
>> . merge-recursive: move better_branch_name() to merge.c
>> . merge-resolve: rewrite in C
>> . merge-one-file: rewrite in C
>> . update-index: move add_cacheinfo() to read-cache.c
>> . merge-index: add a new way to invoke `git-merge-one-file'
>> . merge-index: drop the index
>> . merge-index: libify merge_one_path() and merge_all()
>> . t6060: add tests for removed files
>> . t6060: modify multiple files to expose a possible issue with merge-index
>>
>> An attempt to rewrite remaining merge strategies from shell to C.
>>
>> Tired of waiting for too long.
>> source: <20220809185429.20098-1-alban.gruin@gmail.com>
>
> I submitted a v9 of this during Taylor's maintainership, but it fell
> between the cracks. I've submitted a rebased-on-master v10 now (there
> were some conflicts):
> https://lore.kernel.org/git/cover-v10-00.12-00000000000-20221215T084803Z-avarab@gmail.com/
>
> It's just the "prep" patches, the real meaty part is converting the
> merge drivers, which will come after. Some of the performance numbers
> for those are really impressive...
I think splitting this in two is a good idea as there were only a couple
of outstanding issues with the first half of Alban's V8. When you posted
V9 I looked at the range-diff hoping to see a couple of localized
changes addressing those issues. Instead it looks like you've rewritten
most of the patches that people have already spent a considerable time
reviewing. I don't think it is a good use of reviewers' time to
essentially start reviewing again from scratch.
Best Wishes
Phillip
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: ag/merge-strategies-in-c (was: What's cooking in git.git (Dec 2022, #05; Wed, 14))
2022-12-15 12:55 ` Phillip Wood
@ 2022-12-15 15:32 ` Ævar Arnfjörð Bjarmason
2022-12-15 16:27 ` Phillip Wood
0 siblings, 1 reply; 21+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2022-12-15 15:32 UTC (permalink / raw)
To: phillip.wood; +Cc: Junio C Hamano, git, Alban Gruin, Taylor Blau
On Thu, Dec 15 2022, Phillip Wood wrote:
> On 15/12/2022 09:14, Ævar Arnfjörð Bjarmason wrote:
>> On Wed, Dec 14 2022, Junio C Hamano wrote:
>>
>>> * ag/merge-strategies-in-c (2022-08-10) 14 commits
>>> . sequencer: use the "octopus" strategy without forking
>>> . sequencer: use the "resolve" strategy without forking
>>> . merge: use the "octopus" strategy without forking
>>> . merge: use the "resolve" strategy without forking
>>> . merge-octopus: rewrite in C
>>> . merge-recursive: move better_branch_name() to merge.c
>>> . merge-resolve: rewrite in C
>>> . merge-one-file: rewrite in C
>>> . update-index: move add_cacheinfo() to read-cache.c
>>> . merge-index: add a new way to invoke `git-merge-one-file'
>>> . merge-index: drop the index
>>> . merge-index: libify merge_one_path() and merge_all()
>>> . t6060: add tests for removed files
>>> . t6060: modify multiple files to expose a possible issue with merge-index
>>>
>>> An attempt to rewrite remaining merge strategies from shell to C.
>>>
>>> Tired of waiting for too long.
>>> source: <20220809185429.20098-1-alban.gruin@gmail.com>
>> I submitted a v9 of this during Taylor's maintainership, but it fell
>> between the cracks. I've submitted a rebased-on-master v10 now (there
>> were some conflicts):
>> https://lore.kernel.org/git/cover-v10-00.12-00000000000-20221215T084803Z-avarab@gmail.com/
>> It's just the "prep" patches, the real meaty part is converting the
>> merge drivers, which will come after. Some of the performance numbers
>> for those are really impressive...
>
> I think splitting this in two is a good idea as there were only a
> couple of outstanding issues with the first half of Alban's V8. When
> you posted V9 I looked at the range-diff hoping to see a couple of
> localized changes addressing those issues. Instead it looks like
> you've rewritten most of the patches that people have already spent a
> considerable time reviewing. I don't think it is a good use of
> reviewers' time to essentially start reviewing again from scratch.
What do you consider a good way to turn this comment into something
actionable?
To have a minimal re-submission of the v8 which simply fixes the
semnatic & textual merge conflicts we've had on "master" in the interim?
I think such a re-submission would need to address the issues I noted in
the v9 CL[1]. E.g. that in over-libifying merge-index its behavior was
changed, e.g. emitting N error() instead of die()-ing on the 1st
one. Addressing that is going to need to require around the same code
changes.
This is also a case where the range-diff looks overly scary, aside from
such specific fixes the end result is substantially the same, but I did
split up (and mostly not rewrite) the existing patches to:
* Cleanly separate those bits that were changing behavior, from those
that were not (and precede them with tests to assert that)
* Make the eventual libification change as small as possible, now it
really benefits from the diff rename detection.
If you have some more specific suggestions for how to move forward I'm
all ears.
1. https://lore.kernel.org/git/cover-v9-00.12-00000000000-20221118T110058Z-avarab@gmail.com/
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: ag/merge-strategies-in-c (was: What's cooking in git.git (Dec 2022, #05; Wed, 14))
2022-12-15 15:32 ` Ævar Arnfjörð Bjarmason
@ 2022-12-15 16:27 ` Phillip Wood
2022-12-15 16:29 ` Ævar Arnfjörð Bjarmason
0 siblings, 1 reply; 21+ messages in thread
From: Phillip Wood @ 2022-12-15 16:27 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: Junio C Hamano, git, Alban Gruin, Taylor Blau
Hi Ævar
On 15/12/2022 15:32, Ævar Arnfjörð Bjarmason wrote:
>
> On Thu, Dec 15 2022, Phillip Wood wrote:
>
>> On 15/12/2022 09:14, Ævar Arnfjörð Bjarmason wrote:
>>> On Wed, Dec 14 2022, Junio C Hamano wrote:
>>>
>>>> * ag/merge-strategies-in-c (2022-08-10) 14 commits
>>>> . sequencer: use the "octopus" strategy without forking
>>>> . sequencer: use the "resolve" strategy without forking
>>>> . merge: use the "octopus" strategy without forking
>>>> . merge: use the "resolve" strategy without forking
>>>> . merge-octopus: rewrite in C
>>>> . merge-recursive: move better_branch_name() to merge.c
>>>> . merge-resolve: rewrite in C
>>>> . merge-one-file: rewrite in C
>>>> . update-index: move add_cacheinfo() to read-cache.c
>>>> . merge-index: add a new way to invoke `git-merge-one-file'
>>>> . merge-index: drop the index
>>>> . merge-index: libify merge_one_path() and merge_all()
>>>> . t6060: add tests for removed files
>>>> . t6060: modify multiple files to expose a possible issue with merge-index
>>>>
>>>> An attempt to rewrite remaining merge strategies from shell to C.
>>>>
>>>> Tired of waiting for too long.
>>>> source: <20220809185429.20098-1-alban.gruin@gmail.com>
>>> I submitted a v9 of this during Taylor's maintainership, but it fell
>>> between the cracks. I've submitted a rebased-on-master v10 now (there
>>> were some conflicts):
>>> https://lore.kernel.org/git/cover-v10-00.12-00000000000-20221215T084803Z-avarab@gmail.com/
>>> It's just the "prep" patches, the real meaty part is converting the
>>> merge drivers, which will come after. Some of the performance numbers
>>> for those are really impressive...
>>
>> I think splitting this in two is a good idea as there were only a
>> couple of outstanding issues with the first half of Alban's V8. When
>> you posted V9 I looked at the range-diff hoping to see a couple of
>> localized changes addressing those issues. Instead it looks like
>> you've rewritten most of the patches that people have already spent a
>> considerable time reviewing. I don't think it is a good use of
>> reviewers' time to essentially start reviewing again from scratch.
>
> What do you consider a good way to turn this comment into something
> actionable?
To address the issues noted in [1-3] by tweaking patches 3, 5 & 7 of v8
and not rewrite all the other patches. Note that the sequencer cannot
die() while merging so we need to be careful when fixing patch 3 - it
should bail out early rather than dying when there is an error.
Best Wishes
Phillip
[1] https://lore.kernel.org/git/220817.86lernaa9i.gmgdl@evledraar.gmail.com
[2] https://lore.kernel.org/git/o759r3qn-nqn9-oq22-p90o-2nrn24085n80@tzk.qr
[3] https://lore.kernel.org/git/2r992r19-or36-733r-1139-4575n9o6o23s@tzk.qr
> To have a minimal re-submission of the v8 which simply fixes the
> semnatic & textual merge conflicts we've had on "master" in the interim?
>
> I think such a re-submission would need to address the issues I noted in
> the v9 CL[1]. E.g. that in over-libifying merge-index its behavior was
> changed, e.g. emitting N error() instead of die()-ing on the 1st
> one. Addressing that is going to need to require around the same code
> changes.
>
> This is also a case where the range-diff looks overly scary, aside from
> such specific fixes the end result is substantially the same, but I did
> split up (and mostly not rewrite) the existing patches to:
>
> * Cleanly separate those bits that were changing behavior, from those
> that were not (and precede them with tests to assert that)
>
> * Make the eventual libification change as small as possible, now it
> really benefits from the diff rename detection.
>
> If you have some more specific suggestions for how to move forward I'm
> all ears.
>
> 1. https://lore.kernel.org/git/cover-v9-00.12-00000000000-20221118T110058Z-avarab@gmail.com/
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: ag/merge-strategies-in-c (was: What's cooking in git.git (Dec 2022, #05; Wed, 14))
2022-12-15 16:27 ` Phillip Wood
@ 2022-12-15 16:29 ` Ævar Arnfjörð Bjarmason
0 siblings, 0 replies; 21+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2022-12-15 16:29 UTC (permalink / raw)
To: phillip.wood; +Cc: Junio C Hamano, git, Alban Gruin, Taylor Blau
On Thu, Dec 15 2022, Phillip Wood wrote:
> Hi Ævar
>
> On 15/12/2022 15:32, Ævar Arnfjörð Bjarmason wrote:
>> On Thu, Dec 15 2022, Phillip Wood wrote:
>>
>>> On 15/12/2022 09:14, Ævar Arnfjörð Bjarmason wrote:
>>>> On Wed, Dec 14 2022, Junio C Hamano wrote:
>>>>
>>>>> * ag/merge-strategies-in-c (2022-08-10) 14 commits
>>>>> . sequencer: use the "octopus" strategy without forking
>>>>> . sequencer: use the "resolve" strategy without forking
>>>>> . merge: use the "octopus" strategy without forking
>>>>> . merge: use the "resolve" strategy without forking
>>>>> . merge-octopus: rewrite in C
>>>>> . merge-recursive: move better_branch_name() to merge.c
>>>>> . merge-resolve: rewrite in C
>>>>> . merge-one-file: rewrite in C
>>>>> . update-index: move add_cacheinfo() to read-cache.c
>>>>> . merge-index: add a new way to invoke `git-merge-one-file'
>>>>> . merge-index: drop the index
>>>>> . merge-index: libify merge_one_path() and merge_all()
>>>>> . t6060: add tests for removed files
>>>>> . t6060: modify multiple files to expose a possible issue with merge-index
>>>>>
>>>>> An attempt to rewrite remaining merge strategies from shell to C.
>>>>>
>>>>> Tired of waiting for too long.
>>>>> source: <20220809185429.20098-1-alban.gruin@gmail.com>
>>>> I submitted a v9 of this during Taylor's maintainership, but it fell
>>>> between the cracks. I've submitted a rebased-on-master v10 now (there
>>>> were some conflicts):
>>>> https://lore.kernel.org/git/cover-v10-00.12-00000000000-20221215T084803Z-avarab@gmail.com/
>>>> It's just the "prep" patches, the real meaty part is converting the
>>>> merge drivers, which will come after. Some of the performance numbers
>>>> for those are really impressive...
>>>
>>> I think splitting this in two is a good idea as there were only a
>>> couple of outstanding issues with the first half of Alban's V8. When
>>> you posted V9 I looked at the range-diff hoping to see a couple of
>>> localized changes addressing those issues. Instead it looks like
>>> you've rewritten most of the patches that people have already spent a
>>> considerable time reviewing. I don't think it is a good use of
>>> reviewers' time to essentially start reviewing again from scratch.
>> What do you consider a good way to turn this comment into something
>> actionable?
>
> To address the issues noted in [1-3] by tweaking patches 3, 5 & 7 of
> v8 and not rewrite all the other patches.
>
> Best Wishes
>
> Phillip
>
> [1] https://lore.kernel.org/git/220817.86lernaa9i.gmgdl@evledraar.gmail.com
> [2] https://lore.kernel.org/git/o759r3qn-nqn9-oq22-p90o-2nrn24085n80@tzk.qr
> [3] https://lore.kernel.org/git/2r992r19-or36-733r-1139-4575n9o6o23s@tzk.qr
That seems to implicitly assume that the outstanding feedback on the v8
was the last word on outstanding issues with the series.
The v9..v10 combines addressing those, with issues that I discovered
along the way. I had not reviewed this series in any detail before.
So, I could submit such a v8.5, and then comment on it, and address
those comments, and then we'd be back to the same v9 in the end?
Since I didn't see the point of doing that I submitted the v9 directly.
> Note that the sequencer cannot die() while merging so we need to be
> careful when fixing patch 3 - it should bail out early rather than
> dying when there is an error.
Yes, part 2 will address that, i.e. there are callers that need to not
die() in the same process, but the v8 took the approach of changing the
entirety of the API to error(), but as it turns out the surface where we
needed to error() or die() is much smaller than that in the end.
>> To have a minimal re-submission of the v8 which simply fixes the
>> semnatic & textual merge conflicts we've had on "master" in the interim?
>> I think such a re-submission would need to address the issues I
>> noted in
>> the v9 CL[1]. E.g. that in over-libifying merge-index its behavior was
>> changed, e.g. emitting N error() instead of die()-ing on the 1st
>> one. Addressing that is going to need to require around the same code
>> changes.
>> This is also a case where the range-diff looks overly scary, aside
>> from
>> such specific fixes the end result is substantially the same, but I did
>> split up (and mostly not rewrite) the existing patches to:
>> * Cleanly separate those bits that were changing behavior, from
>> those
>> that were not (and precede them with tests to assert that)
>> * Make the eventual libification change as small as possible, now it
>> really benefits from the diff rename detection.
>> If you have some more specific suggestions for how to move forward
>> I'm
>> all ears.
>> 1. https://lore.kernel.org/git/cover-v9-00.12-00000000000-20221118T110058Z-avarab@gmail.com/
^ permalink raw reply [flat|nested] 21+ messages in thread
* ab/remove--super-prefix & ab/submodule-no-abspath (was: What's cooking in git.git (Dec 2022, #05; Wed, 14))
2022-12-14 9:59 What's cooking in git.git (Dec 2022, #05; Wed, 14) Junio C Hamano
` (4 preceding siblings ...)
2022-12-15 9:14 ` ag/merge-strategies-in-c (was: What's cooking in git.git (Dec 2022, #05; Wed, 14)) Ævar Arnfjörð Bjarmason
@ 2022-12-15 9:33 ` Ævar Arnfjörð Bjarmason
2022-12-15 9:49 ` js/bisect-in-c " Ævar Arnfjörð Bjarmason
` (4 subsequent siblings)
10 siblings, 0 replies; 21+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2022-12-15 9:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Glen Choo
On Wed, Dec 14 2022, Junio C Hamano wrote:
> * ab/remove--super-prefix (2022-11-21) 12 commits
> . fetch: rename "--submodule-prefix" to "--super-prefix"
> . read-tree: add "--super-prefix" option, eliminate global
> . submodule--helper: convert "{update,clone}" to their own "--super-prefix"
> . submodule--helper: convert "status" to its own "--super-prefix"
> . submodule--helper: convert "sync" to its own "--super-prefix"
> . submodule--helper: convert "foreach" to its own "--super-prefix"
> . submodule--helper: don't use global --super-prefix in "absorbgitdirs"
> . submodule.c & submodule--helper: pass along "super_prefix" param
> . read-tree + fetch tests: test failing "--super-prefix" interaction
> . Merge branch 'ab/submodule-no-abspath' into ab/remove--super-prefix
> . submodule--helper absorbgitdirs: no abspaths in "Migrating git..."
> . Merge branch 'ab/submodule-helper-prep-only' into ab/remove--super-prefix
>
> Remove the top-level `--super-prefix` option.
> Will discard.
> cf. the thread leading to <xmqqmt86stm3.fsf@gitster.g>
> source: <cover-v3-0.9-00000000000-20221119T122853Z-avarab@gmail.com>
>
>
> * ab/submodule-no-abspath (2022-11-23) 2 commits
> . submodule absorbgitdirs: use relative <from> and <to> paths
> . submodule--helper absorbgitdirs: no abspaths in "Migrating git..."
>
> Remove an absolute path in the "Migrating git directory" message.
>
> Revert out of 'next'.
> cf. the thread leading to <xmqqmt86stm3.fsf@gitster.g>
> source: <patch-1.1-34b54fdd9bb-20221109T020347Z-avarab@gmail.com>
This stranded on the question of whether the "absorbgitdirs" message
should show relative paths or not.
I've re-rolled this post-release just now at
https://lore.kernel.org/git/cover-v4-0.9-00000000000-20221215T083502Z-avarab@gmail.com/;
this time around there's no changes to the output.
^ permalink raw reply [flat|nested] 21+ messages in thread* js/bisect-in-c (was: What's cooking in git.git (Dec 2022, #05; Wed, 14))
2022-12-14 9:59 What's cooking in git.git (Dec 2022, #05; Wed, 14) Junio C Hamano
` (5 preceding siblings ...)
2022-12-15 9:33 ` ab/remove--super-prefix & ab/submodule-no-abspath " Ævar Arnfjörð Bjarmason
@ 2022-12-15 9:49 ` Ævar Arnfjörð Bjarmason
2022-12-15 11:55 ` What's cooking in git.git (Dec 2022, #05; Wed, 14) Sean Allred
` (3 subsequent siblings)
10 siblings, 0 replies; 21+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2022-12-15 9:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin
On Wed, Dec 14 2022, Junio C Hamano wrote:
> * js/bisect-in-c (2022-08-30) 17 commits
> . bisect: no longer try to clean up left-over `.git/head-name` files
> . bisect: remove Cogito-related code
> . Turn `git bisect` into a full built-in
> . bisect: move even the command-line parsing to `bisect--helper`
> . bisect--helper: make `state` optional
> . bisect--helper: calling `bisect_state()` without an argument is a bug
> . bisect: avoid double-quoting when printing the failed command
> . bisect run: fix the error message
> . bisect: verify that a bogus option won't try to start a bisection
> . bisect--helper: migrate to OPT_SUBCOMMAND()
> . bisect--helper: make the order consistently `argc, argv`
> . bisect--helper: make `terms` an explicit singleton
> . bisect--helper: simplify exit code computation
> . bisect--helper: really retire `--bisect-autostart`
> . bisect--helper: really retire --bisect-next-check
> . bisect--helper: retire the --no-log option
> . Merge branch 'sg/parse-options-subcommand' into js/bisect-in-c
>
> Final bits of "git bisect.sh" have been rewritten in C.
>
> Tired of waiting for too long.
> source: <pull.1132.v6.git.1661885419.gitgitgadget@gmail.com>
I submitted
https://lore.kernel.org/git/cover-0.6-00000000000-20221215T094038Z-avarab@gmail.com/
just now, which cherry-picks the various small fixes from this topic.
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: What's cooking in git.git (Dec 2022, #05; Wed, 14)
2022-12-14 9:59 What's cooking in git.git (Dec 2022, #05; Wed, 14) Junio C Hamano
` (6 preceding siblings ...)
2022-12-15 9:49 ` js/bisect-in-c " Ævar Arnfjörð Bjarmason
@ 2022-12-15 11:55 ` Sean Allred
2022-12-15 22:45 ` Junio C Hamano
` (2 subsequent siblings)
10 siblings, 0 replies; 21+ messages in thread
From: Sean Allred @ 2022-12-15 11:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
> * sa/git-var-empty (2022-11-27) 2 commits
> (merged to 'next' on 2022-12-01 at 3b81dcb382)
> + var: allow GIT_EDITOR to return null
> + var: do not print usage() with a correct invocation
>
> "git var UNKNOWN_VARIABLE" and "git var VARIABLE" with the variable
> given an empty value used to behave identically. Now the latter
> just gives an empty output, while the former still gives an error
> message.
> source: <pull.1434.v3.git.1669472277.gitgitgadget@gmail.com>
After reading gitworkflows.txt and maintaingit.txt, I take it 'next' is
a proving ground for the larger community to have a chance to suss out
any bugs/regressions. I'm going to assume no further input is needed
from me regarding this topic (unless of course I've got a bug!), but let
me know if I'm mistaken :-) (and thanks to all the folks who've already
provided review!)
Is now a good time to resume the conversation of exposing
GIT_SEQUENCE_EDITOR variable within git-var [1]? I expect the patch to
be mostly the same, but instead following the now-corrected pattern laid
out for GIT_EDITOR (and updated to use the new test helper functions).
Should I then base my branch on 'next' or upon 'sa/git-var-empty'
specifically (now merged to 'next')?
[1]: https://lore.kernel.org/git/pull.1424.git.1668972017089.gitgitgadget@gmail.com/T/#u
--
Sean Allred
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: What's cooking in git.git (Dec 2022, #05; Wed, 14)
2022-12-14 9:59 What's cooking in git.git (Dec 2022, #05; Wed, 14) Junio C Hamano
` (7 preceding siblings ...)
2022-12-15 11:55 ` What's cooking in git.git (Dec 2022, #05; Wed, 14) Sean Allred
@ 2022-12-15 22:45 ` Junio C Hamano
2022-12-15 23:09 ` Junio C Hamano
2022-12-16 15:33 ` ds/bundle-uri-4* (was Re: What's cooking in git.git (Dec 2022, #05; Wed, 14)) Derrick Stolee
10 siblings, 0 replies; 21+ messages in thread
From: Junio C Hamano @ 2022-12-15 22:45 UTC (permalink / raw)
To: git
Junio C Hamano <gitster@pobox.com> writes:
Let's mark the following to "Will merge to 'next'" again.
> * rs/t3920-crlf-eating-grep-fix (2022-12-07) 1 commit
> - t3920: support CR-eating grep
> (this branch uses js/t3920-shell-and-or-fix.)
>
> Test fix.
>
> Will merge back to 'next'.
> source: <cbe88abc-c1fb-cb50-6057-47ff27f7a12d@web.de>
With reviews by Philippe and Eric, this one still looks reasonable.
> * ab/t4023-avoid-losing-exit-status-of-diff (2022-12-05) 1 commit
> - t4023: fix ignored exit codes of git
>
> Test fix.
>
> Will merge back to 'next'.
> source: <patch-v2-3.8-c5feef1c808-20221202T000227Z-avarab@gmail.com>
Simple, obvious and trivially correct.
> * jh/t7527-unflake-by-forcing-cookie (2022-12-02) 1 commit
> - fsmonitor: fix race seen in t7527
>
> Make fsmonitor more robust to avoid the flakiness seen in t7527.
>
> Will merge back to 'next'.
> source: <pull.1437.git.1669937534944.gitgitgadget@gmail.com>
<xmqqfsdgqonk.fsf@gitster.g>.
> * rs/plug-pattern-list-leak-in-lof (2022-12-02) 1 commit
> - list-objects-filter: plug pattern_list leak
>
> Leak fix.
>
> Will merge back to 'next'.
> source: <b4361c3e-852b-e30c-f240-86c34bc9c474@web.de>
Simple, obvious and trivially correct.
> * rs/t4205-do-not-exit-in-test-script (2022-12-02) 1 commit
> - t4205: don't exit test script on failure
>
> Test fix.
>
> Will merge back to 'next'.
> source: <c5b4d091-23c1-5a75-a255-99ec83973d8d@web.de>
Ditto.
> * ab/t5314-avoid-losing-exit-status (2022-12-02) 1 commit
> - t5314: check exit code of "git"
>
> Test fix.
>
> Will merge back to 'next'.
> source: <patch-v2-1.1-ca77a7249e6-20221128T141818Z-avarab@gmail.com>
Ditto.
> * ab/t7600-avoid-losing-exit-status-of-git (2022-12-05) 1 commit
> - t7600: don't ignore "rev-parse" exit code in helper
>
> Test fix.
>
> Will merge back to 'next'.
> source: <patch-v3-1.8-64dfec31fb3-20221202T114733Z-avarab@gmail.com>
Ditto.
> * jh/fsmonitor-darwin-modernize (2022-12-05) 1 commit
> - fsmonitor: eliminate call to deprecated FSEventStream function
>
> Stop using deprecated macOS API in fsmonitor.
>
> Will merge back to 'next'.
> source: <pull.1436.git.1669991072393.gitgitgadget@gmail.com>
This one was updated <pull.1436.v2.git.1671045153981.gitgitgadget@gmail.com>
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: What's cooking in git.git (Dec 2022, #05; Wed, 14)
2022-12-14 9:59 What's cooking in git.git (Dec 2022, #05; Wed, 14) Junio C Hamano
` (8 preceding siblings ...)
2022-12-15 22:45 ` Junio C Hamano
@ 2022-12-15 23:09 ` Junio C Hamano
2022-12-16 15:33 ` ds/bundle-uri-4* (was Re: What's cooking in git.git (Dec 2022, #05; Wed, 14)) Derrick Stolee
10 siblings, 0 replies; 21+ messages in thread
From: Junio C Hamano @ 2022-12-15 23:09 UTC (permalink / raw)
To: git
Junio C Hamano <gitster@pobox.com> writes:
Continuing from the previous one.
> * js/t3920-shell-and-or-fix (2022-12-05) 1 commit
> * sx/pthread-error-check-fix (2022-12-05) 1 commit
> * jk/avoid-redef-system-functions (2022-12-05) 3 commits
> * jk/avoid-redef-system-functions-2.30 (2022-12-05) 2 commits
> * aw/complete-case-insensitive (2022-11-30) 2 commits
These are all simple, obvious and trivially correct.
> * rs/diff-parseopts (2022-12-02) 3 commits
Not exactly trivial but very well explained and easy to follow.
^ permalink raw reply [flat|nested] 21+ messages in thread* ds/bundle-uri-4* (was Re: What's cooking in git.git (Dec 2022, #05; Wed, 14))
2022-12-14 9:59 What's cooking in git.git (Dec 2022, #05; Wed, 14) Junio C Hamano
` (9 preceding siblings ...)
2022-12-15 23:09 ` Junio C Hamano
@ 2022-12-16 15:33 ` Derrick Stolee
2022-12-16 22:55 ` Junio C Hamano
10 siblings, 1 reply; 21+ messages in thread
From: Derrick Stolee @ 2022-12-16 15:33 UTC (permalink / raw)
To: Junio C Hamano, git
On 12/14/2022 4:59 AM, Junio C Hamano wrote:
> * ds/bundle-uri-4-fixup (2022-12-13) 3 commits
> - bundle-uri: remove GIT_TEST_BUNDLE_URI env variable
> - bundle-uri: advertise based on repo config
> - bundle-uri: drop unused 'uri' parameter
> (this branch uses ds/bundle-uri-4.)
>
> Incremental fixes on ds/bundle-uri-4 topic.
>
> Will merge to 'next'?
> source: <pull.1443.git.1670866407.gitgitgadget@gmail.com>
> * ds/bundle-uri-4 (2022-12-06) 11 commits
> - clone: unbundle the advertised bundles
> - bundle-uri: download bundles from an advertised list
> - bundle-uri: allow relative URLs in bundle lists
> - strbuf: introduce strbuf_strip_file_from_path()
> - bundle-uri: serve bundle.* keys from config
> - bundle-uri client: add helper for testing server
> - transport: rename got_remote_heads
> - bundle-uri client: add boolean transfer.bundleURI setting
> - clone: request the 'bundle-uri' command when available
> - t: create test harness for 'bundle-uri' command
> - protocol v2: add server-side "bundle-uri" skeleton
> (this branch is used by ds/bundle-uri-4-fixup.)
>
> Bundle URIs part 4.
>
> Will merge back to 'next'?
> source: <pull.1400.v3.git.1670262639.gitgitgadget@gmail.com>
Please do merge these to 'next'. Things have been stable
since ds/bundle-uri-4-fixup was submitted and I'm currently
polishing part 5 on top of that branch.
Thanks,
-Stolee
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: ds/bundle-uri-4* (was Re: What's cooking in git.git (Dec 2022, #05; Wed, 14))
2022-12-16 15:33 ` ds/bundle-uri-4* (was Re: What's cooking in git.git (Dec 2022, #05; Wed, 14)) Derrick Stolee
@ 2022-12-16 22:55 ` Junio C Hamano
0 siblings, 0 replies; 21+ messages in thread
From: Junio C Hamano @ 2022-12-16 22:55 UTC (permalink / raw)
To: Derrick Stolee; +Cc: git
Derrick Stolee <derrickstolee@github.com> writes:
> On 12/14/2022 4:59 AM, Junio C Hamano wrote:
>
>> * ds/bundle-uri-4-fixup (2022-12-13) 3 commits
>> ...
>> Will merge to 'next'?
>> source: <pull.1443.git.1670866407.gitgitgadget@gmail.com>
>
>> * ds/bundle-uri-4 (2022-12-06) 11 commits
>> ...
>> Will merge back to 'next'?
>> source: <pull.1400.v3.git.1670262639.gitgitgadget@gmail.com>
>
> Please do merge these to 'next'.
Heh, these question marks were meant to invite "wow, now we have
both of these outside 'next', we can fold the 'oops that was wrong'
fix-up patches and redo the base series; thanks for the opportunity
to clean up the history" ;-).
> Things have been stable since ds/bundle-uri-4-fixup was submitted
> and I'm currently polishing part 5 on top of that branch.
OK.
Thanks.
^ permalink raw reply [flat|nested] 21+ messages in thread