Show the rebase

[sullyj3]

Every time I do a rebase, I immediately run jj log to verify that I got the result I was expecting.

I think it would be nice if jj rebase did this automatically. It could just log the revset consisting of the base and the rebased commits. We could make this behaviour opt-out, or even opt-in if it's very controversial.

As a matter of UX, it's nice to have feedback about the operations I perform. It gives me confidence in my use of the system. The "Rebased n commits" message is good, but I think additionally showing those commits, and the commit they were rebased onto, would be even better.

[emilazy]

I think I would like this. If nobody is against this do you think you’d be up for writing a patch?

[sullyj3]

Yep, for sure

[PhilipMetzger]

While I do think that this is a nice improvement, you also could the fix root cause by implementing jj git sync (#1039), as then this would be entirely unnecessary.

[emilazy]

There are other uses of rebase where this could still be useful, e.g. doing cherry‐picks or (especially) reordering commits.

[sullyj3]

Yeah, it came up for me in the context of a long lived local feature branch.

[PhilipMetzger]

Ok, then unnecessary was to a harsh categorization although you also could solve it via revset (which would be similar to #2871).

[sullyj3]

Sorry, I'm not quite following how that ticket addresses this problem?

[PhilipMetzger]

It does not, but we could have a symbol in the revset language for the last rebased symbol which is similar in spirit.

[joyously]

Maybe this could be a --verbose flag?

[sullyj3]

I could live with a config setting as a compromise

[emilazy]

I would prefer to have it be there by default and obey --quiet like other commands. It’s in line with the other brief status output commands give.

I’m not sure how it should behave if you rebase really large branches though; opening a pager feels awkward. Perhaps it should show truncated output if there are more than n commits rebased, for some arbitrary n.

[arxanas]

I'm not personally opposed to using a flag, but I don't think the flag should be --verbose for this case. I think of that flag as including more detailed (textual) output for the operation itself, rather than the rendering of the operation for UI purposes. For example, perhaps you prefer to list all of the rebased commits instead of just showing Rebased n commits..

[joyously]

For example, perhaps you prefer to list all of the rebased commits instead of just showing Rebased n commits..

I thought that is what I was referring to.

[arxanas]

You're right; a list of all rebased commits is essentially just a log rendering. The main thing is that I think rendering a list/log of commits shouldn't be controlled by a --verbose flag, as I feel that --verbose is more for detailed output as part of executing a command than for the format of its results.

[arxanas]

This is actually the default behavior for git-branchless! Therefore, I'll give an experience report on it.

I implemented it because I noticed that I was constantly running git sl after running various commands.

• See https://github.com/arxanas/git-branchless/wiki/Configuration#branchlesssmartlogdefaultrevset, where it mentions that the smartlog is implicitly printed after some commands.
  • Admittedly, the feature itself is not well-documented, but it's hard to not notice after using git-branchless for even a short period of time 🤣.
  • It includes not only git-branchless move, but navigation commands like next/prev/switch.
  • It might include others; in particular, I don't remember if it runs as part of the post-rewrite hook, which would happen even after stock git rebase. I think it doesn't (but maybe it should).
• Note that jj lets you configure the default command to run if you just type jj, which is a great way to quickly orient yourself.
  • I think this feature was copied from Sapling? Which lets you run sl with no arguments to print the smartlog.
  • git-branchless doesn't have anything like that. If it did, perhaps I wouldn't have implemented this feature for git-branchless?
• I'd suggest that the proponents in the thread to also try using jj with no arguments and report back on how it feels, and whether they find that it reduces the need for this kind of feature.
  • I typically don't use the jj log myself, so I don't know how well it works personally.
• Similarly, I'd be interested to know if proponents of the feature also tend to immediately print the log after navigation commands like new/edit/next/prev as well.

---

The most serious problem was the time that one of my coworkers tried to use git-branchless for a bunch of big in-memory rebases as part of automation, and then it hung at the end due to the implicit smartlog printing, and they had to turn it off to get the operation to complete 🤣.

• While there's not anything technically wrong with printing the extra log output, I get the feeling that this behavior should not be part of the output for automation.
  • One way is to simply make the feature opt-in, so then hapless users don't ruin their automation scripts by not thinking about this situation,
    • but simply opting in for the interactive use-case doesn't necessarily mean that you wanted to opt in for the automation use-case as well.
  • A better alternative is to support a certain flag or environment variable that should be used by all automation commands.
    • I think Mercurial has HGPLAIN for this purpose?
• The main thing is to reduce cognitive overhead when designing/building automation that uses jj. This feels like a sensitive design area in that respect.
  • This is an argument in favor of opt-in configuration.

---

One concrete problem is that it might consume all of the user's available terminal scrollback.

• Even if it doesn't consume all the scrollback, it can make skimming through the output of previous commands annoying.
  • I haven't seen anyone specifically complain about it, but I've noticed problems personally.
• I could easily see users becoming annoyed that jj is so verbose by default, to the point of making the rest of their terminal usage less productive.
  • This is an argument in favor of opt-in configuration.

---

Lately, I notice that the output is quite unhelpful when the entire smartlog becomes unwieldy and the full output doesn't fit on my screen.

• Note that git-branchless's smartlog doesn't show the full repository history by default.
  • I mean that I have like 100 draft commits, including some ugly-to-render merge commits.
  • I can reconfigure the default revset (such as to show only the current stack), but then it affects the default smartlog output.
    • It probably should have been a different configuration option, at least. There was a great deal of "path of least resistance" design here 😅.
• It's certainly possible to trim the output and configure the revsets appropriately.
  • The suggestion "It could just log the revset consisting of the base and the rebased commits" or similar seems like a good idea,
    • but if we find that we want the behavior for other commands as well (like next/prev/new), then this idea doesn't transfer.
• The main point is that I wonder if it's really suitable to have a single revset be responsible for the visualization behavior.
  • Is it possible that you want to see very different things depending on the command you run, or just depending on what you happening to be doing/working on lately?
  • I'm not trying to suggest anything in particular here, just caution that we need to be quite careful when changing the default UI/UX for this workflow. It becomes tedious to reconfigure it if it's doesn't suit you.

---

We would almost certainly want to make "reversing" the log output into a configuration option that's respected here.

• It's currently available as a flag to jj log. It doesn't look like it's available as a configuration option, as far as I can tell.
• This is my preference and at least a few other peoples', although I get the sense that it's not the majority opinion.
  • I think many people don't care, since the git-branchless default (reversed) is the opposite of the jj default, but we don't hear that many voices complaining on either side.

---

There are some potential context-dependent hints we could surface.

• If opt-in:
  • When we invoke jj log, we should (?) be able to look at the operation log and see if it was recently preceded by jj rebase or a similar operation. If that happens often enough, then we could start surfacing a hint to enable the feature in question.
  • Another simple heuristic is the ratio of jj log to non-jj log invocations 👀.
  • I do feel that the feature is useful enough that many people might want it, and also would be simultaneously rather hard to learn about if you weren't specifically looking for such an option.
    • This is an argument in favor of opt-out configuration.
• If opt-out:
  • We can just indiscriminately print a hint after the output explaining how to disable the extra output.
  • In all cases, hints should explain how to disable themselves (which you would use if you wanted to keep the extra output).

---

Overall, my preference would be for opt-in configuration with clever hinting, or some other effective onboarding strategy.

[arxanas]

I think the utility of the feature is inversely correlated with how much output it produces, which is unfortunately very dependent on whatever I happen to be doing 😅. It's great when it actually helps me determine something at a glance... but it's hard to tune such a feature to only produce output when a human would find it to be "useful".

When I do a 20-commit rebase, it's actually not very helpful to see the exact list of 20 commits again. There might be something clever with just showing the "changed" sections, like just showing the new base and its immediate child which was just rebased. But determining the set of "interesting" commits in that case can be difficult when you insert commits into arbitrary places as part of the operation.

---

I forgot to discuss in the parent post, but there's the general question of "how much output should a command produce, in terms of the input size"?

• IIRC Git will print a list of all the changed files when you do a commit/merge/etc.
  • It definitely helps you get a sense for the size of the change, but it can be very spammy, and actually induce significant overhead when you do big operations in terms of just printing everything (and rendering in the terminal, or streaming over SSH, etc.).
• IIRC Mercurial defaults to much more concise output,
  • but then you might find yourself frequently needing to confirm operations manually.

There's probably a few tiers:

• Constant amount of output ("rebased n commits").
• Linear in the size of the change to the commit graph (listing each commit).
• Linear in the size of the diff (listing each changed file).
• Listing "everything" (like a full log).

(The problem applies to the verbosity of nearly all commands, not just this one.)

---

There's also some argument to be made that, fundamentally, an append-only output medium like the command line will have a great deal of difficulty providing a constantly up-to-date status of something, and you really have to resort to higher-level UI primitives to resolve this problem well.

[sullyj3]

and then it hung at the end due to the implicit smartlog printing

One concrete problem is that it might consume all of the user's available terminal scrollback.

Lately, I notice that the output is quite unhelpful when the entire smartlog becomes unwieldy and the full output doesn't fit on my screen.

It seems like many of these issues would be addressed by @emilazy's suggestion:

Perhaps it should show truncated output if there are more than n commits rebased, for some arbitrary n.

What do you think?

[arxanas]

btw this is not really on‐topic but I might like --reversed more if not for how it interacts with pagers.

jj pages by default and git-branchless doesn't, which is part of the design issue that motivated reversed-by-default output in git-branchless. Possibly I would also have designed git-branchless differently if it integrated with pagers better.

I haven’t yet read this entire comment, which is wonderfully dense with information

Alas, I did not have more time to write a shorter letter ✍️ ✉️

[emilazy]

I think my preference might be to see the new base, the immediate child, and the head of whatever was rebased. But that’s probably difficult to define precisely.

[sullyj3]

Similarly, I'd be interested to know if proponents of the feature also tend to immediately print the log after navigation commands like new/edit/next/prev as well

I was pretty sure I almost never do, I checked my shell history and I almost never do. I think the difference is that rebase is much more consequential, so it's more important to verify I've gotten it right.

[tim-janik]

Every time I do a rebase, I immediately run jj log to verify that I got the result I was expecting.

I think it would be nice if jj rebase did this automatically. It could just log the revset consisting of the base and the rebased commits. We could make this behaviour opt-out, or even opt-in if it's very controversial.

As a matter of UX, it's nice to have feedback about the operations I perform. It gives me confidence in my use of the system. The "Rebased n commits" message is good, but I think additionally showing those commits, and the commit they were rebased onto, would be even better.

There are a number of other commands like squash, duplicate, split, etc for which I also want to check the log/history to verify the outcome and my mental model of it. When doing git rebase -i, I have gotten used to immediately check the new history via gitk --all.
For jj, gitk wasn't good enough (and I like to stick to the terminal), so for daily jj usage, I've scripted up an fzf view, that allows me to view the log, do a rebase (with key bindings for -s/-b/-r and -A/-B) and watch the outcome right away.
But I wouldn't argue that most commands should automatically show a log. And which one? I have learned that different people prefer jj log to default to a different revset... Also, for e.g. rebase -r, I might be interested in the state of the branch the rev originated from, while for -s that'd be rather unlikely.

FWIW, here is jj-fzf that shows a jj log, let's you filter by revset and supports squash/rebase/etc:
https://github.com/tim-janik/tools/tree/master/jj-fzf