Git repository name-guessing corner case

Hello,

I ran into an admittedly bizarre corner case, caused in part by my own failings, but I wanted to report it. I haven't come across anyone else having had this experience (but I suspect that I haven't properly exhausted the right combination of search terms).

I maintain a big handful of my workplace's git repo's - there is a "north" server and a "south" git server. They both run gitosis for access control. The repo's are generally setup to sync the north and south repos to each other for disaster recovery purposes.

I'll glossing over the backstory - but the process for creating repo's for new projects is partially automated, and involves some manual steps.

On the north machine, I created the repo wizard.git, with the mirroring configured to south:wizard.git

On the south machine, I first accidentally created the repo wizard.git.git (note the double .git), with the mirroring configured by default to north:android.git (I'll gloss over the back story here - but basically, the template used for repo setup used a working config file from the android project - and the real repo name was left in the template).

On the south machine, I then created the repo wizard.git with the mirror configured to north:wizard.git

As you might guess, there was already a north:android.git and south:android.git repo's configured.

So the corner case (or perhaps just a "gotcha") that occured is this: when my developer pushed their new code into the north:wizard.git repo, the hook to replicate the repo fired, mirroring to south:wizard.git -- however, instead of operating on the wizard.git bare repo, the mirroring was done to the wizard.git.git repo. The hook that subsequently fired mirrored to north:android.git and, in turn, a mirroring was done to south:android.git.

Because the android.git bare repo was recently set to allow deletes of branches and tags for housekeeping reasons, this allowed the push to the north:wizard.git repo to chain to the android.git repo's, deleting all branches in that project.

I'm guessing this must be the result of the git repo name guessing code trying a repo name with a .git attached first. Admittedly, this problem was caused by my dumb actions (template config file pointing to a real repo; not removing the wrong bare repo as soon as I created it) -- but I suspect that this is an undesired behavior. (BTW, no permanent damage was done in my case - I was able to replicate a relatively recent clone back into the master servers.)

Thanks for reading this. Joseph

-- View this message in context: http://git.661346.n2.nabble.com/Git-repository-name-guessing-corner-case-tp7561236.html Sent from the git mailing list archive at Nabble.com.

Joseph Chiu <joechiu@joechiu.com> writes:

We have updated the logic around this area with b3256eb (standardize and improve lookup rules for external local repos, 2012-02-02), and this is part of v1.7.9.2 and later releases. The rule used to be (1) check with "/.git" appended, to cover the case where you access a repository with a working tree attached, (2) check with ".git" appended, and then (3) check without anything appended. It was very error prone to cause exactly the above kind of gotchas.

The updated rule checks with "/.git" first andthe next possibility that is checked is the given name without modification, so if you have both wizard.git and wizard.git.git (with or without working tree):

        accessing with this name ... will find this repository
        wizard                       wizard.git
        wizard.git                   wizard.git
        wizard.git.git               wizard.git.git

which should be much saner.