a few impressions from my first run of gg

[joyously]

I am trying out gg for the first time with the 0.15.3 release (I had to look that up in email, couldn't find it in gg) and it looks great.

I didn't have any jj repositories, and was surprised that gg didn't have a way to create one or clone one.

With no repo, the Commit menu was mostly grayed out, but still had Create a branch, which didn't show me any feedback when I tried it.

With no repo, the menus leave a white footprint on the gray background.

Although I read the Design page, it would be nice to have some sort of feedback in gg for the actions that happen with a click or drag. Maybe a status bar like a browser has, to indicate the action when the cursor changes.

I opened the jj repo and scrolled down to look at history, but the details pane shows only a time (no date) and part of it is covered by a bullet.

I can click on a changed file and nothing happens, even though the cursor changes for the files.

I accidentally double-clicked a change and saw that it made that the working copy. While exploring the files, I saw that new files listed were not present in the tree, however.

Having double-clicked a couple of changes, I decided to undo. I thought I should be able to see a list and choose, but didn't see that. Clicking Undo seemed to work, but the message for undo has the full hash, so it is truncated (even on fullscreen) and not very helpful. I clicked Undo several times before realizing it was simply alternating between the two states (one of which was the undo).

I thought there would be a more obvious way to deal with files.
I'm uncertain how confusing gg would be if I have to have two views (GUI and CLI) open to the source tree, and both of them can easily change what the files contain. Depending on how your editor behaves with autosave or reloading, you can accidentally leave a trail of unintended changes in the history or losing your current edits?

[gulbanana]

Thanks, this is very useful. An initial experience report is a great way for me to learn about the expectations people have and how their workflows match or differ from my own. I've improved the time/datestamps and the file list, and will use this feedback as a source of future improvements. Here are a few specific things that stuck out to me:

I didn't have any jj repositories, and was surprised that gg didn't have a way to create one or clone one.

You're not the first to mention this. Originally I thought that all gg users would already have jj and so init/clone functionality didn't seem important - I've changed my mind and now plan to add it.

With no repo, the menus leave a white footprint on the gray background.

I couldn't reproduce this one... looks like you're using Linux? I'll have to find some way to test on GTK. Odd that it would be specific to the no-repo state, which is ultimately just a different css background-color.

I clicked Undo several times before realizing it was simply alternating between the two states (one of which was the undo).

This is how jj undo works too - undoing again undoes your first undo. However, I agree that it's not very useful behaviour in a GUI and I intend to add more typical redo-stack semantics on top of the underlying operation log.

I'm uncertain how confusing gg would be if I have to have two views (GUI and CLI) open to the source tree, and both of them can easily change what the files contain.

This should actually work pretty well in practice. JJ snapshots file changes into the working copy whenever you run a command, and GG does this when the window is focused as well - the idea is that while you've got it focused, you aren't likely to be also making changes in another program.

It's not impossible to have conflicts (for example, there could be some long-running background operation) but in that case you won't lose any edits permanently; you'd get two conflicting copies of the current revision, a situation Jujutsu calls "divergence", and you could use gg or jj to pick the changes out of each of them.

[joyously]

looks like you're using Linux?

Yes, Xubuntu 22.04 LTS.

This is how jj undo works too - undoing again undoes your first undo.

Yes, it makes sense, but in the GUI there were very few clues to distinguish what was happening (only a hash that was truncated). I don't remember now if there was a way to see the op log.

the idea is that while you've got it focused, you aren't likely to be also making changes in another program.

Well, for someone like me, who keeps windows open for days, it is very likely. My thought was that I use an editor for making changes and I might need to look something up from history so I open gg and click around. This can change the files on the disk and my editor might load the changed file (I think Atom does this) or autosave my existing edits onto the changed file (most editors do this) so when I click on to other history I've unknowingly added commits (not sure how this part works). This is just with one person mucking about, but what if the repo is on shared network drive and there are multiple people doing this?
To me it seems a bit fragile unless I'm totally misunderstanding what's going on. But it would be safer if browsing history was non-destructive (files stored somewhere temporary) and you had to do a bit more to actually edit history. I know, it sounds like going backward, but if every novice can screw up the repo just learning the GUI, then there is something wrong.

you could use gg or jj to pick the changes out of each of them

I think there is no easy way to determine what got changed on purpose or by accident.

[joyously]

Following up with the newer version (0.16.0):
Here's a screenshot of the menu leaving a white background when there is no repo loaded.

The files panel showing the diff is much better.
The changes to the date display are disappointing. It is now showing relative time (which I don't like because I leave windows open a long time and it's only correct at first, and I don't want to have to do date math in my head while programming). But the bigger problem is there is still a bullet obscuring the number.

In my short test of gg 0.16.0, I wondered what was going on, because when I first opened the jj repo (which I don't think I've updated since my last test of gg) it was showing a bunch of commits to the docs at the top, all in a line. I had to scroll pretty far down to find code commits and branches, yet my screenshot for the prior test shows the scrollbar pretty near the top. I was very careful and did not double click anything, but single clicked a few entries to see them reflected in the right side panel and test that out. But then I noticed that those doc commits were no longer at the top and the scrollbar was further toward the top. So my question is twofold: am I misunderstanding what a single click is doing (browsing history of the commit without changing the working copy) and if so, why would that change the log (which I assume is what is on the left panel) ? Or maybe I wasn't as careful as I thought and accidentally dragged something or double clicked or whatever to change the view. If this is the case, it is entirely too sensitive to use as is.

[ilyagr]

Or maybe I wasn't as careful as I thought and accidentally dragged something or double clicked or whatever to change the view. If this is the case, it is entirely too sensitive to use as is.

I very much agree that this is an issue.

As a workaround for gg as it is now, I recommend you open a separate terminal where you can run jj op log and jj op restore. That should make it clear what happened and let you recover from accidental changes.

[gulbanana]

SIngle click is definitely meant to just browse without changing the log. Did you by any chance press any of the keyboard navigation buttons - arrows pageup/down, home/end? Those would make the log jump around if you have it selected, though they shouldn't change what's in it.

Good call on the relative times, which I will fix, but I have no idea where the bullet's coming from! I'll definitely have to arrange to try the GTK build at some point, maybe setup Xubuntu - at the moment I don't have a good way to debug Linux-specific issues.

[joyously]

I didn't use the keyboard during the test.
Is there something I can run to debug the bullet by the date?