I'm moving my projects off GitHub | Hacker News Reader

I'm moving my projects off GitHub

ntietz.com

103 pointsnalgeon112 comments

Open articleView on HN

> As a GitHub user, I was always seeking green squares to try to make sure I had activity every day.

I have never paid any attention to that at all. It surprises me that some do.

Do you think it's common?

I think it is common, but completely absurd.

Why are green squares _every day_ a good thing?

Have a life. Live your life. There is more than just code.

I've used github for 10 years or more. I've never met someone who pays attention to the green squares. I see some online but that's it

Would you say that it's because they're probably at home chasing green squares?

Joking aside, I've known only one person who did (does?) this. They're a great engineer but frequently get into the weeds on assignments. This is just anecdote, but these types of people definitely exist.

This thread is the first time I’ve even heard about people caring about the squares.

I hire programmers (and was one for more than two-and-a-half decades). I don't look at green squares on GitHub.

Same. In fact, I discovered git-backdate [1] which can specifically be used to hide the fact that your working hours are a bit deranged.

[1] https://github.com/rixx/git-backdate

Either you discovered it within the 10~ish days it exists or someone is fudging the timeline...

It was 5 days ago

Nice, I had been thinking for a long time about writing such a tool that adjusts all commits on personal projects to be outside business hours (although of course that's not going to be an acknowledged use).

Seems the same as chasing Pokemons or trying to become the "mayor" of something on FourSquare - a useless virtual accolade.

These green squares helped John Resig for about 4 years: https://johnresig.com/blog/write-code-every-day/

Interesting angle. This kind of robotic tracking has also helped me with personal aspirations (exercise a key one). I suppose it is all in how you use it. In fact, I even stopped using it at one point for another activity because it was making it feel like a chore. For that one it is more satisfying to allow myself to skip it.

Do you think it's common?

Yes. I see it more and more these days, especially among recruiters and HR departments.

I believe there's an inverse correlation between the value one places on green squares and their understanding of what it actually takes to build software...

https://eddiots.com/931

https://eddiots.com/447

https://eddiots.com/2461

https://eddiots.com/2390

At one point, you could backdate commits and push them to GitHub to make art with the red/green squares. I don't know if that still works, but recruiters generally won't be able to tell whether you're faking commit activity.

This definitely still works.

Exactly. I hate this too. I'd rather keep my github activity private. It's nobody's business to know if I commit 30 times per hour or once per week.

On the other hand I recently encountered a very interesting hiring process. I think this is the first time in 20 years when I'm encountering some "new idea in recruitment" and I actually think it's good for everyone.

I'm talking about coding/other task based challenges you complete on your own. I recently got something like this sent by a recruiter. (2 coding challenges, one - writing a email to a junior colleague telling them how to troubleshoot an imaginary backend issue). I was very pleasantly surprised that web based system had over 20 languages you could choose from to complete the challenges and once I've completed it around midnight my time, by 7am it was already scored (by humans and pretty well).

I much prefer this kind of stuff to traditional "share your screen via video all and code live" or pre-covid, write your code with a pen on a whiteboard...

As for cheating possibility... They openly allow one to use Google etc, but there is barely enough time to complete the task, so someone extensively searching on Google, or trying to use chatgpt for the task would run out of time tweaking the prompt very quickly.

i am not exactly a fan of coding challenges and i do like laive coding, but that challenge to write an email to a junior colleague telling them how to troubleshoot an imaginary backend issue sounds like something i'd really enjoy doing.

I've been a proponent of the code-to-hire process for at least a decade.

There are for sure some challenges (some legal, some technical) but those replace other challenges that I think are less effective.

Interviews are pretty low value for skill-set - mostly for personality.

GitHub and SocialMedia spying don't reveal much about the Person-at-Work.

So, currently we find a nice candidate, brief interview for personality/communication then code test them. And I pay for the time too - but that value is capped for tax/paperwork reasons.

I think this is a good hiring process. There is research which suggests that the hiring process which produces the highest performing hires is one that sticks as closely as possible to evaluating the candidate's performance on the specific tasks involved in the job.

In a dev job you're writing code, you have some degree of time constraint, you get to use Google. You're emailing a colleague with advice/suggestions. So yep. That company's test is pretty on the money.

We've used a similar process and it's super interesting to be on the hiring side and compare the results from different candidates when you give them the same problem. There were people who sounded really smart and polished in an interview but then bombed the coding test.

Was this the Woven-ran 4 question (recommendation system, email junior, invoice, database schema) interview? If so, I think the 4 questions are pretty good. The issue is I've had the exact same interview 3 times now from 3 different companies who use Woven.

If not, it sounded quite similar.

I remember a HN post where someone used git history to make pictures out of their github tracker. Seems like a silly thing for companies to pay attention to. I'm pretty sure you can make up old history if you want, too -- just turn yourself into a commit rockstar!

HR departments many times hardly read the CV before the interview, let alone spending time on Github repos.

Additionally many people cannot make their work public anyway.

I had an interview where I had linked my SO and my GitHub. The latter just because it wasn’t completely empty.

He cheekily complained that I didn’t have much activity.

Others are saying they experience this, but couldn’t that be solved by using one of the many projects that completely spoof the history?

I mean there are folks with histories which would make you greeen with envy, but you can have the same history with ~0 effort, making it immaterial.

I used one of those in the past and it was a great subject of interest in my interviews.

They thought I hacked Github or something. Good time :)

