Turns out that *more* than one of the contributors to Joinmarket has had their github account banned/blocked, but it seems not directly related to current news - it seems it happened specifically to people that only logged in via Tor.

I'm not sure of details, obviously, just reporting what I've heard.

Gitlab migration may be incoming.

· · Web · 1 · 2 · 1

@sjors yes. i have had reports that some are *not* having problems while logging in only over Tor. But obviously one cannot know all the personal details of each person (e.g. how/when did they create their account, what else have they done). So in the dark, which is as usual for such things ...

@waxwing @sjors Considering a self-hosted instance? They're quite close to being federation-ready so you can contribute cross-instance.

@stevenroose @sjors i was interested in this, but then somebody told me that you can only sync the repo to the self-hosted gitea not the issues/PRs?

@stevenroose @sjors I mean, obviously this is only needed for issues/PRs, not for code, right? In which case code-only replication is not interesting. I think I must have missed something.

@waxwing @sjors Like @raucao pointed out the migration procedure provides you can migrate most GitHub data over to the new instance.

And with federation, people from public instances can (will be able to*?) automatically contribute to repos on your instance without having to create an account locally.

@stevenroose @waxwing @raucao
> this is only needed for issues/PRs, not for code, right

Ideally you want a backup of every version of the pull request, at the time the comments were coming in. In Bitcoin Core those disappear because the commits in pull requests are kept clean using force pushes.

@sjors @stevenroose @waxwing Force pushes are an antipattern and should be avoided. PRs need the full history for people to follow updates most efficiently. The branch should be cleaned up when (or just before) merging the code IMO. GitHub even has a button for squash-merging.

@sjors @stevenroose @waxwing That said, code comments aren't directly tied to commits, and they are indeed migrated to GItea when using Gitea's built-in migration tool.

@raucao @sjors @waxwing yeah this squashing is what force pushes are for, right? Often during different stages in review, I think it can be useful to force-push into a clean history from time to time during a longer review process

@stevenroose @raucao @waxwing the three downsides of squash commits are:
1. You lose the PGP sig of the original author
2. Git blame provides less clear historical documentation, because the real
change is burried onder "fixup" instead of actual
3. I tend to review PR per commit. Reasoning through bugs that are fixed in later commits is more difficult and error prone.

Some devs keep unsquashed history in a seperate branch, but that involves more skill, i.e. barrier to contributing.

@stevenroose @raucao @waxwing re (2) I use git blame a lot when trying to understand a piece or code and how it came to be. Github has a nice interface for that.

@sjors @stevenroose @waxwing Yes, my point was exactly that the history should be clean in the end, but I disagree about force-pushing to *shared, collaborative* branches. I think authors should clean up their history before merge.

@sjors @stevenroose @waxwing The problem is that with complex changes, i.e. the larger the PR changeset, the more difficult it is to follow along while changes are coming in, when new changes are force-pushed. Precisely because you cannot review incoming changes by commit then.

@sjors @stevenroose @waxwing ... However, it really depends on the repo, project, and contributors, of course. Just as a general rule of thumb, I think "do not force-push to collaborative branches" is a good best practice to start out with on most repos.

@raucao @sjors @stevenroose yeah these are some good points, it's pretty troublesome and not always having a full history of changes can be a pain.

@waxwing @stevenroose @sjors The migration also works for issues, PRs, milestones, and releases.

@waxwing @stevenroose @sjors But without federation it's much less accessible for potential contributors, of course. Because everyone needs an account on your instance for PRs, or they have to send patches via email, as Linus intended.

Sign in to participate in the conversation
unidentified instance

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!