Re: [PATCH 0/4] subtree: move out of contrib

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: May 1, 2018, 12:48 UTC
Message-ID: <877eonzgm6.fsf@evledraar.gmail.com>
In-Reply-To: <nycvar.QRO.7.76.6.1805011338490.79@tvgsbejvaqbjf.bet>

On Tue, May 01 2018, Johannes Schindelin wrote:

Show 16 quoted lines

> 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.