I was wondering why there is seemingly no way to currently update git packages without editing the manifest (even on 2019.3) and if this is something that is planned?
Hi @QFSW, If you mean updating a Git package to a more recent version of a given branch (newest commit on the branch), we currently have no API or UI that does this directly, but it's on our roadmap - not for 2019.3, however. As a workaround, you can re-add the same Git dependency using the UnityEditor.PackageManager.Client.Add method, and it should update the Git package if a newer commit exists on that branch.
Hi, Deleting the revision lock also does the trick, just inconvenient Glad to hear it's on the road map and hope to hear an ETA on when it will be added to the UI (like non git packages can be updated) when available
Using 2019.4.15f1 and looks like this feature is still missing. Updating to a recent commit will conflict with Github and Gitlab flows where master branch is for development and tags are for releases. Therefore I suggest updating to a version tag ,instead of a recent commit.
One other very important related issue is, it is impossible for git packages to define which version of the package that should be used. Local project is locked to the version you first imported the package. Other people cloning the repository are forced to use the version from the date they first opened the project. This will eventually lead to a compatibility hell!
Sorry, I just noticed the "hash" field of the commit in "packages-lock.json" which is pretty useful for including the commit used in the repository. I would love to see related useful tools in Unity editor package manager as well. Such as a corresponding field, or a tags list selector.
Ran into the same issue so I made a little editor window tool to quickly update Unity packages hosted on git if you're interested: Unity Git Package Updater
This is so great, but unfortunately it does not seem to work with the 2020 LTS version. Edit: It seems to work partly, if you select only a single package to update, it does not work. If you select "Update All", you need to minimize and open Unity in order for it to update the package.
The team have confirmed to me that they're aware of this issue and currently working on resolving it.
Hi, I was wondering if there's any progress on this? I've been thinking about the issue with git packages and have a bunch of thoughts I hope could be passed on to the team developing UPM. Is the team by any chance considering changing git packages over to use the unity concept of a package version (specifed in the package.json) instead of using the latest git hash? I know that it's harder and more performance intensive to dig this info out of git history, but could this be streamlined if the git query focuses on just the package.json file history ie. not the entire commit history? and then would it be possible for the query results to be cached so subsequent queries don't need to query back further than the last version number cached. There must be some ways to optmise the queries, and if not could is just be user initiated using a 'refresh git package' button or an optional setting to resolve git packages which is off by default to turn this on at our own risk of it taking a long time. Frankly I don't mind how long it takes, I would prefer it is functionally usable, I understand this would attract complaints from other users that do care. At the very least a user initiated button to grab the latest package version should be the bare minimum. It just feels like it would be such a better setup though if git packages were using the formal unity concept of a package version. This would allow package developers to decide 'when' out of many commits that the changes have matured to the point that it is worth incrementing the version number to be shared ie. trigger an update version button. Using the last git hash suggests that every commit made is a worthy update that should be installed which if ends up being the approach Unity go for it feels like it's going to be causing endless headaches for devs that never intended for half baked versions of a package to be updated to. The concept of what makes a version number increment should be a human one, it could be the first commit that sets a new unique version number. Not to mention that there's also no way to specifiy a desired version (edit: aside from git tags but that's a pretty limited approach that isn't an option that makes sense for us). If there was an incompatibility introduced in a newer version how would the package be rolled back? The unity package version number shown for git packages at the moment is somewhat arbitrary and obviously there's no update button available for them. I've read your suggestion in another thread that the UI could be changed to include the git hash, but if the update button was shown as the hash version like 'update to 21jn34kj234k' it would be completely unintuitive and not really at all helpful. Seeing this update button with no idea what it's updating to (all you'd know is that there's some sort of update available) would encourage the package to be updated to every new commit made, which again in my view seems like it would not be desirable for a lot of developers. Only when the actual unity concept of a package number has been increased makes sense. Changing this to use the unity concept of a package version would also bring the git package functionality more in line with other packages so there is more of consistent approach to versions. A sensible update button could be added that works like other packages. A specific version could be specified as a dependency or rolled back to. Even if a developer did actually want every git commit to be available as an update they could use git hooks or some other mecanism to auto-increment the package version for every commit and the functionality would be on par with using every commit hash as an package update. Thanks for reading, it would be great to know what kind of plan is in place for this and when to expect git package updating to be improved, cheers.
Ok.. so after my huge mind dump on this topic I'd found this note about being able to use git tags to target a specific commit: https://docs.unity3d.com/Manual/upm-git.html#revision Yet to try this but I'm hoping this will suffice.
hmm... no go, I have a git repo with dozens and dozens of packages and would need to break each into their own repo for a git tag based approach to make any kind of sense. Using a hash to target the commit is going to be way too confusing and time consuming to implement as a way to manage dependencies between large amounts of packages.
Any updates on this? Currently, I need to manually update the commit hash in `packages-lock.json` to update to a new version tag (Unity 2019.4.27f1).
Hi, is it such complicated to add a Update(string packageName) to UnityEditor.PackageManager.Client that fetches the last (git) commit? Would be great to see this in 2021.1 Thanks
@UnityMaru Do we have no simple feature for this yet?! Still in 2019 LTS but not being able to update a git package seems like the whole Git feature is a bit half-done. Also could there be SVN support added - another popular source control?
Hey! So, updating git packages remains on the roadmap and will be done eventually - it's not seen as a priority at present. As for SVN, there are no plans to support it at present. We know there is a community that still uses it, but we don't see it as a long term solution. This is why we remain committed to Git.
OK... but this does appear as though using packages via source control is not a key plan then, even though people like Google use it for their Cardboard plugin. If you want to share code between projects a package seemed the best way to do it, but if you must manually update it each time there is a change, then it is not so good. (Although the lack of update notifications is a general package shortcoming currently anyway)
I don't remember exactly which version this landed, but in 2021.2 you can now update custom Git Packages via a button in the package manager.
I just tested this out in 2021.2.11 and the update button is now activated all the times and will grab the latest commit for a git package. The only thing git packages still fail to do is to look up and detect whether package version numbers have been incremented, I can understand the difficulties there would be in getting this working however. But it does make the package numbers somewhat arbitrary, I guess you can still at least use them to configure a minimum required version number in other packages that need to use the git package. Just don't expect the kind of behaviour you get from other package types which have published versions, where the package manager will show that there is an package update available to upgrade to, not that I've seen, instead the update button is just active at all times to 'check' if there happens to be an update.
great recommendation there! however for simplicity, I do recommend Unity take on the path of using git tags for version updates and kind of display all the available tags in the package manager!