We pull all commits that happened at ownCloud and create the PR out of it. Thus, basically it will include any commit. But not everything will be taken over (e.g. branding related things), which should end up in merge conflicts anyway. In the mentioned one I dealt with that for instance.
Until we experience bigger issues with backporting, or decide to just leave it. No fixed date, yet.
First, and to clarify, the “No rebase. Ever.” relates solely to this use case: pulling commits from upstream (owncloud).
My issue was caused, because of these steps:
git pull uptream master –
Open pull request –
Meanwhile other Nextcloud PRs were merged resulting in conflicts –
I did an git rebase origin master
A git rebase put’s the commit of your current working branch on top of the specified branch. By doing so however, there will be a new history, because the underlying base changed. The commits will have a new hash, for instance. Anyway, this will result that in a subsequent, second git pull upstream master the already merged commits were not matched with those present in upstream and you would merge them twice.
This does not happen, if you do the git pull upstream master again on a fresh branch based on origin master (as step 4). You can even force push to the branch you opened the pull request with.
In the usual pull requests that you do when fixing bugs or doing improvements it is absolutely OK to rebase.
Will it work if, before step 1, if you insert systematically a “git pull origin master” ? You will get the last commits from origin missing on your working branch. Then you update from upstream (step 1) and hope that nobody will merge a PR on origin before yours
Is that right ?
Git is not simple, as usual… Powerfull but not easy to master.