From: Stefan Sperling Subject: Re: [patch] add a one-line-per-commit output mode to log To: Evan Silberman Cc: gameoftrees@openbsd.org Date: Wed, 8 Jun 2022 11:03:06 +0200 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?