purebasic
purebasic copied to clipboard
Handling PB Project Files via '--skip-worktree'?
Maybe a good solution to prevent PureBasic project files (.pbp
) from being overridden by local IDE changes, and at the same time allow upstream changes to be detected, is to use git-update-index --skip-worktree
.
So, probably running something like:
git-update-index --skip-worktree -- **.pbp
If I've understood correctly, this would allow end users to locally override *.pbp
files by using the PB IDE, preserving their local machine-specific settings even when pulling or hard resetting their local clone; but if the upstream project file is changes by the maintainers, then the new changes are indeed enforced locally (but after that, local changes will be still treated as before, the --skip-worktree
flag remaining intact).
I haven't used this feature, so it's just a proposal which need verification. Also, we'd have to enforce this setting repository-wide — is this doable at all? or at least in a simple way? — otherwise, if we rely on end users running this command manually it might not be effective (not more than having asked contributors to reformat PB sources using the IDE linter has been an effective safeguard against trailing whitespace).
Anyhow, it's an interesting alternative to simply ignoring *.pbp
files, and less complicated than providing sample *.sample.pbp
project files which end users need to copy and rename, but most of all it would enforce upstream updates to overwrite the local project file (which is quite important in case of significant changes to the project file).
Of course, doing without *.pbp
files and relying instead on compiler-directives to check that all compiler settings are correct is the best approach; but undoubtedly having project files greatly simplifies managing multiple sources in big projects like this one.
Here are links to good readings on the differences between assume-unchanged
and skip-worktree
:
NOTE — Even if the above proposal was to be enforced, we'd still need to create a tool to remove machine-specific setting from project files (like user name, machine specific absolute paths, and other stored info which is not crucial nor portable to other machines).
The above would allow maintainers to provide a stripped version of a PB project file to the repository, which end user can effectively open with the PB IDE without having to worry about its changes ending up as modified files in Git work space.
When significant changes need to be made to the upstream project files, maintainers can prepare the updated stripped-version and force it to be committed, which would then override the local .pbp
files after pulling — which also means that in the rare occasions that this happens, all custom IDE info and settings stored in the .pbp
files will be lost, but this shouldn't be a great deal.
Looks very good to me