On Fri, Apr 23, 2021 at 7:28 PM Luke Shumaker <lukeshu@xxxxxxxxxxx> 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.
