Re: [PATCH] introduce git root

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

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

> ... git rev-parse --show-toplevel is not just long,
> it's just not the place where people would look for (it's neither about
> revision nor about parsing, so clearly, "rev-parse" is not a good place
> to host the feature in the UI).

For the record, "rev-parse" is not about revisions in the first
place.  It started purely as a helper to implement "git log" in
terms of "git rev-list" piped to "git diff-tree --stdin", which
requires you to sift a command line argument list given to such
a scripted "git log" into those to be passed to "rev-list" (i.e.
primarily revision ranges) and those to be passed to "diff-tree"
(i.e. primarily diff options and pathspecs).

Various subcommands "rev-parse" takes such as --show-git-dir were
added only because there wasn't any single best "kitchen sink"
command to tuck such a small feature that do not deserve a
standalone command (e.g. "git root", which makes it sound as if the
top-level of the working tree is the most important thing in the
world, and adding other useful things such as --show-prefix to it,
while it would make sense to have them there from the implementation
point of view, would be hard to justify against the connotation the
word "root" gives us), and we happened to pick "rev-parse" as a
"kitchen sink" place, which is not better or worse as anything else.

If I were redoing this today, I would probably nominate the "git"
potty as such a "kitchen synk" command.  We have "--man-path" that
shows the location of the manual pages, "--exec-path[=path]" that
either shows or allows us to override the path to the subcommands,
and "--show-prefix", "--show-toplevel", and friends may feel quite
at home there.