Message ID | cover.1715964816.git.luishenriquegh2701@gmail.com |
---|---|
Headers | show |
Series | Update fzf to 0.52.1 | expand |
Hi, Thank you for the patches. From the first glance, some of the changes need to be grouped as single commit - [PATCH 8/9] gnu: golang.scm: Update packages and go versions. A general cement to all of them - is everything related just to bump fzf to the latest version or it's a collection of not related patches? I'm on the way to update valve to the latest version which is quite a massive change in dependencies tree. Also try to avoid adding any new packages to golang.scm. -- Oleg
Hi Oleg, > From the first glance, some of the changes need to be grouped as > single commit - [PATCH 8/9] gnu: golang.scm: Update packages and > go versions. thanks for the feedback! I didn't know it was OK to group commits, do you think all commits before the last one should be grouped? > A general cement to all of them - is everything related just to > bump fzf to the latest version or it's a collection of not > related patches? So, to upgrade fzf I had to update some of its dependencies and, due to it, had to update their go versions from 17 to 18. When I checked if any other dependent packages were affected with =guix refresh=, it showed to me that the packages were not building because they were compiled with Go 17 and it seems the =go-build-system= vendorizes all package dependencies before building. I tried fixing only the packages that were broken, so I guess they are all related in that sense. I'm totally open to being convinced otherwise though :) > Also try to avoid adding any new packages to golang.scm. OK, I read some other packages there and it seemed to me that =fastwalk= was similar in nature to the ones near it (where I inserted it). Should I move it to =golang-xyz.scm= instead?
Hello, I think there has been some misunderstanding, it is the other way round: Every package change needs its own commit, even if they are in the same file. So commit 8/9 should be split into several ones. When doing so, you may wish to use the ./etc/committer.scm script in the source tree: Update a package and run the script, which often creates a good commit. Updating many packages at the same time can become a bit unwieldy; it might be easier to update in smaller chunks, starting with only some dependencies (if this is possible depends of course on how entangled the situation is). Andreas