On Monday, May 6, 2024 1:13 PM, Junio C Hamano wrote: >Patrick Steinhardt <ps@xxxxxx> writes: > >> ... I was pondering >> whether we want to introduce a document as part of that patch series >> that starts to keep track of upcoming removals for a potential Git 3.0 >> release. > >Finally somebody has bit it ;-) In the 2.44 cycle, I wrote > > The RelNotes symbolic link says we are now working towards Git 2.44. > It may not be a bad idea to reflect on what technical debt and UI > warts we have accumulated so far to see if we have enough of them to > start planning for a breaking Git 3.0 release (or, of course, keep > incrementally improve the system, which is much more preferrable--- > continuity and stability is good). End of year being a relatively > quiet period, it may be a good time to think about your favorite pet > peeve, to be discussed early next year. > >in a few of the "What's cooking" reports. > >> There are multiple items that could be added: >> >> - Removal of the old syntax of git-config(1). >> >> - Removal of the dumb HTTP transport. >> >> - Removal of `info/grafts`. >> >> There are probably other items. > >A list of things I can think of that I won't be the primary advocate for but I do not >mind too terribly if we had champions for the topics are attached at the end. > >> In any case, the old actions are here to stay for the foreseeable >> future until we commit to a breaking major release. > >True. > >> Thanks for the thorough explanation, I have nothing to add! > >You could have avoided it if you copied some from the initial cover letter to each >round (i.e. preparing the series to be read by some folks who did not read an earlier >round). > > >Possible additional Git 3.0 items: > > - Removing "git http-push" to push over HTTP/DAV. > > - Removing support of `$GIT_DIR/branches/` from remote.c API. > > - Removing "git update-server-info". > > - Removing "git annotate". I must have missed this... I thought annotate was replacing blame. > - Removing "gitweb" and "git instaweb". > > - Removing "git filter-branch", now we have a better alternative > "git filter-repo". > > - Removing discovery of hook script in "$GIT_DIR/hooks/", in favor > of the configuration variables that point at them. > > - Switching to SHA-256 as the default hash algorithm. > > - Switching to reftable as the default ref backend. > > - Switching the hardcoded default branch name away from "master" to > "main". > > - Declaring that "git restore" and "git switch" were failed > experiments and deprecating them. This restore and switch have broad use in my community. I do not consider them failed experiments at all, but essential in scripts and usage. Removing these would block migration to git 3, in my view. I have actually been thinking about doing a YouTube video on these commands. > - Declaring that "git submodule" was a failed experiment and > deprecating it. This would be a very high-impact decision. Aside from my community's use (and my own company's dependence on submodules), this will break large numbers of GNU-based projects that use submodules for distribution, including build-aux. I would suggest staying away from this decision. Submodules have definite value. Please keep them. If you really want to get rid of stuff that has limited use instead of submodules, it is worktrees, the benefit of which is reduced given sparce checkouts and fetch depth. --Randall
