FR: Allow for setting --reversed globally in the config file

[barakmich]

Is your feature request related to a problem? Please describe.

I set my ui.default_command to be log --reversed (even as suggested in the documentation) and I really like the reversed style. While there's also recent work related to reversing (eg, #5170), it would be nice to make reversing log order a global option, especially for when I'm running jj log -r QUERY and then forget to add --reversed every time.

Describe the solution you'd like

A configuration option for what seems to eventually be a family of --reversed flags, to invert their behavior. Some examples include:

ui.always_reversed = true
ui.top_to_bottom = true

Or if not globally, a consistent flag for each subcommand

log.default_reversed = true

(but it feels more ui to me 🤷)

[PhilipMetzger]

I don't think this will be possible, see #1509. You can always use a custom log alias for it though.

[yuja]

And it's unlikely we'd want to see op log or log -r 'all()' in reverse order. I don't think --reversed by default would be worth the UI mess it would add.

[barakmich]

I do think it's useful in both those cases: log -r 'all()' is going to be a mess either way if it's really branchy or really long. Similar the op log

I think the underlying point to my request -- trying to take it from your perspective -- is that if you're printing it straight to console having the most recent things, op log or log, is really handy to have the latest stuff the one or two lines above where you're typing. So I disagree that this is universally unlikely.

However, I can also see that, using the tool in a script or pipeline to head/less or something, it's easier/preferable to put the most recent at the top.

The semi-underlying issue being that, if you run jj log -r 'all()', and it's too long, much like git, it will use a pager. Which is probably correct behavior, as well.

So we come back around to, maybe I'm just a minority, but, considering you advertise the option in the docs, it's really really helpful when taking a quick look around with default-command because it will print to console. So then it's confusing to folks getting used to the tool, and what one sees most frequently.

I'm closing the issue myself, but noting that while I think jj is great and going to do well, this felt really dismissive 😞

[ilyagr]

Just to expand on Philip's "alias" suggestion (sorry if you already figured this out), that would be:

[aliases]
logr = ["log", "--reversed"]
evologr = ["evolog", "--reversed"]  # Once implemented

[ui]
default-command = ["logr"]

Then, you can use jj logr instead of jj log. (I also think jj op logr will work because of how aliases are parsed, or it could have its own alias).

One upside of relying on aliases is that if you mention jj log to other people, it should work for them more or less the same as it works for you, and if you mention jj logr you will probably remember it's an alias the other person might not have. That might be the "UI mess" Yuya was referring to, I'm not sure.

One unfortunate downside of aliases is that they currently mess up shell completion, at least as of a few weeks ago. I believe this is being worked on, so I might be out of date; either way, the hope is that this will be fixed at some point in the future.

[yuja]

I do think it's useful in both those cases: log -r 'all()' is going to be a mess either way if it's really branchy or really long. Similar the op log

Just to be clear, I meant it would be unlikely because of performance reasons. --reversed graph can't be rendered without scanning all the graph nodes. It's only reasonably useful when the output is filtered by -r or the default revset.

And the UI cost we would have to pay is that we would need --no-<flag> for all boolean flags that can be flipped by configuration.

[arxanas]

Actually, I was going to change the default for git-branchless to have a reversed configuration option rather than a --reversed flag in arxanas/git-branchless#1315 (comment). (I should probably return to that PR... in fact, we could try to use a deprecation notice there to gain insight into workflows here, if we think it's valuable to do so.)

I do agree that reversing the output makes sense for a certain class of user's workflows (including me), although I'm sympathetic to the "UI cost" argument.

I set my ui.default_command to be log --reversed (even as suggested in the documentation)

[observation] I'm not sure if that suggestion was originally meant to advocate for reversing vs not reversing, vs just showing a helpful practical example of configuring your log output. I agree that the documentation sounds like it's recommending it as the default 👀.

Just to be clear, I meant it would be unlikely because of performance reasons. --reversed graph can't be rendered without scanning all the graph nodes. It's only reasonably useful when the output is filtered by -r or the default revset.

One of the differences between git-branchless and jj that's relevant here is that git-branchless's log output by default tries to limit it to just "your" work, rather than all nodes, so it makes more sense to reverse the output via a configuration option.

---

I'm closing the issue myself, but noting that while I think jj is great and going to do well, this felt really dismissive 😞

@barakmich Sorry to hear this. I don't think it was necessary to close the issue based on the discussion comments so far, which is perhaps a cultural difference for those inside and outside the project?

For this discussion, I'll reopen it for now to invite commentary from anyone else who may be interested in providing their feedback.

• If adopting the proposal in its current form, I think we would have to address the design concerns discussed above.
• Regardless, it would at least be good to hear if the --reversed-on-all-commands workflow is something that's currently unhandled for many users, even if we can't resolve the feature request in its current form.
• We can keep this open indefinitely if the fundamental workflow/UI issue remains unsolved, or migrate it to a Discussion or close it if we think we've achieved consensus.

I have found that many issues and proposals on fairly "basic" things get a lot of discussion about the topic itself, but also —

• relevant topics on different levels of abstractions
• reevaluations of whether the underlying version control concepts still apply to jj
• evaluations of feature and UI bloat, etc.
• discussion of whether the topic might be generalized into something in the distant future
• etc.

I think this is to be expected for a project at jj's stage, where not all of the design and UI principles have been fully established.

• Example: we will probably replace/supplant branches/bookmarks with some other design for managing related commits (such as "topics", and I myself have proposed a competing design). This means that a lot of simple requests for branches might devolve into discussions about whether we should implement a certain feature for branches at all, or other bikeshedding.

Was that in line with your expectations for the project? (You might also have just gotten unlucky with two immediate negative comments?) Do you think it's possible to convey those expectations to new users (perhaps via a comment in the feature request template)?

[yuja]

One of the differences between git-branchless and jj that's relevant here is that git-branchless's log output by default tries to limit it to just "your" work, rather than all nodes,

That's also true for jj. The default jj log might be nice if rendered in reverse (depending on your preference.) The problem is that jj log can also be used as a command to query revisions of arbitrary length, and it's weird if ui.reversed = true were applied only to the default jj log (with no options.)

[arxanas]

@barakmich I'm curious if you think adopting an alias (as described in #5203 (comment)) would work for your workflow? That's probably what I would do.