Le 07/10/15 18:49, Stephen Kelly a écrit :
Raffi Enficiaud wrote:
Le 07/10/15 17:02, Andrey Semashev a écrit :
On 07.10.2015 16:27, Raffi Enficiaud wrote:
Since the organization of boost.test is biased by the runners, our develop branch will become a kind of release branch (like master for other less coupled modules). Our internal develop branch (not called develop but something else) will accept force pushes, but this is fine since it is not meant to be checked out by anyone but boost.test developers.
There's one problem with this approach, if you intend to accept patches or pull requests. What branch are they supposed to be against? So far the general rule was to create PRs against develop. Others have mentioned problems with forks in case when history is rewritten, so maybe PRs will become unusable.
The patch can be rebased manually before being commited. This is what they do in eg. CMake and it is working quite well.
Speaking as an upstream CMake maintainer, this statement is not true. Once a commit is reachable from the master branch it is definitely not rebased. The master branch does not get rewritten. Rewriting long-lived branches is wrong.
I was specifically mentioning the case of PR and patches, hence not yet included in the history: they can be rebased as we want quite easily, although manually (a PR can be downloaded as a patch or pulled into a branch).
Temporary branches under review can get rebased. That is very different. Then the temporary branch gets merged to master and the temporary branch is removed.
Correct, in our case, develop is not a temporary branch and has the same public value as master. I believe this is the case for "next" in CMake as well, which serves a bit as our develop. As soon as there is a merge point from the topic to master or next, it is impossible to rewrite the history of the topic (rebase +/- interactive). Best, Raffi