[GitHub] [PR] setting default branch to 'develop'
Hi, We sometimes forget to change the base branch of PR from 'master' to 'develop', even if we know PR should be made against 'develop' branch! To prevent from accidentally making PR against master branch, it'd be nice to **set the default branch to 'develop' branch** for Boost repositories on GitHub. (Then, the default base branch of PR would be set to 'develop' branch.) To change the default branch, it takes just a few clicks on web browser: https://help.github.com/articles/setting-the-default-branch/ Thoughts? Regards, Michel P.S. Some libraries have already done this, but most of Boost libraries don't do this yet.
On Fri, Oct 23, 2015 at 1:09 PM, Michel Morin <mimomorin@gmail.com> wrote:
Hi,
We sometimes forget to change the base branch of PR from 'master' to 'develop', even if we know PR should be made against 'develop' branch! To prevent from accidentally making PR against master branch, it'd be nice to **set the default branch to 'develop' branch** for Boost repositories on GitHub. (Then, the default base branch of PR would be set to 'develop' branch.)
To change the default branch, it takes just a few clicks on web browser: https://help.github.com/articles/setting-the-default-branch/
Thoughts?
I wish there was a global default that could be set for all boost libraries to default pull requests to develop. Is it possible to write a curl script that could make the change for all libraries? --Beman
Beman Dawes wrote:
Is it possible to write a curl script that could make the change for all libraries?
Like this REPOLIST=$(curl https://raw.githubusercontent.com/boostorg/boost/master/.gitmodules \ | awk -F '"' '{print $2}') for REPO in $REPOLIST; do curl --user $USERNAME:$PASSWORD \ --data '{"name": $REPO, "default_branch":"develop"}' \ https://api.github.com/repos/boostorg/$REPO done ? (You need to set USERNAME and PASSWORD in some way before using the command.) Regards, Michel
On 28 October 2015 at 03:20, Michel Morin <mimomorin@gmail.com> wrote:
Beman Dawes wrote:
Is it possible to write a curl script that could make the change for all libraries?
Like this
REPOLIST=$(curl https://raw.githubusercontent.com/boostorg/boost/master/.gitmodules \ | awk -F '"' '{print $2}') for REPO in $REPOLIST; do curl --user $USERNAME:$PASSWORD \ --data '{"name": $REPO, "default_branch":"develop"}' \ https://api.github.com/repos/boostorg/$REPO done
There are several modules that will miss. I can write a more thorough script tonight if wanted - I've got most of the required mechanisms implemented already (for the commit-bot, doc build etc.).
On 28-Oct-15 6:20 AM, Michel Morin wrote:
Beman Dawes wrote:
Is it possible to write a curl script that could make the change for all libraries?
Like this
REPOLIST=$(curl https://raw.githubusercontent.com/boostorg/boost/master/.gitmodules \ | awk -F '"' '{print $2}') for REPO in $REPOLIST; do curl --user $USERNAME:$PASSWORD \ --data '{"name": $REPO, "default_branch":"develop"}' \ https://api.github.com/repos/boostorg/$REPO done
? (You need to set USERNAME and PASSWORD in some way before using the command.)
I have ran the above, with some quoting fixes: REPOLIST=$(curl https://raw.githubusercontent.com/boostorg/boost/master/.gitmodules | awk -F '"' '{print $2}') for REPO in $REPOLIST; do curl -H "Authorization: token <redacted>" --data "{\"name\": \"$REPO\", \"default_branch\": \"develop\"}" https://api.github.com/repos/boostorg/$REPO; done This has updated every repo that is included in master. I've updated hana by hand. Is this fine with everybody? -- Vladimir Prus http://vladimirprus.com
On 10/28/2015 12:50 PM, Vladimir Prus wrote:
On 28-Oct-15 6:20 AM, Michel Morin wrote:
Beman Dawes wrote:
Is it possible to write a curl script that could make the change for all libraries?
Like this
REPOLIST=$(curl https://raw.githubusercontent.com/boostorg/boost/master/.gitmodules \ | awk -F '"' '{print $2}') for REPO in $REPOLIST; do curl --user $USERNAME:$PASSWORD \ --data '{"name": $REPO, "default_branch":"develop"}' \ https://api.github.com/repos/boostorg/$REPO done
? (You need to set USERNAME and PASSWORD in some way before using the command.)
I have ran the above, with some quoting fixes:
REPOLIST=$(curl https://raw.githubusercontent.com/boostorg/boost/master/.gitmodules | awk -F '"' '{print $2}') for REPO in $REPOLIST; do curl -H "Authorization: token <redacted>" --data "{\"name\": \"$REPO\", \"default_branch\": \"develop\"}" https://api.github.com/repos/boostorg/$REPO; done
This has updated every repo that is included in master. I've updated hana by hand.
Is this fine with everybody?
I think it should be run on develop since we have submodules that only exist on develop and not master. I think there's one consequence of this change that has not been mentioned in the discussion. When checking out libraries from git people will get develop branch by default and not master. This is fine if the checkout is done for development, which is the most likely the case, but may be a surprise to some who expect to get master by default. Personally, I'm ok with this change.
Andrey Semashev wrote:
When checking out libraries from git people will get develop branch by default and not master. This is fine if the checkout is done for development, which is the most likely the case, but may be a surprise to some who expect to get master by default.
I assumed the former (i.e. the checkout is for development and so setting the default branch to 'develop' is fine), but the latter may be true as well. Thanks for bringing this up. Regards, Michel
On 28/10/2015 12:58, Michel Morin wrote:
Andrey Semashev wrote:
When checking out libraries from git people will get develop branch by default and not master. This is fine if the checkout is done for development, which is the most likely the case, but may be a surprise to some who expect to get master by default. I assumed the former (i.e. the checkout is for development and so setting the default branch to 'develop' is fine), but the latter may be true as well. Thanks for bringing this up.
This also has the side-effect that if someone hits the "download zip" button they get develop, which is probably not what we want? John.
On Thu, Oct 29, 2015, John Maddock wrote:
This also has the side-effect that if someone hits the "download zip" button they get develop, which is probably not what we want?
I feel that it is certainly not what we want. It seems counter-intuitive (going by what appears to be widespread practice with public git repositories) that the 'default' branch is not the stable one. I understand the motivation, but couldn't we just request from any contributors to submit a new pull request against 'develop' instead of 'master'? Glen
Glen Fernandes wrote:
I understand the motivation, but couldn't we just request from any contributors to submit a new pull request against 'develop' instead of 'master'?
Or, someone with Github connections could try to convince them to add a feature that would allow us to set the default pull request branch separately. :-)
On 10/30/2015 04:25 AM, Peter Dimov wrote:
Glen Fernandes wrote:
I understand the motivation, but couldn't we just request from any contributors to submit a new pull request against 'develop' instead of 'master'?
Or, someone with Github connections could try to convince them to add a feature that would allow us to set the default pull request branch separately. :-)
I suspect that would be difficult to do or counter-intuitive. If the default branch is master then the user sees master by default in the web interface, including when he does online edits. When he commits the edits and creates a pull request he has a choice of the target branch. If that branch is develop it is very likely that the PR will have conflicts because he edited master. And that is counter-intuitive because he initially forked from master, so why would the system create a PR for develop? The logical solution for this is to show develop in the web interface by default (thus making edits and PRs on develop by default) and that is what the default branch does.
On 30-Oct-15 4:12 AM, Glen Fernandes wrote:
On Thu, Oct 29, 2015, John Maddock wrote:
This also has the side-effect that if someone hits the "download zip" button they get develop, which is probably not what we want?
I feel that it is certainly not what we want. It seems counter-intuitive (going by what appears to be widespread practice with public git repositories) that the 'default' branch is not the stable one.
That's a good argument, but Boost is not really following standard git practices already. For most projects, you'd send pull requests against master, which would be sort of stable, and then releases would be made from a release branch off master. We do all development on 'develop', with 'master' updated rarely, and often maintainers forget to update 'master' at all. If somebody checks out an individual Boost repository, he probably does it to contribute to development. Checking out it for production use seems unlikely, since for production use you'd need to check out dozens of repositories, and doing that individually is extra painful, comparing to just cloning superproject (whose default branch *is* master still). And if you checkout an individual repository to send pull requests, getting 3-month old 'master' branch is not very useful.
I understand the motivation, but couldn't we just request from any contributors to submit a new pull request against 'develop' instead of 'master'?
I doubt anybody would read any instructions before sending a one-line fix. -- Vladimir Prus http://vladimirprus.com
On 10/30/2015 10:17 AM, Vladimir Prus wrote:
Checking out it for production use seems unlikely, since for production use you'd need to check out dozens of repositories, and doing that individually is extra painful, comparing to just cloning superproject (whose default branch *is* master still).
Hmm, although I understand your reasoning, I find this distinction quite surprising. I'll add that using git checkouts at some stage of production is quite possible and probably wide spread. But you don't just check out whatever is the latest commit and whatever is the default branch in that case. You always want a specific tag or revision (much more rarely - a specific branch, if it is stable enough) to checkout, and you want to update the tag/revision very explicitly, e.g. when you upgrade from one release to another.
Vladimir Prus wrote:
I have ran the above, with some quoting fixes:
Great! Thanks for doing this and fixing incorrect quoting.
https://raw.githubusercontent.com/boostorg/boost/master/.gitmodules | awk -F [...] This has updated every repo that is included in master.
Oops, I forgot to change 'master' to 'develop' in the URL... Regards, Michel
Vladimir Prus <vladimir.prus <at> gmail.com> writes:
On 28-Oct-15 6:20 AM, Michel Morin wrote:
Beman Dawes wrote:
Is it possible to write a curl script that could make the change for all libraries?
Like this
[...]
? (You need to set USERNAME and PASSWORD in some way before using the command.)
I have ran the above, with some quoting fixes:
[...]
This has updated every repo that is included in master. I've updated hana by hand.
Is this fine with everybody?
No, it isn't. The only way of getting Hana right now is by cloning it from GitHub. By making the default branch `develop`, you automatically make any script that uses `git clone https://github.com/boostorg/hana` clone the `develop` branch, and thus potentially clone something broken. Also, the README shows the current status of the Travis CI build for the master branch. By defaulting the branch to develop, most people will now see information that is misleading. In general, I don't think defaulting pull-requests to master is a sufficient argument for changing the default branch. There is a nice CONTRIBUTING file at the root of the project telling people to pull-request against develop, and I am always free to close pull-requests that do not follow this advice. That being said, I don't care much about what is done for other libraries, but I do care about Hana. Hence, please revert the default branch to master for Hana. Also, shouldn't I be the one to have sufficient admin rights to change that kind of thing? I don't like the idea that anyone with sufficient rights within 'boostorg' can do as they please with my repository ('my' taken lightly). In this case it's fine because I saw the thread and I'm sure Vladimir will revert the change, but in general I think the author should be in control of such things to avoid silent breakages. Regards, Louis
On 29-Oct-15 4:07 AM, Louis Dionne wrote:
Vladimir Prus <vladimir.prus <at> gmail.com> writes:
On 28-Oct-15 6:20 AM, Michel Morin wrote:
Beman Dawes wrote:
Is it possible to write a curl script that could make the change for all libraries?
Like this
[...]
? (You need to set USERNAME and PASSWORD in some way before using the command.)
I have ran the above, with some quoting fixes:
[...]
This has updated every repo that is included in master. I've updated hana by hand.
Is this fine with everybody?
No, it isn't. The only way of getting Hana right now is by cloning it from GitHub. By making the default branch `develop`, you automatically make any script that uses `git clone https://github.com/boostorg/hana` clone the `develop` branch, and thus potentially clone something broken. ... In general, I don't think defaulting pull-requests to master is a sufficient argument for changing the default branch. There is a nice CONTRIBUTING file at the root of the project telling people to pull-request against develop, and I am always free to close pull-requests that do not follow this advice. That being said, I don't care much about what is done for other libraries, but I do care about Hana. Hence, please revert the default branch to master for Hana.
I have set default branch for Hana back to master. That said, I believe that once Hana is included in Boost releases, the decision about default branch should be made depending on what is right for users of Boost. Which, I believe, is to have default branch be 'develop'. Somebody who contributes to Boost is a whole should not be forced to read files in individual repositories to figure out which branch to send pull requests too. - Volodya -- Vladimir Prus http://vladimirprus.com
Vladimir Prus <vladimir.prus <at> gmail.com> writes:
On 29-Oct-15 4:07 AM, Louis Dionne wrote:
Vladimir Prus <vladimir.prus <at> gmail.com> writes:
[...]
Is this fine with everybody?
No, it isn't. The only way of getting Hana right now is by cloning it from GitHub. By making the default branch `develop`, you automatically make any script that uses `git clone https://github.com/boostorg/hana` clone the `develop` branch, and thus potentially clone something broken. ... In general, I don't think defaulting pull-requests to master is a sufficient argument for changing the default branch. There is a nice CONTRIBUTING file at the root of the project telling people to pull-request against develop, and I am always free to close pull-requests that do not follow this advice. That being said, I don't care much about what is done for other libraries, but I do care about Hana. Hence, please revert the default branch to master for Hana.
I have set default branch for Hana back to master.
Thank you!
That said, I believe that once Hana is included in Boost releases, the decision about default branch should be made depending on what is right for users of Boost. Which, I believe, is to have default branch be 'develop'.
We disagree on that point, and it seems like the decision is not as obvious as it seems. Clearly, changing the default branch has more consequences than simply defaulting pull-requests against `develop`. I, for one, have never been annoyed by the need to explicitly pull-request against `develop`. Hence, I don't think saving one click once or twice per month (how often do you submit PRs?) is worth adopting a surprising behaviour the rest of the time. I say surprising because people are used to `master` being the default branch on GitHub. We should also take into account the fact that the number of users cloning a repository or downloading the tarball from GitHub is probably much larger than the number of pull requests we submit. How many WTFs from users is this going to generate? To me, it just seems like we should stick with the standard behaviour. We can also request a new GitHub feature for setting the default pull-request branch, which, let's not forget, is the original motivation for this whole discussion.
Somebody who contributes to Boost is a whole should not be forced to read files in individual repositories to figure out which branch to send pull requests too.
Sure. Hana also requires pull requests to be made against develop, so there's no need to read the CONTRIBUTING document. Regards, Louis
On 29-Oct-15 4:07 AM, Louis Dionne wrote:
Also, shouldn't I be the one to have sufficient admin rights to change that kind of thing? I don't like the idea that anyone with sufficient rights within 'boostorg' can do as they please with my repository ('my' taken lightly).
Until yesterday (almost literally), it was not possible to give you admin permissions for 'hana', without also giving you admin permissions for every other repository in the 'boostorg' organization. I've now tweaked the settings so that you can add/remove collaborators on 'hana'. Note, however, that those with sufficient permissions in the 'boostorg' organization will always be able to change settings on 'boostorg/hana'. While any changes will be mentioned on the mailing list, and generally un-doable, it's just not possible to lock your repository, nor would it be reasonable to ask people to individually tweak settings on 100+ repositories. - Volodya -- Vladimir Prus http://vladimirprus.com
Vladimir Prus <vladimir.prus <at> gmail.com> writes:
On 29-Oct-15 4:07 AM, Louis Dionne wrote:
Also, shouldn't I be the one to have sufficient admin rights to change that kind of thing? I don't like the idea that anyone with sufficient rights within 'boostorg' can do as they please with my repository ('my' taken lightly).
Until yesterday (almost literally), it was not possible to give you admin permissions for 'hana', without also giving you admin permissions for every other repository in the 'boostorg' organization. I've now tweaked the settings so that you can add/remove collaborators on 'hana'.
Thanks a lot! I now also have access to the repository hooks and other things I lost when transferring to boostorg. That's much better!
Note, however, that those with sufficient permissions in the 'boostorg' organization will always be able to change settings on 'boostorg/hana'. While any changes will be mentioned on the mailing list, and generally un-doable, it's just not possible to lock your repository, nor would it be reasonable to ask people to individually tweak settings on 100+ repositories.
When a library has an active maintainer, I think the very least would be to ask the maintainer for such things before doing them, especially if they are undoable. I might be a control freak, but I don't like the idea that someone can play around with a setup that I might have spent several hours setting up and potentially break it. The very least would be to announce such changes on the mailing list, ask for feedback and see if anyone disagrees. Once some agreement has been reached (and I'm not asking for consensus), we could then proceed with the changes. Regards, Louis
On 29-Oct-15 9:39 PM, Louis Dionne wrote:
When a library has an active maintainer, I think the very least would be to ask the maintainer for such things before doing them, especially if they are undoable. I might be a control freak, but I don't like the idea that someone can play around with a setup that I might have spent several hours setting up and potentially break it. The very least would be to announce such changes on the mailing list, ask for feedback and see if anyone disagrees. Once some agreement has been reached (and I'm not asking for consensus), we could then proceed with the changes.
I have possibly done this change too quickly, and I apologize. The one way I can address your concerns is by saying that this particular change was non-destructive, and that any larger change would certainly be announced more prominently and well in advance. - Volodya -- Vladimir Prus http://vladimirprus.com
Vladimir Prus-4 wrote
I have possibly done this change too quickly, and I apologize.
The one way I can address your concerns is by saying that this particular change was non-destructive, and that any larger change would certainly be announced more prominently and well in advance.
No worries, I hold no grudge against you. Thanks for promptly answering my request. Regards, Louis -- View this message in context: http://boost.2283326.n4.nabble.com/GitHub-PR-setting-default-branch-to-devel... Sent from the Boost - Dev mailing list archive at Nabble.com.
On 10/23/15 10:09 AM, Michel Morin wrote:
Hi,
We sometimes forget to change the base branch of PR from 'master' to 'develop', even if we know PR should be made against 'develop' branch! To prevent from accidentally making PR against master branch, it'd be nice to **set the default branch to 'develop' branch** for Boost repositories on GitHub. (Then, the default base branch of PR would be set to 'develop' branch.)
To change the default branch, it takes just a few clicks on web browser: https://help.github.com/articles/setting-the-default-branch/
Thoughts?
I tried to do this - but I don't have a settings icon on my github page
Regards, Michel
P.S. Some libraries have already done this, but most of Boost libraries don't do this yet.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Robert Ramey wrote:
To change the default branch, it takes just a few clicks on web browser: https://help.github.com/articles/setting-the-default-branch/
Thoughts?
I tried to do this - but I don't have a settings icon on my github page
Hmm, that means you have write access to the repo but don't have admin access. I guess there are admin or owner teams for 'boostorg' organization that have permissions to change the default repository. Regards, Michel
participants (10)
-
Andrey Semashev -
Beman Dawes -
Daniel James -
Glen Fernandes -
John Maddock -
Louis Dionne -
Michel Morin -
Peter Dimov -
Robert Ramey -
Vladimir Prus