Skip to content
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

docs: Change remote nick to origin and capitalize version commit #3559

Merged
merged 1 commit into from
Aug 27, 2024

Conversation

joelostblom
Copy link
Contributor

Since this will always be read by a contributor who has push rights to main, the assumption would be that they are working in the upstreams repo already, so shouldn't we reference origin instead of upstream?

I capitalized the commits to be consistent with how we write PR titles.

@joelostblom joelostblom changed the title Change repo nickname and capitalize version docs: Change remote nick to origin and capitalize version commit Aug 27, 2024
@dangotbanned
Copy link
Member

This isn't blocking btw, but thought I had some insight as my current situation is an example where your assumption doesn't hold.

I have several PRs that were opened before I became a maintainer, which are still in my fork https://github.com/dangotbanned/altair/branches/yours

I think I've only done one/two since in upstream.
IIRC, I had some issues with the change in workflow but eventually would want to transition to working in upstream more often

@joelostblom
Copy link
Contributor Author

Good point. If someone already have a fork once they become a maintainer (which is probably the case for everyone), they might keep working there and then upstream is more appropriate than origin. I would expect most contributors transitioning to working on branches in the repo directly, but I understand that doesn't have to be true and there could be a preference to keep working in the fork. Do you prefer that I revert it back to upstream?

@dangotbanned
Copy link
Member

Good point. If someone already have a fork once they become a maintainer (which is probably the case for everyone), they might keep working there and then upstream is more appropriate than origin. I would expect most contributors transitioning to working on branches in the repo directly, but I understand that doesn't have to be true and there could be a preference to keep working in the fork. Do you prefer that I revert it back to upstream?

No strong preference from me really, especially as my situation is only temporary.

Am I understanding this correctly?
Say for example I were to cut a release, using origin would require that working in the repo directly - but upstream would work in either case?

@joelostblom
Copy link
Contributor Author

By default after cloning a repo (whether it is a fork or not), I believe there is only one remote and it is named origin and pointing to the location of the cloned repo (regardless of whether it is a fork or not). You would have to explicitly add an additional remote and name it upstream that points to the main altair repo for it to work from both the fork and main repo (but this would be unnecessary if you cloned the main repo directly since then origin would already point to this remote).

Copy link
Member

@dangotbanned dangotbanned left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems a reasonable change given #3559 (comment)

Thanks @joelostblom

@binste
Copy link
Contributor

binste commented Aug 27, 2024

I don't have a preference as it's easy to exchange it :) Btw, I'm still working on my fork, just kind of like the additional layer of separation it gives so I don't accidentally push anything to main as we have not protected it against direct pushs.

@joelostblom
Copy link
Contributor Author

so I don't accidentally push anything to main as we have not protected it against direct pushs.

That raises a good point, maybe we should? We can still merge our own PRs I believe, so the version bumps that we do when releasing could still be done by one person.

@joelostblom joelostblom merged commit 3da2e9e into main Aug 27, 2024
25 of 26 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants