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

["Shawn O. Pearce" <spearce@spearce.org>]

Junio C Hamano <gitster@pobox.com> wrote:
> "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?

Yes.  I tested it in this use case.  It works with the patch, it
fails rather nicely without.  Fun errors about not being able to
cp HEAD from a directory that shouldn't have a HEAD...

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

True, but it works, and uh, we have this new fangled --work-tree
thing to go along with --git-dir, so why can't I symlink my entire
.git content over to somewhere else and pretend like the mess that
is --work-tree doesn't exist?
 
> 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.

Indeed.  I have a driver script that sets up my bare repos, it
removes core.bare from their configs.  So if you go into the bare
repo our auto-sensing bare thing gets activated and says "Hmm, it
ends in .git but isn't exactly .git so its bare!" (correct answer).
If you cd into a workdir created by git-new-workdir the auto-sensing
bare thing gets activated and says "Hmm, it is exactly .git so its
not-bare!" (correct answer).

So removing that core.bare thing makes the magic work.  But if you
leave core.bare in foo.git/config, yes, a workdir created from it
is mighty confused.

-- 
Shawn.