Open keikoro opened 3 years ago
Starting a list of files / file contents this would affect:
I think that this is not needed. There are a lot of projects that still remains using master without problems. This change would require a lot of effort for us and maybe the GIT historial could be compromised (I'm not sure)? We should not adjust to the platform because Microsoft has decided to change the default name of their branches.
Anyways, it seems that at the time that you've opened the issue, moviepy was using gh-pages for documentation, but now it's not the case.
For those reasons, I'm closing this request. Feel free to reopen this if you still think that this could be worth.
I'm not wild about the change, but a few points:
This change would require a lot of effort for us and maybe the GIT historial could be compromised (I'm not sure)?
If we did it now, yes. However, Github are introducing features that should make it seamless in the future.
Anyways, it seems that at the time that you've opened the issue, moviepy was using gh-pages for documentation, but now it's not the case.
No, https://zulko.github.io/moviepy is still taken from gh-pages, which must be built manually. https://moviepy.readthedocs.io is built automatically from master. See #1328 for more about that. As discussed, we'll likely continue to use https://zulko.github.io/moviepy for the official documentation, and build it for each release. I'd support moving the built version from gh-pages to a subfolder of master, as having a separate branch for a completely different thing doesn't make much semantic sense to me. Anyway, this isn't something we have to consider until we get closer to v2.0.
If we did it now, yes. However, Github are introducing features that should make it seamless in the future.
If in the future becomes useful rather than a weird concept of more newbie-Github-user friendly, I'll be fine with the change.
No, https://zulko.github.io/moviepy is still taken from gh-pages, which must be built manually
Good to know, thanks :+1:
If in the future becomes useful rather than a weird concept of more newbie-Github-user friendly, I'll be fine with the change.
I understand this to mean that your definition of usefulness does not extend to the user or community side of things, in which case I don't know how it could ever become useful. The underlying issue with the original naming scheme of Git branches is one of language, and the argument I made was me thinking one step ahead; it's not the primary reason why anyone wants to or indeed does change branch names now.
This is something we shouldn't do immediately according to GitHub, but I think it might make sense to rename the
master
branch tomain
once GitHub's tools are ready. Reason being that new users are now "growing up" with default branches on GH and elsewhere being namedmain
, and consistency with that will help when explaining things to new Git users. (Whereas people familiar with Git will understand either way, or should at least not have too hard a time following.)Apart from some one-time config refactorings (GitHub integrations? Dunno how PyPI works exactly), I'm not aware of anything we'd be breaking by renaming the branch. But maybe I'm wrong about that.
The other branch is the one for GitHub pages, where the documentation is hosted. As mentioned already in #1328, I think it might make sense semantically – and again also for beginners not familiar with the inner workings of Git and GitHub – to rename that one from
gh-pages
todocumentation
now that GH does not force users to use the former anymore for GH Pages.