Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html