Is it possible to add/commit a file to the index of a local bare Git repo?

I'm messing around with the Ruby Git gem... seeing how I can use it to manage/access a Gitosis server I'm running. Does anyone know if it is possible to add/commit files to a local bare repo, or will I need to set up a loc开发者_如何转开发al 'normal' repo and use SSH to push it to the bare repo on the localhost?

---

You should be able to do this using low level plumbing commands:

$ generate_contents | git hash-object -t blob -w --stdin
$ git update-index --cacheinfo 100644 sha1 path

• sha1 is result of previous command.
• 100644: means an ordinary file.

But bare repositories are meant to be used only to push into or fetch from. Bare repository doesn't need to have index at all!

---

You need a working tree to add a file to the index and commit it.
While it might be possible to change directly the internal content of a bare git repo through plumbing commands, I would really recommend setting up a normal clone, modify it and push the resulting commit back to the bare repo.

---

Since git update-index --add --cachinfo is important to add a file to the index, note that cacheinfo has a new syntax:

--cacheinfo <mode>,<object>,<path>
--cacheinfo <mode> <object> <path>

Directly insert the specified info into the index.
For backward compatibility, you can also give these three arguments as three separate parameters, but new users are encouraged to use a single-parameter form.

See commit ec160ae by Junio C Hamano (gitster), March 2014, part of Git 2.0+:

update-index: teach --cacheinfo a new syntax "mode,sha1,path"

The "--cacheinfo" option is unusual in that it takes three option parameters.
An option with an optional parameter is bad enough.
An option with multiple parameters is simply insane.

Introduce a new syntax that takes these three things concatenated together with a comma, which makes the command line syntax more uniform across subcommands, while retaining the traditional syntax for backward compatiblity.

---

Note: only git 2.0.X/2.1 (Q3 2014) takes care of the NULL case:
See commit c8e1ee4 by Jeff King (peff):

Running "git update-index --cacheinfo" without any further arguments results in a segfault rather than an error message. Commit ec160ae (update-index: teach --cacheinfo a new syntax "mode,sha1,path", 2014-03-23) added code to examine the format of the argument, but forgot to handle the NULL case.

Returning an error from the parser is enough, since we then treat it as an old-style "--cacheinfo <mode> <sha1> <path>", and complain that we have less than 3 arguments to read.