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

Junio C Hamano [off-list ref] wrote:

"Shawn O. Pearce" [off-list ref] writes:

quoted

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.