Talk:KDEConnect

Cloning for development

IMHO the instructions on setting up for local development are backwards.

For outside contributors, rather than cloning your fork as the local origin remote, then adding the upstream as a second remote, it works far better in practice to clone the upstream as origin, and add your personal fork as a second remote.

That way, origin/main tracks the upstream project automatically, and you never have to worry about keeping your local clone up-to-date with the upstream project. The workflow for creating MRs looks like this:

git clone $UPSTREAM_URL
cd project
git remote add $USERNAME $FORK_URL
git fetch --all
git pull
git checkout -b feature-branch
# feature-branch is automatically based
# on up-to-date origin/main
[code code]
git commit
git push -u $USERNAME
git checkout main  # back to origin/main

It's by far the most comfortable setup for creating contributions to forked projects. FeRDNYC (talk) 23:16, 30 April 2025 (UTC)

And in fact Infrastructure/GitLab agrees with me. FeRDNYC (talk) 23:58, 30 April 2025 (UTC)