If at anytime, I have to go find out how to do something in git command line because SourceTree doesn't support it, it is a mark against it. The simple use case that led me here was as follows. I created a repo out of a local small directory of scripts. Then, I want to push to a shared drive for others to access. This apparently can't be done (easily) from SourceTree. When I tried this, I ended up with my local appearing like the server and my shared drive as the "copy". It seems, if I created the bare repo in the shared area first, this would work out fine. I guess I will try that.

I found a way to create a pseudo-bare repository. I create a repository using Source Tree, create an empty commit, and then detach the master branch. Source Tree does not let you create an empty commit so I resorted to terminal commands. I put the commands in a bat file and then add it to Source Tree's custom actions. The two commands are:

  commit --allow-empty -m empty 
  checkout HEAD@{0}

I'm faced with an almost identical requirement. I have a working copy but I need to share my commits through a bare repository. Without the fuss of resorting to a cloud service.

I could really use a checkbox to easily create a bare remote repository when adding a new remote repository to an existing working copy or a button to push to a to be created bare remote repository stored on a local/usb/network disk.

Why do I need it? When the computer I'm working with isn't connected to the network, I create a bare repository on a usb drive and I push/pull my changes to/from that usb drive. It's a simple and easy way of moving commits from one computer to another.

Simple projects are also easily shared using a remote bare repository on a network drive.

Currently, I use msysgit shell just to run "git init --bare /remote/repository" then I add that remote repository to SourceTree and push the working copy to that remote repository.

+1. With the use of git-subtrees instead of submodules (cf. Atlassian's Alternatives To Git Submodule: Git Subtree), there are reasons it can be advantageous to work with local bare copies of bare repositories for the shared repositories. This includes but is not limited to being able to "git subtree pull" and "git subtree push" a local copy of the shared repo even without network access – a main benefit of distributed version control.

So it is reasonable that one would want to be able to do all applicable operations on the shared bare repo (e.g. viewing current state, log information, the commit graph, seeing differences between commits, etc.). Really, any operation that could be performed on the copy of a bare repository at BitBucket is an action that one might consider doing on the local copy one can use without network access. In addition, one would like to be able to push or pull between the local copy and the remote BitBucket copy while one does have internet access.

It would be a sad regression if a distributed version control system required internet access to BitBucket in order to have viewable bare repositories to effectively support the git-subtree method of using shared repositories.

+1. I think this would be useful - I would like to open the bare repos created by stash to view branches and tags and whatnot.