search

pypy / pypy.org

Sources for website at https://www.pypy.org
33 stars 11 forks source link

PyPy has moved to Git, GitHub | PyPy #109

Open utterances-bot opened 6 months ago

utterances-bot commented 6 months ago

PyPy has moved to Git, GitHub | PyPy

https://www.pypy.org/posts/2023/12/pypy-moved-to-git-github.html

mattip commented 6 months ago

On reddit someone commented:

That process was likely a lot slower than it needed to be. You generally don't need to check out a git ref to operate on the ref itself, only if you actually really need to change your working tree.

Since the git notes add command works on the current HEAD, I needed to checkout each commit in turn and then add the note

git notes add works on the current HEAD.... by default. You can easily pass it an object id to avoid the checkout.

while read branch; do git checkout branches/$branch && git push origin branches/$branch; done < branches.txt

Same thing, you don't need to check out a ref to push it.

git push origin <branch>

You can even just push just a commit hash, just if you do you need to tell git to push it as a new head to the remote by explicitly stating the namespace:

git push origin <hash>:refs/heads/<branchname>

amunizp commented 6 months ago

Was gitlab considered? Could it be considered? Should be easier after the move to git.

mattip commented 6 months ago

We were on gitlab: foss.heptapod.net is a friendly fork of gitlab. The problem is the friction of interacting with other software packages when they all are located on github.

arigo commented 6 months ago

People who wish to continue to use Mercurial can use the same method below to push to GitHub.

I don't think this sentence alone will help people like me that are not very familiar with git. As far as I understand it, outside contributors on github must go through the process of making a clone on github, fetching a local copy, pushing some new commits in it, and using the github web interface to propose that as a pull request back to the main repo. Is there also very different approach starting with the mercurial copy of the repo somehow?

mattip commented 6 months ago

On 3/1/24 11:30, Armin Rigo wrote:

People who wish to continue to use Mercurial can use the same
method below to push to GitHub.

I don't think this sentence alone will help people like me that are not very familiar with git. As far as I understand it, outside contributors on github must go through the process of making a clone on github, fetching a local copy, pushing some new commits in it, and using the github web interface to propose that as a pull request back to the main repo.

Yes, I think that is accurate. The path I detail in the blog post is to convert a hg repo to a git one, not to remain with mercurial. I phrased it in a misleading way, sorry.

Is there also very different approach starting with the mercurial copy of the repo somehow?

—

There may be some way to use the github API to create a pull request from a patch file, but it is bound to be complicated. I would suggest that if people wish to avoid git, they submit patches to a github issue. You may be able to use the hg-git mercurial plugin [0] to keep up-to-date with the latest pypy HEADs.

Maybe the heptapod people have other ideas.

Matti

[0] https://hg-git.github.io/

arigo commented 6 months ago

Thanks! So the best solution for me is probably just to check out the new pypy repo in the usual way with git and then submit patches as github issues, generated with the appropriate set of git diff options.

mattip commented 6 months ago

People who wish to continue to use Mercurial can use the same method below to push to GitHub.

Well, I may have misrepresented that. I meant "people who wish to convert their local Mercurial repo to Git". But truthfully it is probably easier to do git clone https://github.com/pypy/pypy than to convert the repo and get all the correct branches.

glandium commented 5 months ago

You should ask github to repack the pypy repo, because it's 2GB instead of the 200MB it could be after an aggressive repack or 400MB after a less aggressive repack. Presumably, you just pushed the result of git-remote-hg without a repack, and git-remote-hg isn't really great at creating tight packs.

cfbolz commented 5 months ago

@glandium: interesting suggestion! how would we do that? is that exposed in the UI or do you need to send an email to the right person?

GreyXor commented 5 months ago

Github an open source synonymous ? Guys, are you aware that GitHub itself isn't open source ? What a joke.

mattip commented 5 months ago

You should ask github to repack the pypy repo

Thanks @glandium. I reached out to github support and they did something, now the repo is much smaller.

BugZappr commented 3 months ago

It's sad that Hg is being abandoned in droves. I only use it for my personal SCM needs, but IMHO, here are things it still stands out on.

I can't say if the advantages of Git hold up under scrutiny for larger projects, e.g. in terms of performance. Hg is probably compiled in something like PyPy, so it should be comparable in terms of performance. Anyway, you can add these to lists of how Hg is better. I'm really glad QtCreator supports it, anyway.

arigo commented 3 months ago

@BugZappr some of us in the PyPy project agree with you. Personally, I just can't use git, I break it as soon as I try to go beyond the basics. Sadly, the world moved on, and nowadays being a git project is kinda expected for all serious open-source projects. Also, Github adds more and more conveniences whereas public Mercurial equivalents abandon their Mercurial support.

mattip commented 3 months ago

readthedocs.org, where we host our documentation, announced they will only support git, so it is a good thing we moved when we did. We could host our documentation from github pages instead, this also requires git.