Did you just fill the entire thing, or did you display scrolling ascii art?

Woth crons in github actions I’ve been thinking you could create an entire movie, especially with a random generator à la Progress Quest.

I used to use it to make sure I made progress on projects my aim was I would do something everyday. Some days I did very little other days I did alot. I stopped caring about that approach. I got a bunch of stuff done but really I ended up making one line changes just so I kept my streak and I technically did something.

Same, except I found that even the one-line changes just to have committed something were useful for keeping me in touch with whatever project I was choosing to work on. It also gave me extra motivation to fix relatively trivial problems that would otherwise annoy me a little but not enough to otherwise justify the effort to `cd $project_dir && git pull && nano $relevant_file && make test $$ git commit`. A lot of unit tests and documentation improvements got written this way, a few minutes per day.

>I have never paid any attention to that at all. It surprises me that some do.

Same. I'm only now realizing some people actually do care about that, from the replies to this thread. I think it's weird. I'm not religious (or theist for that matter), but caring about these things reminds me of Matthew 6:7-8:

"But when you pray, go into your room, close the door and pray to your Father, who is unseen. Then your Father, who sees what is done in secret, will reward you."

But I can see how "gamefying" things to get improved consistency and thus better results can be beneficial to some. Not for me, sadly.

I occasionally look at my green squares for fun. Stars and popular repositories are a better metric of someone's activity on GitHub. But all of this can be easily gamed.

Me neither, the quality of the stuff there isn't anything extraordinary.

Most value I produce is commercial and under NDA.

My private time is for family and friends, not coding.

> As a GitHub user, I was always seeking green squares to try to make sure I had activity every day. This led me to change my workflow to generate more green squares, not for whatever is maximally effective. Having visible stars and followers also turns it into a sort of popularity contest. There's a dopamine hit when you get one of those, so it creates a strong reward function for attention-seeking behavior.

> Another big reason is that Sourcehut is explicitly designed to not dispense dopamine. My brain's response to dopamine is widely exploited by our industry, which is why I'm not on any social media anymore. GitHub dispenses a lot of dopamine and it makes me change how I work to get those nice little green squares. Sourcehut rejects features that are only for dopamine hits without utility on their own, and is generally designed in a humane way that doesn't exploit human psychology. This makes my life tangibly better.

This is enough to get me to switch as well. I did not know about Sourcehut but I will be checking them out today.

For OSS, Codeberg is also an option. It's based on Forgejo (a fork of Gitea) so it's much more traditional a forge in terms of contribution models than Sourcehut's email first model which can be off-putting for many.

Thank you for the recommendation, my friend. I will check out Codeberg as well.

> GitHub dispenses a lot of dopamine and it makes me change how I work to get those nice little green squares.

Yerwhat? This is not remotely my experience with GitHub at all. I never look at my green squares. In fact I rarely even look at anyone's profile page (why would I?)

I use GitHub every day and it has never once occurred to me that anyone could think of GitHub as addictive/gamified or a "dopamine dispenser".

If the green squares were sufficient to give me a dopamine hit, my half-abandoned repos with stars, pull requests, and conversations would be a much higher priority in my life.

As it stands, responding to user requests on Github just feels exactly like work.

Yeah, if Github squares are affecting your health, a better policy is self-control. Otherwise your next issue might be unit tests displaying green checkmarks and repos showing coverage percentages.

I use GitHub, but only as a mirror for the repositories I have on infrastructure under my own control. It's still very easy for others to contribute, even to send pull requests via GitHub, while I merge them locally and push them to my primary and mirror repositories. GitHub detects that PRs are merged, even if you do not use their UI, which is very nice.

Note that you can do this for more online services; you can have GitHub, GitLab, SourceHut and other sites all as mirrors for your self-hosted repositories. It's the best of all worlds in my opinion, and enlarges your pool of potential contributors.

Of course, you have to avoid vendor lock-in that can happen if you rely too much on other services that GitHub provides, like the issue tracker, wiki, CI and so on.

Which side do you use as the primary? I use Gitea and push mirror to GitHub, but I’m not sure how that would work for collaboration. I only push to GitHub for projects that deploy to Cloudflare (via Pages).

