threads / discuss / 6357

1.5.0.rc1.g4494: Can't use a bare GIT_DIR to add

Subject: 1.5.0.rc1.g4494: Can't use a bare GIT_DIR to add

## tl;dr

3 messages between Jan 12, 2007 and Jan 12, 2007.

replies: 2people: 2as markdown or json

Horst H. von Brand· Jan 12, 2007, 15:45 UTC · lore
I tried this:
  
  mkdir xyz
  cd xyz
  git --git-dir=../xyz.git   
     # Initialized empty Git repository in ../xyz.git/
  echo Junk > file-a
  git --git-dir=../xyz.git add .
     # fatal: add cannot be used in a bare git directory

I expected that "GIT_DIR is bare, over there, stuff is here" works the same as "GIT_DIR is .git, right here among stuff".

-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria             +56 32 2654239
Casilla 110-V, Valparaiso, Chile               Fax:  +56 32 2797513
Junio C Hamano· Jan 12, 2007, 17:33 UTC · re: Horst H. von Brand · lore

Re: 1.5.0.rc1.g4494: Can't use a bare GIT_DIR to add

"Horst H. von Brand" <vonbrand@inf.utfsm.cl> writes:
Show 17 quoted lines
> I tried this:
>   
>   mkdir xyz
>   cd xyz
>   git --git-dir=../xyz.git   
>      # Initialized empty Git repository in ../xyz.git/
>   echo Junk > file-a
>   git --git-dir=../xyz.git add .
>      # fatal: add cannot be used in a bare git directory
>
> I expected that "GIT_DIR is bare, over there, stuff is here" works the same
> as "GIT_DIR is .git, right here among stuff".
> -- 
> Dr. Horst H. von Brand                   User #22616 counter.li.org
> Departamento de Informatica                    Fono: +56 32 2654431
> Universidad Tecnica Federico Santa Maria             +56 32 2654239
> Casilla 110-V, Valparaiso, Chile               Fax:  +56 32 2797513
Junio C Hamano· Jan 12, 2007, 17:56 UTC · re: Horst H. von Brand · lore

Re: 1.5.0.rc1.g4494: Can't use a bare GIT_DIR to add

"Horst H. von Brand" <vonbrand@inf.utfsm.cl> writes:
Show 12 quoted lines
> I tried this:
>   
>   mkdir xyz
>   cd xyz
>   git --git-dir=../xyz.git   
>      # Initialized empty Git repository in ../xyz.git/
>   echo Junk > file-a
>   git --git-dir=../xyz.git add .
>      # fatal: add cannot be used in a bare git directory
>
> I expected that "GIT_DIR is bare, over there, stuff is here" works the same
> as "GIT_DIR is .git, right here among stuff".

Sheesh, why didn't you speak out earlier while the discussion was on (I am not serious, git mailing list is still moving too fast for people to be always on top of)?

Now, seriously.

The "bare" topic introduced "is this repository bare?" check, which can say only "yes" or "no" for any given GIT_DIR. A heuristic is there but can be overriden with "core.bare" configuration. We allow certain things we usually do not allow in a repository without working tree (e.g. updating the branch pointed at with HEAD via "git-fetch"), and we forbid things that require a working tree in a bare repository (e.g. "git-checkout").

This "your bare repository is my repository with worktree elsewhere" was not something we considered during the "bare" discussion. If we wanted to allow that, the check needs to say "yes", "no", or "depends", and we need to allow both kinds of operations in a repository marked as the third kind.

You said "I tried". Is this something you do in real life? This _is_ a regression, as we are checking something we did not check before and refusing to work in cases where we did. But I am not sure if reverting to lift the safety (for that matter, introducing the third "depends" alternative) is better than the latest behaviour.

For one thing, you could (sometime before the "git add ." and do this only once) do:

	$ ln -s ../xyz.git .git

and that would make all the future git operation work without the --git-dir parameter (or GIT_DIR environment) in xyz directory. An added benefit is that it would even allow git command to work from a subdirectory of xyz (specifying GIT_DIR or --git-dir means you are bypassing the discovery for the top of the working tree, so you have to always be at the top).

Hmmmm.

← back to recent threads