Hello,
I’ve got a gitlab project for my c++ project. In order to help the test team test the program, the code needs to be modified.
For this, the changes are made and then a patch file is created (git diff of all changes written to a single patch file). Since the creation of the patch file, minor changes have been made to the source code.
My patch file now no longer works as the line numbers don’t match up.
Is there any way I can prevent this?
Regards,
Alan
Can you share how the patch file is applied, and generated before? I remember some differences between using patch -p0 and git am for Git created patch sets.
Some sample source code and project would be helpful, too 
Hi dnsmichi,
To generate my patch file, I would just do git status, followed by git diff of the files highlighted by git status piped to one patch file.
Here’s a comparison between my initial non-working patch and the patch that I regenerated.
Thanks again,
Alan
Thanks for the details. Which commands are being used to apply the patch files?
I know that git apply and git am try to resolve conflicts with some advanced merge techniques, whereas patch fails if the lines diff does not add up.
Hi again,
I’m just using git apply followed by the name of the patch file
Thanks again,
Alan
Hm, ok, then I am on the wrong path here.
An alternative idea could be tracking the changes in a separate MR/Git branch called test-diff, and when the team needs to test something specific, you can either rebase against the test-diff branch, or merge the changes. Alternatively, use git cherry-pick <commit id>.
Something like this, based on the dev branch.
git checkout dev
git checkout -b test-diff
vim main.cpp
<add changes>
git commit -avm "Test required changes"
git push
<Create draft MR>
When a new feature is pushed to the dev branch, and tests should be triggered again, rebase the test-diff branch against dev.
git fetch
git checkout test-diff
git rebase dev
git push --force
It might not work for large patch diff sets, but the previous git base can help Git to determine the best merge/rebase strategies without failure.
If that idea does not work, a different strategy to patching will be needed, I guess. Feature flags / debug parameters for debug builds come to mind. In a previous project, we used macro definitions (#ifdef) to build specific dev code. It was reading the CMake variable CMAKE_BUILD_TYPE with RelWithDebugInfo, Release, Debug and set the preprocessor macros then.
While the different ifdef’s will increase maintenance for developers, it also increases efficiency with a single source of truth for all code changes, and runtime build parameters. Thinking more about it - probably I would suggest going this way, instead of the MR git branch strategy noted above.
Thanks, I will try that out.
Regards,
Alan