Re: [PATCH] Fix new-workdir (again) to work on bare repositories

[Junio C Hamano <gitster@pobox.com>]

Junio C Hamano <gitster@pobox.com> writes:

> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
>> My day-job workflow involves using multiple workdirs attached to a
>> bunch of bare repositories.
>
> Are you sure the patch would help?
>
> For one thing, I do not think we supported such a layout,
> officially or unofficially --- the thing is in contrib so it
> could not be official, but that is besides the point ;-).  Older
> git might have worked by accident, though.
>
> You may have made the part to create the new directory and make
> bunch of symbolic links to work with your patch, but as far as I
> know, new-workdir is designed to share the .git/config file with
> the borrowed repository, which means the configuration would say
> "core.bare = yes" for a bare repository.  So I suspect that the
> initial checkout after creating the new directory and populating
> its .git would barf, although I haven't tested it.

Having said that, I am not saying that we should forbid such a
layout that uses a work tree or more attached to a bare
repository.  We need to figure out what the best practice should
be.

 * Maybe using such a layout needs GIT_WORK_TREE environment to
   be set?

 * Maybe using such a layout needs "core.bare = false" even
   though the true repository is a bare repository?  This has an
   obvious drawback that git-fetch cannot update the branch
   pointed by HEAD even though it is a bare repository.

 * Maybe ignore "core.bare = true" if $GIT_DIR ends with
   "/.git"?  I do not like relying on names too much, though.

 * Maybe ignore "core.bare = true" if $GIT_DIR/index exists?
   This is almost right, except that there is a chicken and egg
   problem -- the index does not exist until the initial
   checkout, and checkout wants to make sure you are not in a
   bare repository.