Re: [PATCH] contrib: drop hg-to-git script

[Junio C Hamano <gitster@pobox.com>]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> While I have no objection to dropping this script, I am reluctant to drop
> it without leaving anything helpful in place. I am thinking about
> something like a `README.md` that would contain helpful information for
> any interested reader.

Years ago, I lost the illusion that our tree is the place for all
users who want to improve their Git experience to come and they try
to find related software in our contrib/ section.

Those with specific needs (e.g., "A project uses Mercuial; I want
its history in Git because I am used to it more") will never come to
our contrib/ as their first place to look, but they may still find
us in https://letmegooglethat.com/?q=mercurial+to+git if we left an
otherwise empty directory there.

Those with curiosity without specific needs (e.g., "what kind of
interesting enhancements around Git are there") are unlikely to come
to our contrib/ section either, as it offers too small a collection,
but more importantly, a directory with README and nothing else is
one more place they have to look at for no interesting information.
If we want to be really helpful to these folks, we need a curated
collection that is properly maintained.

While some directories under contrib/ may have been well maintained,
I do not think we have been good stewards for most directories in
there that do not have upstream author's involvement in maintaining
them.  If 6 months down the road a better alternative for cinnabar
or remote-hg appears, I doubt anybody will update such a README file
to add mention of it.  Even if it did, I highly doubt anybody will
come to our contrib/ area to find out about it---they will find out
about it elsewhere.

I am aware that we have precedence.  contrib/hooks/multimail and
contrib/emacs are two examples that lost almost everything but still
have tombstone README.  But these README are not kept up to date to
help their intended audiences.  The only people it _might_ help to
have such tombstone README are those who say "Oh, I thought we had
Hg to git in contrib/---what happened to it?" and they are better
served by "git log contrib/" that will find the commit that explains
why we decided to drop it back when we did.

>> The hg-to-git script is full of command injection vulnerabilities
>> against malicious branch and tag names. It's also old and largely
>> unmaintained; the last commit was over 4 years ago, and the last code
>> change before that was from 2013. Users are better off with a modern
>> remote-helper tool like cinnabar or remote-hg.

The approach will not give them any false expectation that the
"modern tool" are updated in the historical record to tell them
about better alternative that appeared after hg-to-git was removed,
unlike tombstone README that we _could_ be maintaining but without
any intention to do so.

So, I dunno.  I very much appreciate your desire to be helpful to
the users, but in this case the effort is misguided and not being
helping the users very much.  

If we were a major part of the sources for Git related information
and there were little external information, READMEs that are
somewhat stale were much much better than no READMEs at all.  But
such days are over a decade ago and having README that we plan to
let go stale has dubious value, I would have to say.