On Tue, May 01 2018, Johannes Schindelin wrote: > Hi Ævar, > > On Mon, 30 Apr 2018, Ævar Arnfjörð Bjarmason wrote: > >> I think at this point git-subtree is widely used enough to move out of >> contrib/, maybe others disagree, but patches are always better for >> discussion that patch-less ML posts. > > Sure, it is used widely enough. > > However, it flies in the face of so many GSoC efforts to introduce yet > another one of those poorly portable Unix shell scripts, as central part > of Git's code base. > > The script itself does look quite straight-forward to port to a builtin, > so why not give it a try? That's a valid point. I think it makes sense to leave that aside for now, maybe the consensus is that subtree is fine in every way except we'd like to have a policy not to introduce new shellscript built-ins. Let's first just assume it's in C already and look at it in terms of its functionality, to figure out if it's worth even getting to that point. > If you are completely opposed to porting it to C, I will be completely > opposed to moving it out of contrib/. This series shows that we should split the concern about whether something lives in contrib/ from whether it's built/installed by default. No matter if we decide that subtree should be a blessed default command it makes sense to move it out of contrib, purely because as can be seen from this series it'll replace >100 lines of hacks with 1 line in our main Makefile. We can then just e.g. add a flag to guard for it, e.g. CONTRIB_SUBTREE=YesPlease. But that's just an internal implementation detail of how we manage code sitting in git.git.
