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

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

[Horst H. von Brand]

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

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

[Junio C Hamano]

"Horst H. von Brand" <vonbrand@inf.utfsm.cl> writes:

> 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

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

[Junio C Hamano]

"Horst H. von Brand" <vonbrand@inf.utfsm.cl> writes:

> 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.

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

[Horst H. von Brand]

Junio C Hamano <junkio@cox.net> wrote:
> "Horst H. von Brand" <vonbrand@inf.utfsm.cl> writes:
> 
> > 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)?

Because I just noticed :-(

> Now, seriously.

[...]

> You said "I tried".  Is this something you do in real life?

There was a discussion going on about importing several tarballs (one
version after the other) into git. If you want to just export the result,
not futz around in it, it leads naturally to doing something like:

  mkdir /base/test.git
  cd /base/test.git; git --bare init
  for v in 0.8.0.99 0.99a 0.99b 1.0 1.1 1.2.0 1.2.1 1.2.2; do
    cd /work
    tar zxf test-$v.tar.gz
    cd test-$v
    git --git-dir=/base/test.git add .
    git --git-dir=/base/test.git commit -a "Version $v"
    git --git-dir=/base/test.git tag v$v
    cd /work
    rm -rf test-$v
  done

> 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.

It grates me somewhat that there isn't a clean way of saying "My .git stuff
is over there". No big deal, really.

And it is not a "depends", AFAICS: GIT_DIR says where to stash stuff, users
had better know what they are doing in that case... so perhaps allow
anything if GIT_DIR is set?

> 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).

For this particular case this is no real help.

But no big deal to me. Still trying to wrap my brain aound git, that's all.
-- 
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

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

[Junio C Hamano]

"Horst H. von Brand" <vonbrand@inf.utfsm.cl> writes:

> Junio C Hamano <junkio@cox.net> wrote:
> ...
>> 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.
>
> It grates me somewhat that there isn't a clean way of saying "My .git stuff
> is over there". No big deal, really.
>
> And it is not a "depends", AFAICS: GIT_DIR says where to stash stuff, users
> had better know what they are doing in that case... so perhaps allow
> anything if GIT_DIR is set?

One problem I have with that is that doing so would make it
harder to prevent pushing into the current branch of a
repository with working tree from happening later.

In the "sequence of tarballs" example, I wonder why you cannot
do something like:

	git init-db
	for tarball
        do
        	tar xf $tarball
                # if it extracts in a wrong directory, move them
                # up first ...
                git add .
                git commit -a
		git rm -r .
	done