I’ve stubbornly struggled through self hosting all my stuff while everyone was saying it was a waste of time. There was a stretch where I was starting to believe it, but now I’m starting to feel more vindicated. It’s different for large companies, but I think smaller developers benefit from the control you get from self hosting everything possible.

I use my own git servers as primary. Just a webserver serving the git directory read-only, and I push via SSH to it. You can slap a UI on top, from something simple like gitweb to whatever you want.

I accept that we all need to move off GitHub generally, I just haven't taken my projects off. (Because of microsoft ownership and general effects of being the hegemonic service, it will only serve its users' interests less and less.)

The network effect is pretty great, so that makes github a good place where lots of stuff is happening for hobby and open source projects.

On the ChatGPT / Copilot angle of this story: I have unique code on github that solves a problem I have never seen solved anywhere else. I have searched extensively for other implementations and have not found any. As far as I can determine mine is the only one out there, at least on the searchable internet.

I asked ChatGPT to write code to solve the same problem.

Guess what happened. If you think you know the answer, welcome to the smug feeling of confirmation bias.

ChatGPT created entirely novel code that solved the problem. I have to say I was impressed.

It’s just an anecdote, but to me it made an impression. I think the worries are overblown.

Mind to share the problem?

Sourcehut may have advantages but I just can't get past the design. I need some fun in my products and this feels like an abandoned village.

This is a bad reason to not use it I admit

I can’t get over the PR handling with git send-email.

I know, it’s “how git is supposed to be used” or whatever, but it makes it just worse.

I can’t decide if it’s worse or better than gerrit though. Every time I need to use gerrit for some google stuff, I want to punch my screen.

There are even a few regular contributors on the Git project who complain about the workflow being `git send-email`/email centered.

You need git-review[1] to make Gerrit usage sane...

[1] https://opendev.org/opendev/git-review

God man, Gerrit, I haven't heard that name in a looong time.

You don’t contribute to Google projects then.

