Message ID | pull.830.v3.git.1610136177.gitgitgadget@gmail.com (mailing list archive) |
---|---|
Headers | show |
Series | Remove more index compatibility macros | expand |
"Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com> writes: > UPDATE: this is now based on ag/merge-strategies-in-c to avoid conflicts in > 'seen'. The changes in builtin/rm.c still conflict with > mt/rm-sparse-checkout, but that branch seems to be waiting for a clearer > plan on some corner cases. I thought about ejecting it, but 'rm' still uses > ce_match_stat(), so just dropping the patch gives less of a final stake at > the end of the series. (I'm still open to it, if necessary.) I haven't read this latest iteration myself yet beyond the cover letter, but tonight's 'seen' has this queued near its tip. I expect it would either stay there or occasionally ejected, until the base topic solidifies a bit more. > * Methods that know about the 'repo' pointer no longer also have an > 'istate' pointer and instead prefer 'repo->index' > > * This includes the callback_data struct which only has a 'repo' member, no > 'istate'. OK.
On Sun, Jan 10, 2021 at 2:03 AM Junio C Hamano <gitster@pobox.com> wrote: > "Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com> writes: > > UPDATE: this is now based on ag/merge-strategies-in-c to avoid conflicts in > > 'seen'. The changes in builtin/rm.c still conflict with > > mt/rm-sparse-checkout, but that branch seems to be waiting for a clearer > > plan on some corner cases. I thought about ejecting it, but 'rm' still uses > > ce_match_stat(), so just dropping the patch gives less of a final stake at > > the end of the series. (I'm still open to it, if necessary.) > > I haven't read this latest iteration myself yet beyond the cover > letter, but tonight's 'seen' has this queued near its tip. I expect > it would either stay there or occasionally ejected, until the base > topic solidifies a bit more. > > > * Methods that know about the 'repo' pointer no longer also have an > > 'istate' pointer and instead prefer 'repo->index' > > > > * This includes the callback_data struct which only has a 'repo' member, no > > 'istate'. > > OK. I looked this version of the series over and did not find anything else about which to comment.
On 1/10/2021 2:03 AM, Junio C Hamano wrote: > "Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com> writes: > >> UPDATE: this is now based on ag/merge-strategies-in-c to avoid conflicts in >> 'seen'. The changes in builtin/rm.c still conflict with >> mt/rm-sparse-checkout, but that branch seems to be waiting for a clearer >> plan on some corner cases. I thought about ejecting it, but 'rm' still uses >> ce_match_stat(), so just dropping the patch gives less of a final stake at >> the end of the series. (I'm still open to it, if necessary.) > > I haven't read this latest iteration myself yet beyond the cover > letter, but tonight's 'seen' has this queued near its tip. I expect > it would either stay there or occasionally ejected, until the base > topic solidifies a bit more. Thanks. I'll continue to watch that topic and provide review as new versions come out. -Stolee
On 1/10/2021 2:03 AM, Junio C Hamano wrote: > "Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com> writes: > >> UPDATE: this is now based on ag/merge-strategies-in-c to avoid conflicts in >> 'seen'. The changes in builtin/rm.c still conflict with >> mt/rm-sparse-checkout, but that branch seems to be waiting for a clearer >> plan on some corner cases. I thought about ejecting it, but 'rm' still uses >> ce_match_stat(), so just dropping the patch gives less of a final stake at >> the end of the series. (I'm still open to it, if necessary.) > > I haven't read this latest iteration myself yet beyond the cover > letter, but tonight's 'seen' has this queued near its tip. I expect > it would either stay there or occasionally ejected, until the base > topic solidifies a bit more. Junio, Please drop this series for now. I'll be introducing a new series soon that will collide with it and this is a lower priority. I'll probably come back to revisit removing these macros, but I'll do so one builtin at a time when others are not modifying them at the same time. Thanks, -Stolee