Re: [PATCH 14/30] subtree: drop support for git < 1.7

[Eric Sunshine <sunshine@sunshineco.com>]

On Fri, Apr 23, 2021 at 7:28 PM Luke Shumaker <lukeshu@lukeshu.com> wrote:
> On Fri, 23 Apr 2021 14:31:46 -0600, Eric Sunshine wrote:
> > Is there a higher reason for this change aside from "let's do it
> > because we can"? For instance, are subsequent changes going to take
> > advantage of features only present in more recent Git versions which
> > would be painful or impossible to support with the older Git?
> >
> > The downside of this change is that, while git-subtree may live in
> > git.git, it's still just "contrib", so people might grab git-subtree
> > from a modern git.git but then end up using it with an older Git
> > installation. That's not to say that doing such a thing is guaranteed
> > to work anyhow, but we don't need to make it harder on people if there
> > isn't a good reason (hence my question about whether subsequent
> > changes will actually take advantage of newer Git features).
>
> With the goal of making the whole thing easier to hack on, this just
> seemed like an easy (if small) piece of fat to trim.
>
> I guess I should include here that my bias is: With the 'git' package
> that Parabola inherits from Arch Linux, you install 'git', you get a
> working 'git subtree'.  If you want 'git send-email' to work, you also
> need to install several other Perl packages.  Like, it might live in
> the "contrib" directory, but it's de-facto at least as much a "part
> of" Git as send-email is.
>
> So that's the mindset I started from.  It looks like the latest macOS
> supports me on that, but other distros like Fedora don't (Fedora has a
> separate 'git-subtree' package).  If I take a step back, I realize
> that mindset is flawed, but that's where I started from.
>
> I don't think any of the other work depends on this (I think the only
> commit that will conflict if we drop it is the "rename a some
> variables" commit in this patchset).  It's very possible that
> something else I do relies on newer git features (I'm not testing
> against older git), but that's not something I did intentionally.
>
> I just figured this would be a welcome piece of cleanup.  If that's
> not the case, I don't have a problem dropping it.

As a person who does not and has never used git-subtree, I don't have
a strong opinion, and any git-subtree opinion I might have wouldn't
carry any weight. I do have a bit of reflexive negative reaction to
such removals in general if there's no clear and strong benefit,
perhaps because my daily-use computers are old (perhaps ancient, as in
10-25 years old), so I am regularly stung by support being dropped by
packages I use. That's why I was asking if later patches would take
advantage of some newer Git feature.

Anyhow, I wasn't specifically asking for the patch to be dropped. As a
reviewer I rather wanted to better understand the reason for the
change beyond the somewhat hand-wavy "git-subtree now lives in-tree".
If you happen to re-roll, perhaps you can expand the commit message a
bit with something more concrete (for instance, how some packagers
include git-subtree by default) to better sell the patch to reviewers
who actually have investment in git-subtree (of which I am not one).
Considering how old Git <1.7 is, it's quite likely that no current
git-subtree users/reviewers would care about dropping support for such
old versions.