Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I’m disappointed that this headline will lead to more clicks. This is your reminder that in git the branch name is just a pointer to a commit. Renaming that pointer is relatively seamless on GitHub (https://github.com/github/renaming?tab=readme-ov-file#rename...). Also, git 3.0 isn’t forcing this change on existing repos, just new ones that no automation depends on. And if you really like the old name that’s always an option for your repos. Remember, it’s just a pointer.

The other git 3.0 changes are more consequential and worthy of discussion - changing from SHA-1 to SHA-256 for greater security and performance, changing the storage format for performance and introducing Rust.



> changing from SHA-1 to SHA-256 for greater security

Linus has a different view, he referred to the SHA-256 migration as "pointless churn": https://www.youtube.com/watch?v=sCr_gb8rdEI?t=11m

SHA-1 is not broken enough to be a serious issue for git. The migration to SHA-256 has been forced by on git by clueless morons, and it is, in this very special way, similar to the master-main rename.


Will Git produce repos with both SHA1 and SHA256 commits, or is this a per repo thing?


AFAIR, git is now kind of hash function agnostic, although SHA-256 is the only one there in practice.


How does Git know which hash type a given hash is? Is there a prefix, that is just never shown?


Also wonders if SHA-384 or SHA-256 would be more "future proofing" or whatever the points the supporters making


Only if you don't have any pdf files in your repo.


> just new ones that no automation depends on

Except for automations that happen to create new repositories.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: