Sublime Merge - SHA-256 Repos - Index Build Failure - Tracked Files Untracked

[Sn3akyP3t3]

Version info

• OS: Windows 10
• Build: 2110

Description

Sublime Merge fails to correctly parse and display repositories initialized with Git's SHA-256 object format. Committed and tracked files (e.g., .gitignore, LICENSE, README.md from an initial commit) appear as untracked in the Sublime Merge UI, despite being properly committed and shown as clean in Git CLI tools like Git Bash. Additionally, the integrated terminal in Sublime Merge shows an error: "failed to build index table". This seems related to Sublime Merge's custom Git parsing library not supporting SHA-256, as the issue does not occur with standard SHA-1 repositories.

Note: SHA-256 support in Git has been available since version 2.29 (2020) and stabilized in 2.42 (2023), with Git 3.0 potentially defaulting to it soon. As more users adopt SHA-256 for security reasons, this lack of support could become a significant limitation for Sublime Merge.

Steps to reproduce

1. Install Git for Windows (version 2.46 or later, which supports SHA-256).
2. Create a new repository with SHA-256 format: In Git Bash, run git init --object-format=sha256 test-repo and navigate into it.
3. Add and commit initial files: echo "# Test" > README.md, git add README.md, git commit -m "Initial commit".
4. Open the repository in Sublime Merge (File > Open Repository... > select the test-repo folder).
5. View the status in Sublime Merge: The README.md file shows as untracked (red icon), even though git status in Git Bash shows a clean working tree.
6. Open the Sublime Merge terminal (via the console or command palette) and run a command like git status—observe the "failed to build index table" error.

Expected behavior

Sublime Merge should correctly parse the SHA-256 repository, displaying committed files as tracked (green icon or no staging needed) and showing a clean status matching Git CLI output. No "failed to build index table" error should appear, as the tool should support modern Git formats like SHA-256 for full compatibility.

Debug Information
Omitted section. This bug is super easy and quick to recreate so I won't put effort into gathering this.

[Sn3akyP3t3]

I figured this would be relevant information when the time comes to decide prioritization of the fix.

Progression of SHA-256 Support in Git

SHA-256 support in Git has evolved gradually since its introduction, driven by the need to replace the vulnerable SHA-1 hashing algorithm (which has known collision risks since 2017). Here's a timeline and context based on Git's development history:

• Early Foundations (Pre-2020): Git was originally designed with SHA-1 deeply embedded in its core (e.g., for object IDs, commits, and trees). Discussions about migrating to a stronger hash like SHA-256 began around 2018-2019, as part of broader security improvements. The Git project selected SHA-256 over alternatives (e.g., SHA-3 or BLAKE2) due to its balance of security, performance, and widespread hardware acceleration—it's fast, collision-resistant (no known attacks), and aligns with standards like FIPS. However, the transition was complex because changing the hash breaks interoperability with existing repos and tools.

• Introduction as Experimental (Git 2.29, October 2020): SHA-256 was first added via the --object-format=sha256 flag in git init. It was marked as highly experimental, with warnings about limited tool support and potential data loss risks. This allowed creating repos with 64-character hex IDs instead of SHA-1's 40, but features like bundle/pack files were incomplete.

• Incremental Improvements (2021-2022): Subsequent releases (e.g., 2.30-2.36) added better handling for mixed-format repos, bundle v3 support (for SHA-256 packs), and reduced some warnings. However, as of mid-2022, it was still not recommended for production due to ecosystem gaps—many Git servers (like GitHub) and GUIs didn't support it, leading to isolation issues. A 2022 LWN article highlighted the slow progress, noting that while Git's CLI was solid, broader adoption lagged because recomputing history for existing repos wasn't beneficial for most users.

• Maturing Stability (Git 2.42, August 2023): A key milestone—the "experimental" warning was toned down, signaling greater confidence. Repos could now be created without scary messages, and features like git fsck fully supported SHA-256. This encouraged more testing, but caveats remained: No direct conversion between SHA-1 and SHA-256, and limited server support.

• Current State (2024-2025): As of Git 2.46 (latest stable in 2025), SHA-256 is production-ready in the CLI, with full feature parity (e.g., submodules, signed commits). However, mainstream adoption is still emerging—GitHub has it on their roadmap but doesn't support it yet (as per ongoing discussions), and tools like GitHub Desktop or SourceTree lag behind. Other forges like GitLab and Gitea allow SHA-256 repos, but interoperability is spotty. Git 3.0 (expected 2025-2026) may default to SHA-256, accelerating uptake, especially as security standards push away from SHA-1. Projects like 'got' (a Git alternative) have added support, showing momentum in niche areas. Overall, while CLI users can use it today, full ecosystem buy-in (GUIs, servers) is needed for true mainstream status—likely by 2026-2027 as Git 3.0 rolls out and major platforms catch up. This growing pressure (e.g., from enterprise security requirements) could indeed prioritize fixes in tools like Sublime Merge, as ignoring it risks alienating users migrating for better security.

[dpjohnst]

Hi there,

Thanks for sharing this feedback.

Support for SHA-256 repositories will be available in the next build.

Kind regards,
- Dylan from Sublime HQ

[dpjohnst]

G'day,

Just updating you to let you know that we've just released Sublime Merge 2115 (development build) that adds support for SHA-256 repositories.

Cheers,
Dylan from Sublime HQ