Can gitolite support v1 format features (e.g. sha256) for new repos?

[Michael Bryant]

As the subject asks. I am attempting to set up Gitolite for personal use, and I want to have newer Git features enabled. I have added the following to gitolite.conf:

repo @all

    config core.repositoryFormatVersion = 1

    config extensions.objectFormat = sha256

    config extensions.compatObjectFormat = sha1

    config init.defaultBranch = main

    config init.defaultObjectFormat = sha256

repo gitolite-admin

    RW+     =   shadow53

    config core.repositoryFormatVersion = 0

    config extensions.objectFormat = ""

    config extensions.compatObjectFormat = ""

repo u/CREATOR/..*

    C       = @all

    RW+     = CREATOR

    RW      = WRITERS

    R       = READERS

If I attempt to create a repo by cloning, I get the following output:

$ git clone g...@git.shadow53.dev:u/shadow53/test.git

Cloning into 'test'...

hint: Using 'master' as the name for the initial branch. This default branch name

hint: is subject to change. To configure the initial branch name to use in all

hint: of your new repositories, which will suppress this warning, call:

hint:

hint:   git config --global init.defaultBranch <name>

hint:

hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and

hint: 'development'. The just-created branch can be renamed via this command:

hint:

hint:   git branch -m <name>

hint:

hint: Disable this message with "git config set advice.defaultBranchName false"

Initialized empty Git repository in /usr/local/git/repositories/u/shadow53/test.git/

warning: repo version is 0, but v1-only extension found:

       compatobjectformat

BUG: repository.c:193: hash_algo and compat_hash_algo match

BUG: repository.c:193: hash_algo and compat_hash_algo match

BUG: repository.c:193: hash_algo and compat_hash_algo match

error: git-shell died of signal 6

fatal: Could not read from remote repository.

Please make sure you have the correct access rights

and the repository exists.

I get a similar error if I try to create the repository by pushing a local repo:

hint: Using 'master' as the name for the initial branch. This default branch name

hint: is subject to change. To configure the initial branch name to use in all

hint: of your new repositories, which will suppress this warning, call:

hint:

hint:   git config --global init.defaultBranch <name>

hint:

hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and

hint: 'development'. The just-created branch can be renamed via this command:

hint:

hint:   git branch -m <name>

hint:

hint: Disable this message with "git config set advice.defaultBranchName false"

Initialized empty Git repository in /usr/local/git/repositories/u/shadow53/notes.git/

Enumerating objects: 34, done.

Counting objects: 100% (34/34), done.

Delta compression using up to 16 threads

Compressing objects: 100% (31/31), done.

Writing objects: 100% (34/34), 155.18 KiB | 17.24 MiB/s, done.

Total 34 (delta 1), reused 0 (delta 0), pack-reused 0 (from 0)

remote: error: unable to map tree f6ecb60cdb7c3ab2efe6fabbf9655afb2124f3eabe75cff98c930a5440ab36f7 in commit object

remote: fatal: Failed to convert object from sha256 to sha1

error: remote unpack failed: unpack-objects abnormal exit

To ssh://git.shadow53.dev/u/shadow53/notes.git

! [remote rejected] main -> main (unpacker error)

error: failed to push some refs to 'ssh://git.shadow53.dev/u/shadow53/notes.git'

In other words, it looks like the configuration is not applied until after the repository is created. So, my question boils down to: is there a supported way to set default configuration before a repo is created?

As a separate note, the repo's config file on the server seems like it has most of the config options set, but "extensions.objectFormat" is missing:

[core]

       repositoryFormatVersion = 1

       filemode = true

       bare = true

[init]

       defaultBranch = main

[extensions]

       compatObjectFormat = sha1

I'm not sure if there's logic internal to gitolite preventing it from being set, but I believe this is the cause of "BUG: repository.c:193: hash_algo and compat_hash_algo match" above. I have "GIT_CONFIG_KEYS" equal to '.*',  so I don't think my configuration is causing it to be ignored.

Thanks in advance,

Michael Bryant (Shadow53)

[Sitaram Chamarty]

Hi

I know I said in private email that I have a scheduling problem right now and I can't look at this for at least a few weeks. That hasn't changed, sadly. I'm still limited by the git version on my work laptop until I get home.

But, looking at the problem a little closer, I am not sure this has anything to do with gitolite at all.

Can you please try this with plain SSH, no gitolite.  Make that work, and then send me the details of the *git* config files on both sides (the clone on the client side and the bare repo on the server side).  That'll give me a handle on where I need to fix anything, if at all.

Thanks

[Sitaram Chamarty]

Oh and I guess the "git init" commands used as well :)

[Sitaram Chamarty]

Quick update:

If you leave out all the "compat" stuff, which I don't yet have,
i.e., if you accept that a repo is either sha256 or not, then
this doesn't really need gitolite to be changed.

See below for detailed steps:

(That doesn't mean I won't change anything, it'll happen but not
very soon. Meanwhile, this is a good way to try it out and put
gitolite through its paces in a sha256 world, and I'd like help
from people who can test. For example, I know there's at least
one part of the update hook that will need change. But by and
large it *should* work OK)

Anyway please try this and play with it and let me know what you
find.

1. set up some location (I typically use ~/local) to hold local
code and create this file there:

mkdir -p ~/local/triggers
vim ~/local/triggers/sha256
...
chmod +x ~/local/triggers/sha256

contents:

#!/bin/bash

gitolite git-config -q $2 gitolite-options.sha256 || exit 0

cd $GL_REPO_BASE/$2.git || exit 1
git config core.repositoryformatversion 1
git config extensions.objectformat sha256

2. add a new POST_CREATE trigger called "sha256":

- add this inside the ENABLE section in ~/.gitolite.rc

POST_CREATE =>
[
'sha256'
],

- uncomment the line

LOCAL_CODE => "$ENV{HOME}/local",

in the rc file (if you used a different location in the
previous step, use that here. Only the path preceding
"triggers/sha256" is needed.

3. in gitolite.conf, just add

option sha256 = 1

for any repos you want created with sha256.

That's it. Modulo the issues I mentioned before.

[Sitaram Chamarty]

Hi

I'm replying to the original email on this, because (a) there
were some errors in at least one of my earlier emails (*), and
(b) I've looked into it a lot deeper, with the latest git, and
have a "works for now" solution. Actually, I have *two* such
solutions.

Everything is laid out in
https://github.com/sitaramc/gitolite/blob/sha256-support/README-SHA256.mkd,
which I intend to be both the starting point for any discussion
on this, as well as being a living document (evolving as git's
support for sha256 evolves).

I've also pushed three **temporary** branches:

sha256-support
demo-sha256-method-1
demo-sha256-method-2

Note that these branches **will** be rebased and force-pushed
whenever I feel like it; do not use them directly in your
workflows.

sitaram

----

(*): I had said that the `POST_CREATE` section should be inside
the `ENABLE` section; it should be *outside*.

> In other words, it looks like the configuration is not applied until *after* the repository is created. So, my question boils down to: is there a supported way to set default configuration *before* a repo is created?

>
> As a separate note, the repo's config file on the server seems like it has most of the config options set, but "extensions.objectFormat" is missing:
>
> [core]
> repositoryFormatVersion = 1
> filemode = true
> bare = true
> [init]
> defaultBranch = main
> [extensions]
> compatObjectFormat = sha1
>
> I'm not sure if there's logic internal to gitolite preventing it from being set, but I believe this is the cause of "BUG: repository.c:193: hash_algo and compat_hash_algo match" above. I have "GIT_CONFIG_KEYS" equal to '.*', so I don't think my configuration is causing it to be ignored.
>
> Thanks in advance,
>
> Michael Bryant (Shadow53)
>

> --
> You received this message because you are subscribed to the Google Groups "gitolite" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to gitolite+u...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/gitolite/43e5f240-962b-4512-b3ad-1d6487230fd9%40app.fastmail.com.

[Michael Bryant]

Thanks for your attention on this. Unfortunately, I've reverted to using sha1 for now because I've got a newborn to take care of and need something that works more than I need the latest hashing algorithm. I'll keep an eye out for updates on this though and may test out sha256 once support is merged into gitolite.

Thanks,

Shadow53

[Sitaram Chamarty]

On Sun, Aug 31, 2025 at 12:43:00AM -0700, Michael Bryant wrote:
> Thanks for your attention on this. Unfortunately, I've reverted to using sha1 for now because I've got a newborn to take care of and need something that works more than I need the latest hashing algorithm. I'll keep an eye out for updates on this though and may test out sha256 once support is merged into gitolite.

Congrats on the new baby!

As for full sha256 support in gitolite, just to reiterate, it
depends on git itself resolving what I described in "Git's
readiness" section (see
https://github.com/sitaramc/gitolite/blob/sha256-support/README-SHA256.mkd#gits-readiness )

cheers
sitaram

> > > To unsubscribe from this group and stop receiving emails from it, send an email to gitolite+u...@googlegroups.com <mailto:gitolite%2Bunsu...@googlegroups.com>.