Align git undo view to corner

[chapati23]

not sure this is my specific issue but the rendering of the git undo command is very weird for me, check it out in my little asciinema recording: https://asciinema.org/a/WNpyJCn0iwGg9v24Da5suh46Z

macOS 11.4 / iTerm 2 (but native terminal has the same isse) / ZSH with OhMyZsh

i don't have any other commands / CLIs that show this kind of behavior so it does seem like a specific git-branchless issue

[arxanas]

Hi @chapati23, thanks for the details demo/screenshot. This is currently expected behavior: there's not very much in the displayed commit graph, and all of the events for the latest transaction are listed.

By default, whatever cursive widget I'm using centers the views both vertically and horizontally, and I didn't bother to change it. Do you have a suggestion for how you would expect it to display in this case?

You might find the display more useful if you wrap your git behind git-branchless wrap and then try a complicated rebase/merge operation. There would be many more events and a much more complicated graph to display.

[chapati23]

hey, thanks for the explanation :)
I think top-left or bottom-left alignment would make more sense IMO.

every terminal i know (rtl languages excluded) is typically left-aligned, so the horizontal centering is definitely unusual at least in my experience.

logically speaking i would expect the latest commit (or 'event') to be either on the top left (with older events descending under it) OR vice versa with the newest event on the bottom left with older ones above it.

git log renders the latest commit on the top with older ones below, maybe worth imitating that as many people trying out git-branchless may be looking for a more powerful alternative to the git log they're used to?

[arxanas]

logically speaking i would expect the latest commit (or 'event') to be either on the top left (with older events descending under it) OR vice versa with the newest event on the bottom left with older ones above it.

Thanks for the feedback. I'll experiment with it and see what looks best. Most likely I'll align it to the bottom-left.

I used to use a different implementation of the smartlog for Mercurial. I hated the fact that it would show the most recent commits at the top, because oftentimes I had a lot of work in progress, and then I would have to scroll all the way back up to see what I was most recently working on. So I wrote this implementation to show the most recent commits at the bottom (when running git sl).

Unfortunately, the logical ordering changes when you have a scrollable view, because now the area that's visible at first is the top, and the bottom is occluded, in opposition to what happens when you print a lot of stuff to the terminal. Then it makes sense to put the most recent commits at the top, and then let the user scroll down to see the less recent commits.

The undo view currently starts you scrolled all the way to the bottom, to match what you would see if you ran git sl in the terminal. It probably makes sense to align it to the bottom-left in that case. But we might want to revisit in the whole affair in the future. For example, it might just be better to output git sl to a pager, and then reclaim the top-down commit view.

---

On the terminology of "commits" vs "events": colloquially, Git users sometimes talk about "history-rewriting" operations. The problem is that, with a tool like git-branchless, there's more than one "history" that we could be talking about:

• The history of the code itself. Each commit expresses a change to the code.
• The history of the commit graph. Git itself stores some of the history information in the reflog, but git-branchless augments it with its own event log (see Comparison with the reflog).
  • For people who use merge-based workflows, this is pretty similar to the history of the code itself, because you only append items to the commit graph. Only branches/refs are logically rewritten.
  • For people who use rebase-based workflows, the history of the commit graph may be something quite different than the history of the code itself, because these users frequently amend, reword, move, combine, and split commits.

A colleague of mine (@Myaushka 👋 ) once remarked on the topic of Mercurial's version of interactive rebase: "Oh, so it doesn't rewrite history at all. It just edits your commit graph." Commits are snapshots of the code, but events are the operations which describe the changes to commits/the commit graph.

---

Just so you can see what it looks like right now with a big change, here's git undo after some complicated rebase operation:

One problem with the current layout is that it always shows the entire list of events, which can be quite large, and not leave any space for the actual smartlog. They should probably both be in scrollable views. Actually, it might be best to omit the event descriptions altogether by default, and just say something like "after git rebase -i foo", corresponding to whatever command you ran.

[arxanas]

@chapati23 I've been playing around with the undo view a little bit. So far I like it best when it's full-screen, and I've added some panels to make it more obvious what the UI elements are. Here's what it looks like:

I think it's a lot clearer what's going on now. Let me know if you have any thoughts. I'll need to work on the UI some more and add more discoverable controls, a scroll bar for the event log at the bottom, change the colors, etc.

[chapati23]

Yeah, full screen looks a lot better to me personally! Positive side effect is that it probably adapts automatically to a user’s terminal size, right? I.e. if I make my terminal window smaller, it would auto-adapt the size of the git-branchless canvas too

…

Sent from my iPhone

On 17. Aug 2021, at 05:16, Waleed Khan ***@***.***> wrote:  @chapati23 I've been playing around with the undo view a little bit. So far I like it best when it's full-screen, and I've added some panels to make it more obvious what the UI elements are. Here's what it looks like: I think it's a lot clearer what's going on now. Let me know if you have any thoughts. I'll need to work on the UI some more and add more discoverable controls, a scroll bar for the event log at the bottom, etc. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[arxanas]

@chapati23 Yep, it sizes automatically, and resizes on terminal resize. Thanks for taking a look. I'll proceed with the fullscreen widget approach.

[arxanas]

Closed in #81.