Re: [PATCH] git-init: treat option `--bare'

[Luciano Rocha <luciano@eurotux.com>]

[-- Attachment #1: Type: text/plain, Size: 3358 bytes --]

On Wed, May 28, 2008 at 05:55:46PM -0700, Junio C Hamano wrote:
> Luciano Rocha <luciano@eurotux.com> writes:
> 
> > Currently, passing the `--bare' option to git-init proper doesn't work, and
> > gives no indication that `git --bare init' would work instead:
> >
> > $ git init --bare
> > usage: git-init [-q | --quiet] [--template=<template-directory>] [--shared]
> >
> > Treat the `--bare' option internally in builtin-init-db.
> >
> > Also, fix the usage string, synchronising it with the synopsis in the
> > documentation.
> >
> > Signed-off-by: Luciano Rocha <strange@nsk.pt>
> 
> It could be argued that this kind of "special casing to help common
> mistake situation" would in the long run hamper the new users in
> understanding what --bare means, because one who uses "git init --bare"
> will not realize that --bare is an option to "git" potty in general and
> can be given when invoking other git commands.  On the other hand, many
> commands do work sensibly inside a bare repository already, and "init" is
> truly special in that it cannot inspect the surroundings to guess if the
> user wants to create a bare repository or one with a work-tree because
> there isn't a repository yet.  In that sense, probably people not learning
> "git --bare" is not such a loss after all.
> 
> In general, I am not particularly fond of this kind of special casing, but
> initializing a bare repository would be a common enough operation that I
> personally think it is probably Ok to take this as an exception.
> 
> Opinions?  Breakages?
> 

Personally, my first experience with bare repositories, was when I
decided to have local mirrors of several projects. As I weren't going to
do work over then, I considered copies without a checkout.  Reading the
documentation for git-clone, I found the '--bare' option, and found that
the commands that I mattered about worked transparently (log, diff,
archive).

Much later, when trying to create a public mirror of some of my
projects, I tried to create a bare copy. However, as I didn't have
access from the remote server to my working copy, I had to push my
changes to the remote server.

But 'git init --bare' didn't work, so I resorted to:
mirror$ git init
personal$ git push mirror:copy
mirror$ git clone --bare copy public

Only some time later, in a discussion with a friend, did I learn that
'git --bare init' worked (and thus this thread was started).

In my defence, the usage displayed when running just "git" hides the
'--bare' option, as my terminals usually have 24 lines.

And the transparently way that the other commands I cared about worked
inside a bare repository eliminated any need of mine to search for a way
to specify that I was working with a bare repository to all git commands.

All in all, you are right when you say that 'this kind of "special
casing" ... would in the long run hamper the new users ... [by not
realizing ] that --bare is an option to "git" potty in general', as is
attested by my ignorance of it. But as there is a valid reason for the
'--bare' option to git-clone, there is one for git-init.

But the '--bare' option for "git" must be at least mentioned in
the documentation for those two commands.

-- 
Luciano Rocha <luciano@eurotux.com>
Eurotux Informática, S.A. <http://www.eurotux.com/>

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]