Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > In any case, as stated before, I would like to see this feature be > implemented as a `git log` (or even `git rev-list`) option before > implementing a dedicated command. > > In other words, this new feature should be treated as a _mode_ rather than > a new command. The command can come later, just like `git whatchanged` > is essentially a special-case version of `git log`. Yup, I agree that we may have plenty of commands that this can become a feature of, and if there is a good match, we should make it a mode of an existing command, and "git log" might be a natural first candidate. If the focus is on the "recent topics in flight", "git show-branch" might be a good home. There may be some other candidates. On the other hand, this thing may be sufficiently different from everything else and deserves to be a separate command, just like nobody would think it is a sane design choice to try making "git shortlog" a mere mode of "git log". An unrelated tangent, but I wonder if we want to start drafting the transition plans to deprecate whatchanged. The command was invented about two weeks before "log", but back then the latter did not know how to drive diff-tree (iow, it was only about the commit log messages), so they have both stayed to be "useful" for some time, until the underlying machinery for "log" matured sufficiently and made "whatchanged" more or less a special case of "log". It is not hurting right now to keep it as-is and unmaintained, though.
