What’s the point then? Why bother with hooks at all?

@JackbyDev well, it doesn't happen very frequently, it's more of a nice-to have.It's more of an issue because our product has a lot of totally separate sections, as well as a separate companion app. It's easy enough to work on an issue without ever touching code affected by another, and for whatever reason have two or three issues in progress, each in their own branch.Say, some task you're blocked on, in the meantime some minor issue from five years ago that nobody really cares about that much but would be nice, and then some other unrelated cleanup task as well.But, even when I used to work at a place where there was only one single-purpose app, I still worked in topic branches and never ever wanted to actually commit to main (through the mistake was less likely to happen, I grant).

I'm confused how this even happens. You switch to dev and then choose to keep working on your ticket, but your previous work isn't there, so how do you keep progressing? I can see this as an edge case, but it happens to you often enough that a pre commit hook is useful to stop it?

To be clear, I don't care what you do, if it works, it works, I just am having a difficult time understanding how this particular scenario happened enough that a pre commit hook was the best way to solve it.

@JackbyDev yes, friend, you too have entirely missed the point.I have my branch displayed in my shell, but mistakes happen. And a pre-commit hook that checks what branch I'm on is an excellent way to avoid those mistakes.I already have a topic branch, likely with a half a dozen odd commits in, which I intended to make my changes in. The hook avoids a mistake made on the one branch I know I pretty much never want to commit to directly.Yes, I could continue making commits to the wrong branch, and then fix my mistake later. That's noooot the point! I want to commit to the right branch in the first place. Yes, I'm going to need to rebase eventually before I push and put up a merge request - also not the point. The point of the topic branch is that all my work in progress commits are there, I can see the history of what I've tried that has and hasn't worked, and then eventually clean it up with a rebase before actual submission.All the work neds to go in the topic branch, always, and it already exists because I opened it as soon as I started work on that ticket.

Ehh each tool it's job. Wanted to agree but pre commit checks to keep secrets from entering the graph makes sense at every level for me. Anything that is too keep the git DB itself clean goes there. So if you have Conventional Commits standards precommit checks make sense. Checks for secrets. Tbh that's the furthest I've done for a precommit.

Pre push is a good place to start any orginzational checks though. Pipelines for tests and smell checks or anything fuzzy really (can normally be seen by maintainers in the merge requests). K8s (like fleet, argocd, etc) for ops checks (is this running, is the service accepting requests, etc).

husky has to be one of the most annoying and outright hostile libraries I've seen. Anytime I pull an open source project to get it working on my machine I have to go through and set up an entire development pipeline just to make a code change even if I never intend on upstreaming that change because husky forces formatting on commits. What an idiotic thing to do. The article covers this clearly. It's just not something that should be done on commit.

git switch -c blah
git push -u origin blah
git switch main
git reset --hard origin/main

There are ways to skip the hooks.

Actually rebasing before pushing is the best time to do so, so a pre-push hook seems great. You can also have your branch displayed in your shell which would help avoid this.

Can you share what you use git commit hooks for?

Amen. I also need to be able to commit WIP quickly if i need to urgently checkout master, or push my code because my laptop battery is about to die and i dont want it to have the only copy of my work.

Everytine I've seen a pre-commit hook in my job, it was something that should have been in integration pipeline.

You should not run linter, test or any static analysis tool in a pre-commit (I'm looking at you husky 😡). Why ? Because:

• It takes time. A commit should be instantaneous.

• It may change the content of the commit or of the repos without explicite action of the developer.

• The developper's branch is the developper's mess. He don't have to respect any convention, any quality gate or any workflow on its branch. Quality gates should happen only when integrating into trunk.

I always commit and push on Friday afternoon before leaving as "WIP", in case my computer crash during week end. I don't want to address issues of a WIP job. I just want to backup my work.

I may commit several time per minute, and do a rebase latter. I don't want to spend 2min each time waiting for eslint to parse the repos. I don't want to fix styling because I now I will fix it later and rebase -i before pushing.

You can use custom pre-commit in your own workflow, but forcing all developer to have the same pre-commit is a bad idea.

@Vulwsztyn yeah, "there are multiple ways to fix a mistake" is not the point, dude!Besides which, yes I do have to rebase if I already have a topic branch for what I'm working on, and didn't pay attention to which branch I'm on.I almost never want to commit to the main branch, only merge from a topic branch. So that means that having confirmation before committing to it is useful.

you don't have to rebase.

create a new branch from main

push it

go to main

git reset --hard origin/main

@codeinabox I've got one to ask if I'm sure when I'm committing to anything called master or main. Helps prevent working in the wrong branch.I don't need to only catch that at the push stage and then have to rebase 🤷🏻‍♂️

It's nice to hear you didn't see a drop in engagement, that gives me hope.

I think I might do as you say and make something small to try out codeberg, see if everything works for me (dev to release).

motivation for my migration was just wanting to use services that support what i support

Very true, if it works I should just do it. It's not like I'm losing paying customers hehe.

p.s. thanks for the link, I hadn't looked it up yet :)

I didn't have "deeply rooted" projects, but i started by just creating new projects on codeberg. It gave me time to test it out before i moved the rest of my projects which i did ~6 months later.

For your use case i would consider the same. Figure out where you might like to migrate to and give it a test run with new projects. Then decide if you want to migrate the deeply rooted project(s) or not.

I didn't have to worry about the community much, both because i didn't have large projects and also because i was on gitlab to begin with. If anything going from gitlab to codeberg i had the same if not more engagement with my small projects. But my motivation for my migration was just wanting to use services that support what i support. For me that's what was most important in the long run.

Also re: github container registry. Forgejo (what codeberg uses) supports this: https://forgejo.org/docs/latest/user/packages/container/ . These images would then also show up on your project page under "packages" tab if it has been enabled

I guess I have a slightly different problem in that I use GitHub Container Registry to host release images.

I haven't looked, but I would think Codeberg might have something similar.

I would use Docker's registry, but that feels like stepping sideways instead of forwards for some reason.

Yes, you will lose some "driveby" error reports from people who don't want to make a codeberg account to report the bug on. But then they don't actually "need" need it solved either.

That's a very good point. I had thought of keeping the github repo mirrored so that it could be used for issues (and maybe prs?) still, but your point has me rethinking the need.

Make it a single source of truth, point to the new repo in the old one and update the descriptions in the distributing websites/services and that's it.

I will certainly consider this. It would definitely be easier than setting up a mirror in addition to moving.

I guess I'm worried that without an "active" side on github, the project will lose any traction it has gained since I didn't advertise it, I think github naturally brought people in.

Thank you for your reply, it is very helpful!

That's a good point, I guess I already practice this with everything else, I just waited too long for this specifically and now there's a lot of (+new) people I'd potentially be parting with.

Still going to think about this and maybe test the waters, see if it's viable.

Thank you for the response, I feel more confident in the idea!

In practice these won't be concerns. "Usually" if it's an important project, the distribution is not based around github. It's pypi for python or npm for js, or a package distributor on linux, or a store or whatever.

A weird mixed setup would be providing some kind of signed object through torrents, don't know how that works in practice, but that would avoid stressing your own internet too much.

Yes, you will lose some "driveby" error reports from people who don't want to make a codeberg account to report the bug on. But then they don't actually "need" need it solved either.

Make it a single source of truth, point to the new repo in the old one and update the descriptions in the distributing websites/services and that's it.

Maybe you just have to swap and be okay with less people around, just so you can get out of Microsoft’s grip in open source.

I think you hit the nail on the head here. It is almost always the case that you will trade adoption/utilization/community for a less-used solution. Using loops, pixelfed, mastodon or piefed/lemmy, element, linux, FOSS web apps instead of their more popular system, they all come with an unspoken agreement that you embrace a niche-existence.

Only you can really decide what's more important to you.

Epitome of software engineering

This is an awesome tool. Thanks for putting this on my radar!