Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
BREAKING CHANGE: Change the behaviour of
git_repository_is_empty
to…
… better align with expectations in a world where `master` isn't always the "initial branch" This pull request proposes a change to the definition of an "empty" repository used in `git_repository_is_empty`. At present, an empty is repository is one which: 1. has just been initialised 2. has no references apart from `HEAD` 3. has a `HEAD` pointing to the unborn `master` branch or, if specified, the unborn branch specified in the `init.defaultBranch` configuration value This changes the definition of empty, removing requirement 3. Why? Since `git_repository_is_empty` was first implemented, there has been significant cultural change in the Git community towards using an "initial branch" other than `master`. Because of this change, the current implementation of `git_repository_is_empty` considers repos to be *not empty* which an ordinary observer would consider to be empty. Specifically, this happens where a repo is initialized with `git init --initial-branch`. An ordinary observer would consider such a repo to be empty, but currently, libgit2 considers it to be non-empty if the `initial-branch` is not `master`. This is because, whilst `git_repository_is_empty` checks the `init.defaultBranch` to try to figure out the initial branch, `git init --initial-branch` doesn't set this value, as you can prove like this: ```bash git config init.defaultBranch mkdir test-repo git init --initial-branch main git config init.defaultBranch ``` I'm not necessarily expecting this PR to be merged as is or ever - but I want to start a conversation about this, given that the current implementation is surprising and likely confusing. See #6049.
- Loading branch information