Thread (139 messages) 139 messages, 5 authors, 2021-04-30

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

From: Luke Shumaker <hidden>
Date: 2021-04-23 23:28:30

On Fri, 23 Apr 2021 14:31:46 -0600,
Eric Sunshine wrote:
On Fri, Apr 23, 2021 at 3:43 PM Luke Shumaker [off-list ref] wrote:
quoted
That was nice to have when git-subtree lived out-of-tree.  But now that
it lives in git.git, it's not nescessary to keep around.
s/nescessary/necessary/
Ack.
quoted
Signed-off-by: Luke Shumaker <redacted>
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.

-- 
Happy hacking,
~ Luke Shumaker
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help