Update multimedia/py-soco to v0.28.1, released on 2022-10-22

[conallob]

Maintainer update of multimedia/py-soco, but using a direct pull request instead of patch files via bugzilla. Happy to use bugzilla if preferred though

[metalefty]

Direct pull requst is fine but could you squash them into one commit?

[conallob]

Direct pull requst is fine but could you squash them into one commit?

A reasonable request. I'm a novice git user though, so I've attempted an interactive rebase to merge my local commits.

The cleanest way to merge multiple commits per PR appears to actually be a repository side setting according to Github documention

[metalefty]

It is a GitHub feature not git. We're just using GitHub to mirror our primary repository git.FreeBSD.org. So repository side setting takes no effect. We usually do like this to take pull requests on GitHub into our git repository.

curl https://github.com/freebsd/freebsd-ports/commit/8e2d4511ff12c54c8c50dafa3974af1717d060f0.patch | git am

I can do squash on my side but asking you to do that for your practice. Can you just squash commits and force-push? If difficult, just let me know. I'll squash your commits on my side.

[bsdimp]

(assuming your upstream is called 'freebsd'):

git rebase -i freebsd/main
<in the editor change all the pick lines after the first one to 's ' which squashes all the commits together and kicks you into a new editor to edit the commit message>

While git merge --squash looks like it might be good, that creates a merge commit when committed (though one could delete the .git/MERGE_HEAD file so that commit won't do that, but that seems more complex), which isn't linear.

It's not always clear whether we'd want to set that server-side setting if it is global (and the one I think it is, I haven't looked in a while). Sometimes a pull request should be done as separate commits, sometimes they should be squashed.

[conallob]

Thank you both for the pointers. Even though I've 20+ years of experience with SCMs, my main complaint as I learn git semantics is the quality of documentation. Most docs are unofficial pointers, which may not actually suit my use case.

While trying to squash my commits and resync to HEAD, I accidentally closed this PR, so I've opened PR #139