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?
2 Likes
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
@maximeb_unity Any update on this?
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.
1 Like
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
10 Likes
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.
2 Likes
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: Unity - Manual: Git dependencies
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).
We do have progress. AFAIK, these Git package UX improvements will be available in 2021.2. 
2 Likes
Great news would love to hear about the planned solution for it.
2 Likes
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?
1 Like
Iāll ask internally and find out for you, andyz
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.