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

[Patrick Steinhardt <ps@pks.im>]

[-- Attachment #1: Type: text/plain, Size: 4772 bytes --]

On Mon, May 06, 2024 at 10:13:25AM -0700, Junio C Hamano wrote:
> 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.

> > 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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]