Skip to content

Conversation

@stefanhaller
Copy link
Collaborator

  • PR Description

This fixes two issues with the "<-- YOU ARE HERE ---" label:

  1. When hitting enter on the "You are here"commit to see its files, there's junk in the frame's title bar:

image

  1. When looking at the commits of a branch or tag while a rebase is ongoing, the top commit will show a bogus "You are here" label:

image

  • Please check if the PR fulfills these requirements
  • Cheatsheets are up-to-date (run go run scripts/cheatsheet/main.go generate)
  • Code has been formatted (see here)
  • Tests have been added/updated (see here for the integration test guide)
  • Text is internationalised (see here)
  • Docs (specifically docs/Config.md) have been updated if necessary
  • You've read through your own file changes for silly mistakes etc

@github-actions
Copy link
Contributor

github-actions bot commented Feb 26, 2023

Uffizzi Preview Environment deployment-17517

☁️ https://app.uffizzi.com/github.com/jesseduffield/lazygit/pull/2479

📄 View Application Logs etc.

What is Uffizzi? Learn more

length int,
showGraph bool,
bisectInfo *git_commands.BisectInfo,
youAreHereStr string, // non-empty only when we are rebasing
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm kind of abusing this parameter as both a way to pass in the translated string (Tr isn't known in here), and as a flag to say whether we should add the label or not. Hopefully the comment makes this clear enough.

fullDescription bool,
bisectStatus BisectStatus,
bisectInfo *git_commands.BisectInfo,
youAreHereStr string, // non-empty only if we're rebasing and this is the current commit
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here, the string is both for knowing the translated string and a flag whether this particular commit should get the label. A separate bool might be clearer, but is also a bit redundant.

Alternatively, I considered passing in common.Common so that we know the translated text, and a bool. However, that would make it more awkward for the test below, which would now have to instantiate a common.Common.

Copy link
Owner

@jesseduffield jesseduffield left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a welcome change: it was a hack to have something presentational on the commit itself. The plan with this presentation code is to switch from having standalone functions to having a struct which has fields like common.Common on it for i18n stuff. Given that fact, in this PR it would be good to have two args: one for common.Common and a boolean arg for whether we should show the 'you are here' label for a given commit.

You can use utils.NewDummyCommon() to instantiate the common.Common instance.

@stefanhaller stefanhaller force-pushed the fix-you-are-here-issues branch from 4549e27 to 1bce178 Compare February 27, 2023 07:28
@stefanhaller
Copy link
Collaborator Author

Ah, didn't know about NewDummyCommon. Yes, that's better then; force-pushed.

@stefanhaller
Copy link
Collaborator Author

Hm, testing this again I notice an ugly visual glitch: when hitting "e" on a commit, you see the YOU ARE HERE label briefly appear on the head commit before the commit list changes to the new state. It seems there's one extra refresh that displays the old model commits again, but the working copy is already in rebasing state. Do we need to store the working copy's rebasing state in the model so that it is consistent with the model's commits?

@stefanhaller
Copy link
Collaborator Author

Storing the working tree state in the model does seem to fix the glitch; please have a look at 483890d.

return err
}
gui.State.Model.Commits = updatedCommits
gui.State.Model.WorkingTreeState = gui.git.Status.WorkingTreeState()
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we're now setting this on the model, we should update the places that use gui.git.Status.WorkingTreeState() to now use gui.State.Model.WorkingTreeState, for the sake of consistency. But if we do that, I wonder how often that value would be stale. Perhaps never because it doesn't change without the list of commits also changing?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, I'm not sure I agree; the state in the model is really only there for making sure that the state matches the commits when drawing the commit list. For all other callers, I see no reason to use the model value; if we base behavior decisions on it (e.g. which options to show in the rebase menu), then that shouldn't depend on how long ago we last refreshed the commits list; it's better to use the most up to date value in these cases.

Maybe we could rename the model state to something like WorkingTreeStateCorrespondingToCommits to make that clearer.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense. How about WorkingTreeStateAtLastCommitRefresh?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like that; force-pushed.

Instead, derive it from context at display time (if we're rebasing, it's the
first non-todo commit). This fixes the problem that unfolding the current
commit's files in the local commits panel would show junk in the frame's title.

Along the way we make sure to only display the "<--- YOU ARE HERE" string in the
local commits panel; previously it would show for the top commit of a branch or
tag if mid-rebase.
This is the working tree state at the time the model commits were loaded. This
avoids a visual glitch with the "You Are Here" label appearing at times when it
is not supposed to.
@stefanhaller stefanhaller force-pushed the fix-you-are-here-issues branch from 483890d to de3e483 Compare March 1, 2023 08:17
@jesseduffield jesseduffield merged commit 48acf38 into jesseduffield:master Mar 1, 2023
@jesseduffield
Copy link
Owner

Thanks for this @stefanhaller !

@stefanhaller stefanhaller deleted the fix-you-are-here-issues branch March 1, 2023 08:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants