"Shawn O. Pearce" [off-list ref] 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.
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.