Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • I'm looking forward to reftable to become the default. It solves many problems with branches, like branches with weird characters created with non-standard clients making a fetch impossible; case insensitive branches with "same" names doing the same; or impossible to create branch FOO because FOO/Something exists.

    All those problems just go away when branches are no longer files on disk.

    I enabled it in setup script of one large repo I maintain; the main issue is the incompatibility with some people's personal tooling based on libgit2 (some git status tooling in oh-my-zsh), but people do find workarounds.

    by jakub_g
  • It appears that BitBucket also does not currently support SHA256 hashes.

    https://jira.atlassian.com/browse/BCLOUD-23729

    by moebrowne
  • > The Git 2.45 release added reftables as a more efficient way of storing refs. It is a binary file optimized for both space efficiency and quick access. Since then, it has been possible to create a repository that uses a reftable rather than the old file-based mechanism, but that has never been the default. Switching to reftable should have no visible consequences (other than better performance) for users of Git itself, but it can be a problem for users of other software packages that access Git repositories. In his email, carlson mentioned libgit2 as a potential concern.

    Looking forward to losing all references at once vs just the current one...

    I've noticed persistent Git/fs interaction where on crash the current ref can just disappear...

    by PunchyHamster
  • It seemed obvious to me that the next version number after 2.56 would be 5.12
    by harrouet
  • > Try LWN for free for 0 month: no payment or credit card required.

    Quite a generous offer!

    </aside>

    by notpushkin
  • `git add --resolved` is a wonderful idea, and definitely something I would start using.
    by WCSTombs
  • Does it mean that when switching trop sha1 to sha256 you need to forcepush and rewrite all history? Wouldn’t that be a massive source of potential vulnerabilities?
    by KolmogorovComp
  • It's unfortunate that change IDs aren't considered. There was a discussion [1] in 2025, and it has resurfaced a couple of times since.

    Basically, the idea is to attribute a new kind of ID to an initial 'change'. During review, or whenever a commit is rebased, the change ID is kept, whereas the commit of course changes. This allows tooling to identify all previous versions of a change, and is what enables "per-commit" code review à la Gerrit [2] (which IMO is a much better experience than the branch-review-squash model that GitHub normalized). It's also used in jj, although I'm not familiar with that.

    As of today, any tool that wants a change ID needs to somehow encode it in commit message bodies. The proposed discussion was about making a change ID a standard header field that git would natively keep across rebases.

    [1] https://lore.kernel.org/git/Z_OGMb-1oV0Ex05e@pks.im/T/#mf941...

    [2] https://gerrit-review.googlesource.com/Documentation/user-ch...

    by jodersky

Explore Birbla archives