Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: don't check updates for local plugins #1512

Closed
wants to merge 1 commit into from

Conversation

AThePeanut4
Copy link
Contributor

Extends #1384 to cover all local plugins, not just dev ones. Also adds a skip condition for local plugins to the git.log task - without this, a local plugin that is on a different branch to that specified in the spec always shows as needing updates.

@folke folke closed this in 81d2bff Jul 7, 2024
@folke
Copy link
Owner

folke commented Jul 7, 2024

I find it quite useful to see if any of my local plugins have new commits on the same branch remotely.

I just changed it so that only in that case it will show updates.

folke pushed a commit that referenced this pull request Jul 7, 2024
🤖 I have created a release *beep* *boop*
---


##
[11.10.2](v11.10.1...v11.10.2)
(2024-07-07)


### Bug Fixes

* **git:** only check for new commits for local plugins. Closes
[#1512](#1512)
([81d2bff](81d2bff))

---
This PR was generated with [Release
Please](https://github.com/googleapis/release-please). See
[documentation](https://github.com/googleapis/release-please#release-please).

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
@AThePeanut4
Copy link
Contributor Author

@folke 81d2bff certainly fixes the main issue, and being able to see if there are updates on the remote branch is indeed useful. I am however still seeing some dev plugins shown as having updates available with an empty list of available updates.

I would expect the list of updates for a plugin to be essentially the results of git log some-branch..origin/some-branch - the commits that are on the upstream branch but not the local branch. However, if the local branch is not behind the upstream branch at all, i.e. the above git log returns nothing, then the plugin should not show as needing updates. This is what is happening in my case: some of my dev plugins have unpushed commits, causing them to be shown as needing updates.

From what I can tell, the check being done for whether updates are required is just whether the local and upstream commit hashes are different. This makes sense for non-local plugins, because you always want local equal to upstream. But for a local plugin, I'd argue that having local and upstream be different is perfectly fine, as long as local is not behind upstream.

folke pushed a commit that referenced this pull request Jul 7, 2024
## Description

As I described in
#1512 (comment),
this makes it so that local plugins will only show as needing updates if
the local branch is behind the upstream branch. This is done by checking
the output of the `git log` command, and only setting `plugin._.updates`
if the output is not empty.

This seems to solve my issue where local plugins with unpushed changes
always show as needing updates, but if there's a easier/better way of
doing it then please feel free to edit/close this. Or if you don't agree
that the current behaviour is a bug, then that's also fine - it's not a
big deal and I can easily just ignore the "updates available" notice.

I also came across a minor issue where the plugin diff view (press `d`)
compares the wrong commits for local plugins, because
[lua/lazy/view/init.lua](https://github.com/folke/lazy.nvim/blob/c771cf4928d1a1428ac7461658ab2916ed48adf5/lua/lazy/view/init.lua#L268)
always uses `get_target`. I fixed this by moving `get_local_target` into
`get_target` - I think this is simpler and more straightforward than the
alternative of adding a ternary everywhere `get_target` is called.

This second bugfix is a very small change, so I've just included it
here, but I'm happy to make a second PR if you'd like.

## Related Issue(s)

Related PR: #1512
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.

None yet

2 participants