Re: [PATCH v4 07/14] builtin/config: introduce "list" subcommand

From: Patrick Steinhardt <ps@pks.im>
Date: May 7, 2024, 04:02 UTC
Message-ID: <Zjmn7_C_eiSo0rBL@tanuki>
In-Reply-To: <xmqqttjazwwa.fsf@gitster.g>

On Mon, May 06, 2024 at 10:13:25AM -0700, Junio C Hamano wrote:

Show 19 quoted lines

> Patrick Steinhardt <ps@pks.im> 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.

Show 13 quoted lines

> > 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.

Show 10 quoted lines

> > 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.

Show 5 quoted lines

>  - 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 :)

Show 6 quoted lines

>  - 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