The design is one of my favorite things about sourcehut. It's clean, to the point, and doesn't get in the way. (Of course, taste is subjective, so this is just me offering a different view, not saying you're "wrong".)

I agree, there is nothing "wrong" with it. It's just not for me.

I had a similar thought as OP, except I didnt just "move" the repos and delete on github.

Instead, the github mirrors now contain informative readmes with a helpful link to the sourcehut repos.

Why? Because unfortunately github is still considered as some sort of industry standard, and this is important for discoverability, voting/favouriting (stars) etc. It also allows someone to star the project on github to show their support.

The point about CI is super strong; GitHub Actions almost made me quit being a programmer and I've been doing things professionally ever since Winter 2001.

I don't think much of Drew DeVault -- whether I agree with him or not is not at all relevant to any decision of using his products IMO -- but I'll vote with all three hands for a better and more seamless CI!

I was not aware of that aspect of SourceHut so now I'll seriously consider it.

What's so bad about GitHub actions? Asking as someone who never used it (gitlab fulfills my needs).

Imagine a programming language with the YAML syntax. You get modern CI/CD.

Though, Gitlab CI is less powerful than Github Actions. With Gitlab CI, you can only have one pipeline per repository, and you have to play with conditional includes based on some CI variable to implement multiple pipelines.

While with Github Actions, you can simply have multiple workflows, listening to different kind of events (webhook, issues/pull requests events, ...)

I moved my personal projects to Gitlab. Philosophical issues aside, it’s a great product.

Also, having borderline burnout maintaining popular open source projects on GitHub, there is refreshingly near zero issues filed on my Gitlab projects.

Fewer people already have accounts on Gitlab, creating a small barrier to participation, and sometimes that’s a good thing.

What philosophical issues do you have with Gitlab?

Sorry, I referring to the objections that people have raised with GitHub, not Gitlab.

I recently switched jobs to a company that uses GitLab after a long time of using GitHub and I really don't like it.

It could just be my lack of familiarity, but it feels less polished and more clunky.

Both work similarly enough it doesn't really matter that much to me.

My previous job used GitLab. I agree that it's less polished and more clunky, at least for the overlap of features it shares with GitHub. (Mostly code hosting and collaboration m.)

I think where it shines is as a DevOps platform. I'm not sure I would say any of the features are best in class but there is value in centralizing them in one place. It takes a lot of investment to get that value though.

I'll be honest, having lots of stuff in github is convenient for looking for projects. Like, I need something that does X, and search engines offer the same results for pages and pages. Searching github directly is a lot easier.

Is there a way to search multiple public repos at once? Github, gitlab, sourcehut, codeberg, etc

Does GitHub use code from private repos for AI training?

"Human Eyes will never see the contents of your private repositories"

I think that's pretty clear then.

That doesn't sound so clear. If the code is used to train AI, there's a nonzero chance that human eyes will see it. But if they're not going to use the code to train AI, then why not just say so?

AI might see it, and then AI might replicate the same code, at which point they consider it "not your code"

Oh yeah, that says it all.

Your private code is not used for any user other than you: https://docs.github.com/en/enterprise-cloud@latest/copilot/o...

Thanks, but this reference doesn't exactly answer the original question.

> Will my private code be shared with other users? > No. We follow responsible practices in accordance with our Privacy Statement to ensure that your code snippets will not be used as suggested code for other users of GitHub Copilot.

That just says they prevent snippets from being "suggested" to users of copilot, but not that snippets (from private repos) are not used to train copilot. It could also be they use private repos for training, but have some mechanism to make sure the output for the user is not too close to the original private code. Limiting the scope to "suggested code" here bypasses any information about if it's used for training or not.

Why does he keep calling GitHub a "forge"? Is calling a code repository a "forge" something common that I just haven't run across before?

It is strange to me too. I would have gone with something like "Git host" or "code hosting service".

The term "forge", when applied to something other than metalworking, still implies a place where things are made, molded, or altered. It doesn't seem fitting for a place where you store your source code and make it available for download.

I think it’s a 90’s/2000’s term (e.g. SourceForge) that is now archaic.

See https://en.m.wikipedia.org/wiki/Forge_(software): “In FOSS development communities, a forge is a web-based collaborative software platform for both developing and sharing computer applications. The term forge refers to a common prefix or suffix adopted by various platforms created after the example of SourceForge. This usage of the word stems from the metalworking forge, used for shaping metal parts.”

First time I have ever heard that. Yes, of course I know SourceForge, but never heard the term forge being used generically, like, ever.

Neither have I. Probably because almost nobody uses the term that way. It’s just Wikipedia—in other words, just something somebody made up. There’s no citation.

A forge is just a place where people go to bang out something useful or entertaining. It's not common, put the name comes up in dev contexts.

What dev contexts? Do you have a citation? I’ve been a developer for just shy of 25 years and have never heard or read “forge” used in that way.

Yes, this is a common term for a GitHub-like system: https://en.wikipedia.org/wiki/Forge_(software)

(2022)

I agree about avoiding Github. But she seems to take it for granted that one must then find an alternative “forge”. Git makes it easy to host your repositories on your own website. It’s decentralized by design. One doesn’t need a central organization or website.

Does Sourcehut still reject emails if there are both HTML and plaintext parts? Makes it tough to contribute without needing to set up a client that only sends plaintext email.

Using plaintext is one click away while composing an email in most email/web clients I have tried.

And then another click away when you want to go back to normal.

Every time you do it.

It's not a matter of clicking, it's a matter of having extra steps in an already diverging workflow.

This is probably unpopular, but I like these kinds of simple UI barriers to services I value. Also, this would certainly help with the Hacktoberfest problem.

There are plenty of other code hosting services. If you can't use Sourcehut, it's not for you.

If Sourcehut can’t interoperate with basic email, you’re right – it’s not for me.

Well. These people don't even know that a request to merge code to the trunk is called a "merge request" not a fucking "pull request"

Honestly, it's probably a better idea to keep the repo synced in multiple places, not including local/dev

If anyone is interested in building a competitor to GitHub based on mercurial, please reach out. Email in bio.

There is heptaood, https://heptapod.net/, a friendly fork of gitlab that supports mercurial. PyPy and others are using the free instance at https://foss.heptapod.net/public

Bitbucket dropped support due to to few people using it. Might be better to be agnostic about client tools?

Lack of support is exactly why a focus on mercurial is a good idea. It's a clear (and arguably superior) differentiator to all git based tools.

I fought on that hill for a while.

I dislike the new Github UI. I don't care about a timeline. I want to go directly to my repos.

I know everyone is upset about copilot. But in all honesty, copilot is awesome. I use it everyday and it takes so much pain out of my work. Theres no other tool like it, i tried them all.

That's fine, but saying this doesn't engage with the problems that have been raised at all.

It's like saying "but it's the most delicious thing I've ever eaten" in response to someone telling you a double-bacon cheeseburger with extra sauce is bad for your heart.

> a double-bacon cheeseburger with extra sauce is bad for your heart.

What about my home-made cheeseburger with real cheese (not american cheddar), a 180g steak of locally sourced beef meat, pickle, tomato, salad, onions, all fresh and locally sourced, and some tasty mustard?

Is it still bad for my heart?

Because that's what Github taste to me, I'm a sucker for having everything in one place, with such polish. The only thing I don't quite like would be Github Actions, but that's because I hate that YAML became a programming language (all modern CI/CD platforms are guilty of this monstrosity).

When a CI/CD with a Typescript API? I tried to start working on that, but it's too much for me alone.

Reply on news.ycombinator.com