git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Junio C Hamano <junkio@cox.net>
Date
Jan 12, 2007, 17:56 UTC
Message-ID
<7vzm8ot9gf.fsf@assigned-by-dhcp.cox.net>
In-Reply-To
<200701121545.l0CFjMC1017088@laptop13.inf.utfsm.cl>
"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.
Previous: Junio C Hamano
Message 3 of 3 in “1.5.0.rc1.g4494: Can't use a bare GIT_DIR to add”
  1. Horst H. von BrandJan 12, 2007
  2. Junio C HamanoJan 12, 2007
  3. Junio C HamanoJan 12, 2007

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.