<rmsyn[m]>
<JamesMunns[m]> "I do squash-merges, so the whole..." <- I can see doing this for relatively small PRs where the changes are self-contained. however, for larger PRs with multiple commits that each achieve self-contained changes needed for the overall feature/refactor, I prefer separate commits rebased on the latest HEAD before merge
<rmsyn[m]>
it makes it easier to git revert changes in a more granular way, e.g. maybe part of the changeset cause a regression, but everything else is fine. also, as others mentioned, rebasing keeps the git history cleaner for multi-commit PRs
<JamesMunns[m]>
<rmsyn[m]> "I can see doing this for..." <- You’re free to do whatever makes sense in your projects, that’s just what I do in mine :)
<rmsyn[m]>
right, just weighing in with my opinion. also agree that not everyone has to do it the way I do.
<rmsyn[m]>
there's always exceptions + edge-cases, too. sometimes big PRs are necessary for new features, sometimes multi-commit PRs can be squashed after review, etc. ultimately comes down to the coding guidelines in each project + the team working on the code base, right?
sroemer has joined #rust-embedded
leewoojun has joined #rust-embedded
leewoojun has left #rust-embedded [#rust-embedded]
jfsimon1981a has joined #rust-embedded
jfsimon has quit [Ping timeout: 248 seconds]
pcs38 has joined #rust-embedded
DanielakaCyReVol has joined #rust-embedded
<DanielakaCyReVol>
<therealprof[m]> "Merges in PRs create weird..." <- I still wonder how Torvalds does it.
<DanielakaCyReVol>
Linux looks like Guitar Hero, if you know what I mean. xD
<M9names[m]>
> GitHub won't allow for that direct workflow
<M9names[m]>
are you sure about that? maintainers usually get write access to a branch when a PR has been raised.
<M9names[m]>
you can rebase and apply changes on top of an existing PR, no problems
<M9names[m]>
as for license: if you aren't allowed to change the wording of anything written by anyone else, how can you possibly collaborate on a book?
Ralph[m] has quit [Quit: Idle timeout reached: 172800s]
<DanielakaCyReVol>
<M9names[m]> "as for license: if you aren't..." <- It depends. I just described the general case.
<DanielakaCyReVol>
Some projects/companies set up specific CLAs, other just don't care, and some may be very strict about who owns what.
<DanielakaCyReVol>
* It depends. I just described the general case.
<DanielakaCyReVol>
Some projects/companies set up specific CLAs, others just don't care, and some may be very strict about who owns what.
Emkanea[m] has quit [Quit: Idle timeout reached: 172800s]
<M9names[m]>
is that checkbox not ticked by default for you?
<M9names[m]>
almost every PR i have ever review for an open source project had it enabled, which is why i feel you're describing the exceptional case instead of the general case
wassasin[m] has quit [Quit: Idle timeout reached: 172800s]
<M9names[m]>
maybe my experience is abnormal? i don't get a lot of contributors acting on behalf of companies
<DanielakaCyReVol>
It might have changed.
<DanielakaCyReVol>
My experience is different, yea.
<DanielakaCyReVol>
The docs do not tell what the defaults are, unfortunately.
ouilemur has quit [Quit: WeeChat 4.6.3]
dirbaio[m] has joined #rust-embedded
<dirbaio[m]>
It the fork repo is in an org it sometimes defaults to false or even doesn't let the pr author enable it
<dirbaio[m]>
Depending on the permissions the pr author has on that org, or on the org settings, I'm not sure.
<dirbaio[m]>
I'm also hitting this with some contributors in Embassy. It's super annoying.
<dirbaio[m]>
If I hit that and want to rebase the pr or something I just open a new one and close the old one :p
<dirbaio[m]>
* new one myself and close
pcs38 has quit [Quit: leaving]
Ralph[m] has joined #rust-embedded
<Ralph[m]>
<DanielakaCyReVol> "It might have changed...." <- IIRC the default is "whatever the last setting you had". so if you disabled it on a PR it'll stay disabled on the next (unless you flip it back). for me it's always enabled (because i never disable it)
<JamesMunns[m]>
new SDR podcast season for y'all that are interested :D
<okhsunrog[m]>
<dirbaio[m]> "It the fork repo is in an org it..." <- I know that this thing exists https://github.com/nektos/act
<okhsunrog[m]>
Also I really like the embassy's approach here with ci.sh script, really handy
<Ralph[m]>
out of interest (i don't have a concrete need for this anymore rn): is there any no_std crate providing support for bluetooth gamepads (think xbox controller)? a quick glance at crates.io didn't show me one, at least
<dirbaio[m]>
For making your device act as a gamepad?
<Ralph[m]>
no, to receive events from the gamepad
<Ralph[m]>
e.g. to control a drone (running a rust firmware) using a gamepad
<dirbaio[m]>
Ohhh
<dirbaio[m]>
So the drone is a ble central and connects to the gamepad?
<dirbaio[m]>
Trouble can act as a central, but the HID part is left to you :p
<Ralph[m]>
i'm aware of trouble. i was hoping for a nice layer on top of it :)
<Ralph[m]>
in the best case there'd be a `no_std` driver for gamepads which interfaces with whatever high-level BT abstraction which is then implemented for trouble, linux, windows, etc. so that you can just use it. but all i could find was e.g. specific implementations for windows
<dirbaio[m]>
Yeah I don't think that exists
<dirbaio[m]>
In desktop os's you'd let the kernel handle the hid part, you wouldn't deal with Bluetooth at all to read the gamepad
<Ralph[m]>
it might be nice to have a no_std HID abstraction layer which can then be implemented for trouble (and theoretically also devices wired up via USB or whatever other connection)? just putting this out there as an idea for the future :)
<dirbaio[m]>
I'm sure there's some crate to parse hid reports out there
JamesSizeland[m] has joined #rust-embedded
<JamesSizeland[m]>
Ralph[m]: Feel free to add it as an example request issue on Trouble with some details of what it needs to do.