main branches locally

Posted Oct 24, 2025 1:44 UTC (Fri) by mathstuf (subscriber, #69389)
In reply to: main branches locally by gioele
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. Granted, actual rewriting should be for *extreme* cases (e.g., legal in nature or catastrophic like "oops, committed my VM disk"), but I see no reason to force ff-only here.

> 2) ignore all branches of $UPSTREAM-REPO not pointed by HEAD (so, only fetch `main`),

Some projects have support branches (`release` or the like). I also like to have these. It's the main reason I prefer upstream repos to only publish their maintained branches.

> 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.

> I know that there are plenty of situations in which this kind of arrangement would not work, but it would cover the vast majority (95%+) of the projects and repos I deal with.

Yes, but when you bake in policy, all those corner cases become much sharper. Personally, I have a `git gh-add-fork` command that adds a fork on github to a repo I have with a structured name (`gh/$handle`) and, if it is my handle, sets it as the `remote.pushdefault` as well.

to post comments

main branches locally

Posted Oct 24, 2025 10:00 UTC (Fri) by gioele (subscriber, #61675) [Link] (1 responses)

> > 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.

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?