-
-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rename master branch to main for the core package and coordinated packages #151
Comments
GitHub's guidance at https://github.com/github/renaming suggests waiting until later this year as they will provide tools to make it a lot easier to migrate existing repositories. But I agree we should do this once the tools are available. |
Re-visiting this topic since we got through "later this year" - looking at https://github.com/github/renaming, it looks like they've implemented what they're going to implement, which is all the internal github things, but of course there's no definitive way to update it in user environments. So there's still a hump there, but I think it's as far as can be done automatically. So if we were to start rolling this out here's I think what would have to happen:
We should probably try this out in some lower-traffic repo first. I'll sniff around for some options (possibly not in |
@eteq , I feel like we need to provide memos to all the usual comm channels before actually implementing it, so no one is taken by surprise; and if they still are surprised, we can say, "lookie here, here, and here" |
Definitely, @pllim ! Good point, that should come before we do any of the steps I said above. I think after I've done my investigation I'll draft something for astropy-dev since that might prompt further discussion than this thread. |
As an update here: I transitioned several repos that are "institution-owned" following the github process (spacetelescope/jdaviz, spacetelescope/jdat_notebooks, spacetelescope/dat_pyinthesky), and it was relatively painless. To summarize the process:
Here's a possible example of README text:
|
It was pointed out out-of-band by @bsipocz that the So updated version:
|
FYI -- In the infrastructure/DevOps tag-up today, we have decided to push this forward for the Project, with @eteq leading the effort. |
Nice! Note that numpy already moved. It meant a few PRs broke, but it seems those were abandoned at the level of the user no longer having the repository - see numpy/numpy#18543 |
I think it's less likely here to run into those PRs, as we bot close the old ones anyway. The email went out, so this is water under the bridge, but I think the commands above should use |
Agree with @bsipocz on the naming ( |
I opened issues on the repos in the org, except for https://github.com/astropy/old-astropy-website-src -- That one does not have "Issues" enabled. |
@adrn also mentions https://github.com/dfm/rename-github-default-branch by @dfm that renames the branch programmatically. There is also SO thread https://stackoverflow.com/questions/52776313/set-github-default-branch-through-api-call . Of course, you need the necessary permission on the repos to run this. |
Indeed, I also use |
Indeed, And to demonstrate how confusing upstream/origin are, my comment above has the mistake of calling origin astropy while is should be the github username. But, there is also another mistake in Erik's commands, namely the fetch should be for upstream rather than origin. Out-of-band though I suggested using |
Whether It was pointed out out-of-band by @bsipocz that the So updated markdown version:
and an RST version:
|
One nice thing I realized in astropy/astropy-APEs#66 : links to the "old" name still work, they just redirect. So e.g. https://github.com/astropy/astropy-APEs/blob/master/APE8.rst is not broken, but rather now redirects to https://github.com/astropy/astropy-APEs/blob/main/APE8.rst (albiet with a banner that says the name was changed) |
Oh, the redirect is great, that means @pllim could just go ahead and merge most of the PRs she opened yesterday as there is no circular dependencies any more :) |
I am totally lost when you say that using your local main/master is "bad". It is basically not possible to do astropy development without frequently referring to the |
Anyone knows how long the redirect would work? |
😅 I merged some for the infrastructure stuff. For the rest, would still be nice for someone else to review, just in case. |
main/master as on the fork. You should refer to the main branch on the "canonical" version from the astropy org, but should not refer to the main on your fork as it's outdated by default, and in fact a bit of a pain to keep up-to-date. And there were multiple cases where it was the source of extreme git pain with rebases (people ended up with doubling commits after a rebase as they referring to the master of a fork rather than the "central" repo, etc.). I say "canonical"/"central" as I have no better word for it, after all git is fully decentralized, we just use it in a way that there is one reference, central version that lives under the astropy org. |
worth asking at the helpdesk, but given that they keep the references to hashes of commits that are not on branches any more, I would not be surprised if this would stay on forever as a side effect of the rename (and if so, this is yet another reason to do it with the rename tool rather than creating a new "main" branch and change it to default). |
Slightly OT (I can open a new issue), but doing some googling on "github fork workflow" showed that the top 4 search hits where they specifically named the "canonical" version, that remote was always called There is also https://guides.github.com/activities/forking/ from GitHub that calls the canonical version |
And indeed numpy uses |
Let's move the discussions about remote naming to astropy/astropy#11383 . FWIW, personally, I have always used |
Yes, I much prefer to use (think about |
When the canon repo moves around, I go into my local clone and do a I don't think there is a right or wrong way, just everyone has their own preference. |
I've always used |
Yeah, but at the end of the day you need to know it when you open the PR 🤷♀️ Also, I clearly have no issues when it's personal preference, but think it's worth to know the use cases where the other approach may work better (I really just had to do way too many rebases for others that were due to this origin+upstream+one more fork confusion) |
I make sure I always clone from the "upstream" repository and keep it's name as "origin". (Usually, I do that clone before I even have my own fork anyway). I then add my own fork of the project with some canonical name (I use "github" or "bitbucket"). But, I agree, different workflows work, so it's good to be consistent within our documentation. People who use different personal conventions hopefully know enough to know to to modify the instructions for their situation. |
To close the loop on how long the GitHub has made changes and introduced features to support projects and maintainers that want to rename their default branch. Web requests for the old branch name will now be redirected to the new branch name for as long as such links are used within your projects. You can read more about the feature release here: |
I think this is done, right? Did we miss anything? |
reproject now has |
The actual implementation might need to be repo-level issues, but I think the agreement on this should come at a Project level, hence why I'm making this issue in this repo.
The default git name
master
is very problematic language that causes active harm and is anti-inclusive - you can see more about this from git itself or any of a variety of other resources I can link if there's debate about this.However, assuming others agree with this as a goal, the issue here is to actually work out the mechanics of this. Just changing the name without doing anything else is problematic because it breaks pending PRs, local workflows, etc. I think github and git are working on making this easier (@astrofrog mentioned something about this that perhaps he can link here), but this issue is for working out those details.
The text was updated successfully, but these errors were encountered: