application should block adding a bare repository

Description

So when I try and create a new repository in a directory that includes a bare repository, the app recognizes that the directory includes a git repository and asks me to add it instead. So far so good until I add the repository and the app tries to perform a git operation (I don’t know which one exactly) and fails with “fatal: This operation must be run in a work tree”.

Version

• GitHub Desktop: 1.1.0

• Operating system: Windows 10

Steps to Reproduce

1. Add a bare repository.

Expected Behavior

The app rejects adding it since it does not have a working tree or offers to do a local clone.

Actual Behavior

The app adds it and fails to do a git operation repeatedly till the repo is removed.

Additional Information

So I looked at how the app decides if a path is a git directory. I understand how rev-parse --show-cdup is useful but it does not care if the repo is bare or not. I also tried to put a path into the url field of clone and the app complained that the destination already exists. I feel local clones is an enhancement that should be added as well.

[Daniel-McCarthy]

I would be interested in attempting to implement this functionality if it is not of immediate urgency.

I have already started looking into it. I have added a function that uses the git rev-parse --is-bare-repository command to detect if the repository is bare. However, the part I need some direction on is reporting the error to the user.

From what I can tell this dialog does not display errors like the Publish Repository dialog does. Should this be implemented first, or should we display the error as a pop-up of sorts?

[shiftkey]

For future reference, if we find ourselves supporting bare repositories in the app in the future:

However, I have GitX installed, and it makes bare foo.git repos into a package, so we might need to add that back in if we start supporting bare repositories.

This will affect dragging-and-dropping the bare repository onto the Desktop tray icon in macOS, see #5207 for the current implementation of this support.