ability to lock state.yml

[zachvalenta]

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

I find the status > recent repositories panel very useful, esp. to keep track of commonly used repos.

One downside, however, is that you can't use lazygit in repos you don't want in status > recent repositories.

Describe the solution you'd like

Would be nice to be able to lock recentrepos in state.yml to prevent this.

Describe alternatives you've considered

Manually scrubbing unwanted repos from state.yml

[mark2185]

As a workaround, you could create an alias for launching lazygit that uses something else for the config dir, but you can still supply it the usual config.yml.

Something like this:

$> lazygit --use-config-file ~/.config/lazygit/config.yml --use-config-dir /tmp/lazygit

[willparsons]

Sounds like ideally you'd want: ~- A way to remove a repo from the list in lazygit~ ~- A filter list to accompany RecentRepos~

• Some concept of IgnoredRepos that contains a list of the repos you don't want to see in the recent repos list
• A way to populate this list from lazygit (e.g. pressing X on an item in the recent repo list)

I can take a look into this.

Does anyone know of an example of a menu that allows for multiple actions per menu item? In this case I'm thinking x/d for removing the repo from the list and keeping Enter/Space for opening that repo.

[zachvalenta]

• A way to remove a repo from the list in lazygit

I'm not looking for a way to remove repos [which you can do today via manually editing state.yml] but rather locking the list of repos in state.yml.

Removal within lazygit might be faster - which counts for something! - but I don't see it as actually solving the problem, which is state.yml being mutated depending on the $CWD in which lazygit gets openend.

[willparsons]

The filter list would take care of actually keeping them out of the list, that way you don't have to lock the RecentRepos at all.

When I said a way to remove them I mean in the sense that you could press x/d on a repo in the list and it goes into the filter list, then lazygit will never attempt to add that repo back again.

I'll edit the original comment.

[zachvalenta]

I guess I still see this as a manual process and therefore potentially a site of toil. The number of directories you could open lazygit in and then have to put on what you're terming 'filter list' is unbounded, the number of directories you'd like to lock in state.yml is not.

But maybe the manual process would open up other workflows that I'm not thinking of! My original use case for this feature idea is specific to keeping track of repos synced across multiple machines.

[willparsons]

I see what you mean, a more selective approach about what goes in the list in the first place.

I think a lock could still be too much for most people so I'm just considering how to cover your case but also support some others at the same time.

Maybe we could do a confirmation when a new repo is opened so the user can determine if they want to add it at all, and options like "Always Accept" (current behaviour) and "Always Ignore" (dont add anything from now on) so you can still get that locking if you want.

Does that sound like it covers your use case?

[zachvalenta]

Maybe we could do a confirmation when a new repo is opened so the user can determine if they want to add it at all, and options like "Always Accept" (current behaviour) and "Always Ignore" (dont add anything from now on) so you can still get that locking if you want. Does that sound like it covers your use case?

It does!

Off the top of my head, one nit I can think to pick about this approach:

Let's say you had a freeze list:

frozen_repos:
    - /Users/user_name/big_work_project
    - /Users/user_name/big_personal_project
    - /Users/user_name/my_notes

If you want to add another repo, you would:

• get path to repo you want to add
• vim path/to/lazy-state.yaml and add the path

In the approach you're outlining, the steps to add a new repo would be:

• vim path/to/lazygit-state.yaml to toggle ignore_new_repos=true to false
• cd repo/you/want/to/add and open lazygit
• vim path/to/lazygit-state.yaml to toggle ignore_new_repos=false back to true

It does feel like a bit more work/steps. And then, if you forget to toggle ignore_new_repos back to true, you're likely to add a bunch more repos to state.yml and then have to manually scrub them out of recent_repos as well.

But: the way that you're outlining would still totally work for me and nowhere near enough friction to outweigh to the overall gain in functionality!

[willparsons]

Sounds good.

I'm going to see what I can come up with and then we can see what works best. I've not yet contributed to lazygit in the past so bear with me if this takes some time 😆.

[mark2185]

If you know you don't want to add the repo to your recentRepos list before launching lazygit, why not just use an alias when launching lazygit?

Seems like a simpler solution, without the need to complicate lazygit's implementation.

[zachvalenta]

If you know you don't want to add the repo to your recentRepos list before launching lazygit, why not just use an alias when launching lazygit? Seems like a simpler solution, without the need to complicate lazygit's implementation.

Circling back to your comment previous to the above quoted:

• I see --use-config-file in the codebase
• I don't see --use-config-dir in the codebase

but very well could be a bad grep from me.

As a workaround, you could create an alias for launching lazygit that uses something else for the config dir, but you can still supply it the usual config.yml. Something like this:

$> lazygit --use-config-file ~/.config/lazygit/config.yml --use-config-dir /tmp/lazygit

I confess I don't understand what an alternate config directory would be doing here that would solve the issue. But, I'm unfamiliar with lazygit's config beyond the basics, so sorry if I'm missing something obvious.

[mark2185]

I don't see --use-config-dir in the codebase

Try grepping for use-config-dir or just run lazygit --help.

I don't understand what an alternate config directory would be doing here that would solve the issue.

You wouldn't modify the state.yml that the other lazygit instance is using, but instead use a new one which is a temporary one, one that you use just for situations like these. Think of it as a "private window" (like browsers have) for lazygit. It's hackish, but it might solve your problem.

Of course one could argue "but I want my current state in that new instance as well", but that's a different story.

[zachvalenta]

Try grepping for use-config-dir or just run lazygit --help.

Aha! Dunno why this didn't show up via Github's search but does show up via lazygit --help.

You wouldn't modify the state.yml that the other lazygit instance is using, but instead use a new one which is a temporary one, one that you use just for situations like these. Think of it as a "private window" (like browsers have) for lazygit. It's hackish, but it might solve your problem.

Of course one could argue "but I want my current state in that new instance as well", but that's a different story.

Ok, now I grok. This should work for not modifying recent_repos, but you also lose those repos as well, which I want access to for the use case I'm after. But may work for others with workflows similar but distinct from mine. Good to surface this as an option.

[willparsons]

https://github.com/jesseduffield/lazygit/pull/4086

Been busy with some other stuff but I'm working on this here.