On Tue, Jun 07, 2022 at 09:43:27PM -0700, Evan Silberman wrote:
> This suggests still further interesting questions about the UI design
> space. git log --pretty has 9 predefined formats, all orthogonal to the
> --decorate flag, plus a formatter language with dozens of tokens
> accessible as well as alignment and color output directives. I'd take it
> as a given that got doesn't want to support _quite_ that much but
> certainly my contribution here doesn't seem like the end of the line
> either. (fwiw this patch makes -s behave basically the same as git log
> --oneline --no-decorate.) I think you'd want to make a design decision
> about what your UI should be for this before even more options and
> combinations of options get into the mix.

We certainly don't need to offer the flexibility Git provides here.
A super-flexibel UI already exists in Git's implementation. There
is no need for us to make a clone of the same thing or something
that is similarly complex. We play the less-is-more card, because
it keeps the implementation simple (less work for us!) and appeals
to the target audience.

I feel like log -s is an option for people who don't want to run tog,
but still want to see a quick overview of recent history and perhaps
search through it in less(1). Which is why I suggested to make log -s
output look a bit more like tog for consistency.

Adding a graph to log -s in the future would be nice. We currently
don't have an output mode which would be suitable for displaying a
merge graph, and this patch adds what would be needed.

Perhaps we could optionally display a graph in tog's log view.
But it would be easier to prototype code for this in log -s because
drawing to the display via ncurses is a slightly more tricky.

Would your use of log -s be impacted in any way if the output was
changed? For example, if reference names were shown instead of
commit hashes if available, would that break something in your
workflow or scripting around this?