main branches locally

Posted Oct 24, 2025 10:00 UTC (Fri) by gioele (subscriber, #61675)
In reply to: main branches locally by mathstuf
Parent article: Git considers SHA-256, Rust, LLMs, and more

> > 1) correctly setting the remote from which branches should be pushed and pulled (`main` should be merged ff-only from $UPSTREAM-REPO, but pushed to $MYFORK-REPO-ON-A-FORGE),
>
> If upstream ever rewrites history, the `ff-only` can leave you stranded. I prefer to just always trust what the remote repo is.

Agreed. What I meant was "ff-only" by default. If a pull cannot be fast-forwarded then I definitely want to know about it. I will mostly likely pass some option that says "it's OK, overwrite the branch instead of merging it", but I want to be in control of that.

> > 3) prevent direct pushes to $UPSTREAM-REPO (I may have admin access to that repo, but our workflow is PR-based),
> > 4) block commits to the `main` branch (all development should happen in feature branches).
>
> Branch protection rules (i.e., server-side git hooks) should handle these situations. There's nothing to be done on the developer's side for these as I want the server to enforce them.

As an admin I should have the ability to push whatever I want (or need) to any branch. But that's a big gun pointing at my foot, so I'd like my local tools to not allowing me to do that by default and then shout loudly when I ask them to do it nevertheless. Server-side hooks can be used to implements something similar, but IMO they should be used to solve problems like enforcing policy and access control, rather than as preventive measures for common mistakes.

to post comments

main branches locally

Posted Oct 24, 2025 13:33 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

> As an admin I should have the ability to push whatever I want (or need) to any branch. But that's a big gun pointing at my foot, so I'd like my local tools to not allowing me to do that by default and then shout loudly when I ask them to do it nevertheless. Server-side hooks can be used to implements something similar, but IMO they should be used to solve problems like enforcing policy and access control, rather than as preventive measures for common mistakes.

Sure, the *ability* makes sense, but I'd rather have to go back to the forge, open the gate, do the action, then close the gate again. Having admin privileges just "laying around" is not a good idea (as you need to keep this in mind when onboarding new co-admins) and as an additional layer of defense in case your machine/key becomes compromised (not limited to rogue LLM-based agents "trying to help" or trying to cover their own mistakes).

I also can't say I've seen "common" mistakes which require rights to rewrite history (e.g., any token leak is not a reason as once it is leaked, it needs rotated anyways, so there's no reason to scrub it from history either). I acknowledge they can exist…but I'd also rather continue doing the "gate" thing to help try and train those making the mistakes to, maybe, not do that?