lucasfang opened a new issue, #221:
URL: https://github.com/apache/paimon-cpp/issues/221

   ### Search before asking
   
   - [x] I searched in the 
[issues](https://github.com/apache/paimon-cpp/issues) and found nothing similar.
   
   
   ### Motivation
   
   [Feature] Normalize cmake_modules/arrow.diff generation via git diff
   
   Labels: enhancement
   
   ### Search before asking
   
   - [x] I searched in the 
[issues](https://github.com/apache/paimon-cpp/issues) and found nothing similar.
   
   ### Motivation
   
   `cmake_modules/arrow.diff` is the patch applied to the bundled Arrow 
ExternalProject via `PATCH_COMMAND` in 
`cmake_modules/ThirdpartyToolchain.cmake`. Historically its per-file patch 
sections were appended ad hoc as changes accumulated, so section ordering was 
arbitrary and hunks were sometimes grouped under the wrong file headers. This 
makes the patch hard to review, and every future edit risks producing large 
noisy diffs just from reordering. Commit `e776426` ("chore: format arrow diff") 
cleaned up the current file (sections sorted by file path, hunks split under 
their proper headers, content verified byte-for-byte identical), but there is 
no documented convention to keep it that way, so the file can drift back into 
an unstable state.
   
   ### Solution
   
   Standardize on generating `arrow.diff` with `git diff` so the section 
ordering is always stable and reproducible:
   
   1. Check out the pinned Arrow version (matching 
`PAIMON_ARROW_BUILD_SHA256_CHECKSUM` / the version in 
`third_party/versions.txt`) in a clean local repository.
   2. Apply the intended modifications directly on that checkout.
   3. Regenerate the patch with `git diff > cmake_modules/arrow.diff`. Git 
emits per-file sections in stable alphabetical path order, which guarantees a 
deterministic layout regardless of the order in which the changes were authored.
   4. Document this regeneration workflow (e.g. as a comment header inside 
`cmake_modules/arrow.diff` or in `CONTRIBUTING.md`) so future contributors 
follow the same process instead of hand-editing or appending patch fragments.
   5. Optionally, note in the PR template/review guidance that `arrow.diff` 
changes should be regeneratable by the above steps and keep semantic changes 
reviewable.
   
   ### Anything else?
   
   Related: commit `e776426` already reformatted the existing patch to the 
target layout without any semantic change (verified by comparing the multiset 
of all added/removed patch lines before and after). This issue tracks 
establishing the convention so the normalized state is preserved going forward.
   
   ### Are you willing to submit a PR?
   
   - [x] I'm willing to submit a PR!
   
   
   ### Solution
   
   _No response_
   
   ### Anything else?
   
   _No response_
   
   ### Are you willing to submit a PR?
   
   - [ ] I'm willing to submit a PR!


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to