[aur-dev] AUR 4.0.0 version tags
Hi. I have a suggestion for AUR 4.0.0: git tags with version information. The idea is that each and every commit will be tagged with the version extracted from .SRCINFO. Only the server will be allowed to apply tags (maybe a simple chmod on `.git/ref/tags` would do). They must never be overwritten, so `git-serve.py` should check if a tag exists before accepting a new commit. This will allow the user to check what happened to the AUR package he wants to install with`git diff` and `git log`, relative to his installed version. It will totally replace the need of aurifere, and can help other AUR helpers [1] as well. What do you think? If there is interest, I will work on a patch. Yaron [1] https://github.com/rmarquis/pacaur/issues/231
On Mon, 12 Jan 2015 at 19:17:35, Yaron de Leeuw wrote:
Hi. I have a suggestion for AUR 4.0.0: git tags with version information. The idea is that each and every commit will be tagged with the version extracted from .SRCINFO. Only the server will be allowed to apply tags (maybe a simple chmod on `.git/ref/tags` would do). They must never be overwritten, so `git-serve.py` should check if a tag exists before accepting a new commit.
This will allow the user to check what happened to the AUR package he wants to install with`git diff` and `git log`, relative to his installed version.
It will totally replace the need of aurifere, and can help other AUR helpers [1] as well.
What do you think? If there is interest, I will work on a patch.
I am not sure whether doing it automatically on the server is a good idea but I like the idea of having tags for different versions of a package. The problem with creating them on the server side is that you need to run `git push && git pull` instead of `git push` every time you want to sync the server with the local clone. Because it happens in the background, users might not be aware of the new refs and may not run `git pull` to update their local repository (which means the tags are also missing from any other remotes the users push to). Not sure if that really is a problem, though. I would like to hear some more opinions. Note that our post-receive script already rejects any updates to tags, so you don't need any additional checks here :)
Yaron
* Lukas Fleischer <archlinux@cryptocrack.de> (Mon, 12 Jan 2015 20:59:36 +0100):
On Mon, 12 Jan 2015 at 19:17:35, Yaron de Leeuw wrote:
I have a suggestion for AUR 4.0.0: git tags with version information. The idea is that each and every commit will be tagged with the version extracted from .SRCINFO. Only the server will be allowed to apply tags (maybe a simple chmod on `.git/ref/tags` would do). They must never be overwritten, so `git-serve.py` should check if a tag exists before accepting a new commit.
I am not sure whether doing it automatically on the server is a good idea but I like the idea of having tags for different versions of a package. The problem with creating them on the server side is that you need to run `git push && git pull` instead of `git push` every time you want to sync the server with the local clone. Because it happens in the background, users might not be aware of the new refs and may not run `git pull` to update their local repository (which means the tags are also missing from any other remotes the users push to). Not sure if that really is a problem, though.
I would like to hear some more opinions.
I like the idea of having tags, but not that the server applies them in the background: it's too error prone if users have to manually type `&& git pull` behind there `git push`. Perhaps a simple script, possibly included in pkgbuild-introspection, can take care of the extra hassle (and perhaps include a tag in the client repository?) of typing `git push [origin master] && git pull` every time? Just my few thoughts… Regards, Marcel
On Tue, 13 Jan 2015 at 16:43:53, Marcel Korpel wrote:
[...] I like the idea of having tags, but not that the server applies them in the background: it's too error prone if users have to manually type `&& git pull` behind there `git push`. Perhaps a simple script, possibly included in pkgbuild-introspection, can take care of the extra hassle (and perhaps include a tag in the client repository?) of typing `git push [origin master] && git pull` every time?
Just to clarify: Users don't necessarily need to run `git pull` after each `git push`. Not running that command just means they won't fetch the tags the server added automatically. They can still use `git fetch` to import the tags later at any point in time. The problem with creating them on the client-side is that it requires special tools in every local repository and even then, checking the tags for consistency (and making sure that they are attached to every commit) is involved. Users would have to use `git push --tags` instead of `git push` and we would have to do all the tag computation on the server again for validation. After discussing this with some developers and some users in #git, I am still not totally convinced that it is sane to add tags on the server but I think we should give it a try. Patches welcome!
Just my few thoughts…
Regards, Marcel
Regards, Lukas
participants (3)
-
Lukas Fleischer
-
Marcel Korpel
-
Yaron de Leeuw