On Fri, Apr 23, 2021 at 7:28 PM Luke Shumaker [off-list ref] wrote:

On Fri, 23 Apr 2021 14:31:46 -0600, Eric Sunshine wrote:

quoted

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.