On Sun, Jun 8, 2025 at 1:03 PM Daniel Sahlberg <daniel.l.sahlb...@gmail.com> wrote:
> > > sön 8 juni 2025 kl. 12:47 skrev Timofei Zhakov <t...@chemodax.net>: > >> On Sun, Jun 8, 2025 at 2:48 AM Branko Čibej <br...@apache.org> wrote: >> >>> On 7. 6. 25 19:41, rin...@apache.org wrote: >>> >>> Author: rinrab >>> Date: Sat Jun 7 17:41:22 2025 >>> New Revision: 1926218 >>> >>> URL: http://svn.apache.org/viewvc?rev=1926218&view=rev >>> Log: >>> In the trunk: Add svn_cmdline__get_utf8_argv() function and >>> platform-specific implementations. >>> >>> >>> You don't need to say "in the trunk" for trunk commits. >>> >>> >> I know, but why not? >> > > For brevity? > > >> >>> >>> (merged from utf8-cmdline-prototype@r1925816) >>> >>> >>> Please don't do that. You have an (experimental) feature branch, which >>> we're at some point going to review in depth; and now it will no longer be >>> trivial to see (e.g., with only "svn log --diff" what's changed on the >>> branch and what's merged to trunk. Stuff like this makes reviewing new >>> features much, much harder. >>> >>> >> I prefer to plan my work in a branch, so I can freely break some >> functionality, and then commit those changes to trunk one-by-one, and >> pretend we never had this branch before. This way, I am getting the work >> done, and committed properly. The changes can be reviewed as they are >> committed to the trunk. >> > > I’m with Brane on this point. > > I was planning to review this in the branch and then we could wholesale > merge it. Cherrypick merging seems prone to missing something. > > Fine, I can prepare this branch for reviewing (revert or cherry-pick unrelated changes), so the diff would be clean, without those experiments. But still I am going to cherry-pick the remaining changes one-by-one into the trunk, because I prefer having a bunch of small changes instead of a code-bomb after svn-merge. Are we okay with that? -- Timofei Zhakov
