14:09:15 <m-relay> <r​brunner7:monero.social> SNeedlewoods: I am not fully sure I understand the question(s) you ask, and the possible choices you face. But let's see:
14:12:07 <m-relay> <r​brunner7:monero.social> First, you extended the Wallet API, with PR #9464 as the result. Then you went on to refactor the CLI wallet to use only the Wallet API, and over the course of doing so you noticed several things still lacking in the Wallet API, and some of your new things that you could do in a better way, which resulted in the mix of commits in one of your branches.
14:14:46 <m-relay> <r​brunner7:monero.social> Now it's question how to bring order into this. I see basically 2 possibilities: 3 PRs which you could call "Extending Wallet API first round" (#9464), "Extending Wallet API second round" and "Refactoring CLI wallet to use Wallet API". Or, only 2 PRs "Extending Wallet API" and "Refactoring CLI wallet to use Wallet API".
14:16:11 <m-relay> <r​brunner7:monero.social> I guess your question "I assume a second commit is preferable over directly squashing them!?" refers to exactly this choice and tells that you currently lean towards a 3-PR-solution. Correct?
14:19:32 <m-relay> <r​brunner7:monero.social> I think right now a 2-PR-solution would be better. I suspect that the distinction between the things in "round one" and "round two" of Wallet API extensions would not tell reviewers and future readers of the PRs much, and without really looking into details I can imagine it's a pretty wild mix what you forgot in round one and were forced to add in round two, while migrating the CL<clipped mess
14:19:33 <m-relay> <r​brunner7:monero.social> I wallet. Which, IMHO, would result in a pretty arbitrary border between two PRs extending Wallet API.
17:34:47 <m-relay> <s​hshjwwjqj:nope.chat> LEARN HOW TO HACK 🕹
17:34:49 <m-relay> <s​hshjwwjqj:nope.chat>  🕶️ CyberSecurityExpertsHQ— born from the 2013 cyber underground. Real intel. Real exploits. No noise — just raw cybersecurity knowledge. ⚡
17:34:51 <m-relay> <s​hshjwwjqj:nope.chat> JOIN US HERE 📌
17:34:53 <m-relay> <s​hshjwwjqj:nope.chat> 📱Telegram Account Hacking
17:34:55 <m-relay> <s​hshjwwjqj:nope.chat> 📩Hotmail and Outlook Hacking
17:34:57 <m-relay> <s​hshjwwjqj:nope.chat> ☎️Track cellphone
17:34:59 <m-relay> <s​hshjwwjqj:nope.chat> 📱YouTube Account Hacking 
17:35:01 <m-relay> <s​hshjwwjqj:nope.chat> 📩Gmail Hacking
17:35:03 <m-relay> <s​hshjwwjqj:nope.chat> 🛡SS7 attack launching
17:35:05 <m-relay> <s​hshjwwjqj:nope.chat> 📱Facebook Hacking
17:35:07 <m-relay> <s​hshjwwjqj:nope.chat> 📱WhatsApp Account/Spy
18:10:21 <m-relay> <r​ottenwheel:unredacted.org> Mr. [@rbrunner7:monero.social](https://matrix.to/#/@rbrunner7:monero.social), hammer time!
18:10:41 <m-relay> <r​ottenwheel:unredacted.org> kek, the other admin that instance was deprecated years ago by now.
19:16:26 <m-relay> <s​needlewoods_xmr:matrix.org> I'll try to clarify, so my proposal is a 2-PR solution. I share the opinion a 3-PR solution does not make sense, because Wallet API round two probably has breaking changes compared to round one.
19:16:27 <m-relay> <s​needlewoods_xmr:matrix.org> The first PR is #9464, but updated with the "round two" changes, as you can see [here](https://github.com/monero-project/monero/compare/master...SNeedlewoods:seraphis_wallet:x_api_add_new_functions_updated). With the question "a second commit is preferable over directly squashing them!?" I mean should I keep the first commit of "round one" and add a second commit for "round two" a<clipped 
19:16:29 <m-relay> <s​needlewoods_xmr:matrix.org> s I have done, or should I squash both commits into a single commit "round one + round two". rbrunner7 you've already spent time reviewing #9464, so I'd like to hear if you have a preference, before I do some irreversible git thing.
19:16:31 <m-relay> <s​needlewoods_xmr:matrix.org> The second PR would be a new PR, consisting of one commit for all the simplewallet changes based on top of the updated Wallet API.
19:56:59 <m-relay> <r​brunner7:monero.social> Ah, I see, thanks for the clarification, SNeedlewoods . As far as I know, it almost makes no difference whether that single PR #9464 consists of 2 commits or only a single one. I think for review purposes GitHub will present all the changes from all commits together anyway? Maybe some more experienced dev can chime in and have their say, just to be sure. Pinging jberman , jeffro256
19:57:19 <m-relay> <o​frnxmr:monero.social> Its only irreversible if you dont have a backup :P
19:58:45 <m-relay> <r​brunner7:monero.social> Thanks for the heads up about the spam, rottenwheel :) It must be months since such an admin intervention was necessary the last time; regarding spam it helps that this room still is pretty obscure, so to say.
19:59:05 <m-relay> <o​frnxmr:monero.social> the main reason to keep the commits separate, is easier review of what-has- changed-since-previous-commit
19:59:44 <m-relay> <o​frnxmr:monero.social> And easier to revert a later commit if it has issues