On Mon, May 06, 2024 at 10:13:25AM -0700, 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. I know :) I have been thinking about this on and off, but never felt like pushing for it yet. > > 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. I'd be happy to champion for each of those. > > 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). Fair enough. I should have known that this part is indeed quite important to the whole series and included it in the newer cover letters. > > Possible additional Git 3.0 items: Some pretty controversial takes in here ;) I guess that's by design. > - Removing "git http-push" to push over HTTP/DAV. > > - Removing support of `$GIT_DIR/branches/` from remote.c API. > > - Removing "git update-server-info". Yes, all of these are quite sensible. > - Removing "git annotate". I don't care much about this one, but it's nice indeed to get rid of duplicate functionality. > - Removing "gitweb" and "git instaweb". I don't care about this one, to be honest. It's basically unmaintained though as far as I know, so we might just be accepting the status quo. > - Removing "git filter-branch", now we have a better alternative > "git filter-repo". This one I'm sceptical about. The one upside of git-filter-branch(1) is that it's part of Git itself, whereas git-filter-repo(1) is not. I thus think that a prerequisite here should be that we first land the new script in Git before actually deprecating the old tool such that things remain discoverable. And upstreaming git-filter-repo(1) would be a worthy goal by itself already. > - Removing discovery of hook script in "$GIT_DIR/hooks/", in favor > of the configuration variables that point at them. Those have been an attack vector in the past, and I think that using config to set up hooks is quite a bit saner. But of course, we first need to land this topic :) > - 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". All three of those may be nice. The first one is going to be hardest as it requires support in forges. GitLab started to support SHA256 a month ago, but it's still experimental. But to the best of my knowledge GitHub does not yet support SHA256 at all. > - Declaring that "git restore" and "git switch" were failed > experiments and deprecating them. I use those quite a lot, so it'd be a shame if those went away. > - Declaring that "git submodule" was a failed experiment and > deprecating it. Well. I know that most people think that submodules don't work and should just go away, and I count myself as part of that group. But realistically I don't see that as a feasible goal, even more so because we don't actually have a proper replacement. They may be somewhat broken, but there is no better substitute. You know, let me take this list and propose it as something like "Documents/UpcomingDeprecations". This will make the whole discussion here a lot more discoverable. Patrick
Attachment:
signature.asc
Description: PGP signature
