[v1,0/3] War on dashed-git

Message

Junio C Hamano Aug. 26, 2020, 1:17 a.m. UTC

If we were to propose breaking the 12-year old promise to our users
that we will keep "git-foo" binaries on disk where "git --exec-path"
tells them, we first need to gauge how big a population we would be
hurting with such a move.

So here is a miniseries towards that.  The third one hooks to the
codepath in git.c::cmd_main() where av[0] is of "git-foo" form and
we dispatch to "foo" as a builtin command.  In the original code, we
will die() if "foo" is not a built-in command in this codepath, so
it is exactly the place we want to catch remaining uses of "git-foo"
invoking built-in commands.

There are a few legitimate "git-foo" calls made even for built-ins
and those exceptions are marked in the command-list mechanism, which
is shared with the help subsystem.  We might want to see if we can
unify this exception list with what we have in the Makefile as
BIN_PROGRAMS and what Dscho introduces as ALL_COMMANDS_TO_INSTALL
in his series.  These have large overlaps in what they mean, but
they are not exactly identical.

Junio C Hamano (3):
  transport-helper: do not run git-remote-ext etc. in dashed form
  cvsexportcommit: do not run git programs in dashed form
  git: catch an attempt to run "git-foo"

 command-list.txt         | 11 +++++++----
 git-cvsexportcommit.perl | 16 ++++++++--------
 git.c                    |  2 ++
 help.c                   | 34 ++++++++++++++++++++++++++++++++++
 help.h                   |  3 +++
 transport-helper.c       |  3 ++-
 6 files changed, 56 insertions(+), 13 deletions(-)

Comments

Johannes Schindelin Aug. 26, 2020, 8:09 a.m. UTC | #1

Hi Junio,

On Tue, 25 Aug 2020, Junio C Hamano wrote:

> If we were to propose breaking the 12-year old promise to our users
> that we will keep "git-foo" binaries on disk where "git --exec-path"
> tells them, we first need to gauge how big a population we would be
> hurting with such a move.
>
> So here is a miniseries towards that.  The third one hooks to the
> codepath in git.c::cmd_main() where av[0] is of "git-foo" form and
> we dispatch to "foo" as a builtin command.  In the original code, we
> will die() if "foo" is not a built-in command in this codepath, so
> it is exactly the place we want to catch remaining uses of "git-foo"
> invoking built-in commands.
>
> There are a few legitimate "git-foo" calls made even for built-ins
> and those exceptions are marked in the command-list mechanism, which
> is shared with the help subsystem.  We might want to see if we can
> unify this exception list with what we have in the Makefile as
> BIN_PROGRAMS and what Dscho introduces as ALL_COMMANDS_TO_INSTALL
> in his series.  These have large overlaps in what they mean, but
> they are not exactly identical.

As it happens, I discussed a scenario the other day where dashed
invocations might still happen, and the consensus was that nobody looks at
the output unless things are broken.

So maybe this patch series would be a good first step, but if we truly
wanted to break that 12-year old promise, we might need to have another
patch on top that _does_ install the dashed commands, but into a
subdirectory of `libexec/git-core/` that is only added to the `PATH` when
an "escape hatch"-style config setting is set.

Ciao,
Dscho

Junio C Hamano Aug. 26, 2020, 4:45 p.m. UTC | #2

Johannes Schindelin <[e-mail]> writes:

> So maybe this patch series would be a good first step, but if we truly
> wanted to break that 12-year old promise, we might need to have another
> patch on top that _does_ install the dashed commands, but into a
> subdirectory of `libexec/git-core/` that is only added to the `PATH` when
> an "escape hatch"-style config setting is set.

Yes, I think that is a much more reasonable approach.  Instead of
checking another environment variable that does not do anything but
bypass the "you used dashed form for builtin" check, we install non
builtins in libexec/git-core and leave the exec-cmd.c::setup_path()
as-is to add it to the PATH.  A new location will have the buitlin
binaries, say in libexec/git-core/builtins, and it is not added to
the $PATH by us.  The scripts that the users updated 12-years ago by
adding the former to the $PATH now needs to also add the latter,
too, and those users will loudly complain (which is what we want to
see happen [*1*]), but doing so is an easy way to unbreak them while
we reverse the course.

I think the cvsexportcommit and transport-helper changes are worth
salvaging even if we don't remove builtin binaries, so I'll split
them and whip them a bit more into a reasonable shape to be merged
to 'next'.  The "break those who say 'git-cat-file'" can be left for
future.

Thanks.


[Footnote]

*1* In the ancient thread, I was sick of hearing complaints that
beat the dead horse, but in this particular case, we do want to hear
from them---that is the primary reason why we are doing it.

https://public-inbox.org/git/[e-mail]/