Junio C Hamano <gitster@xxxxxxxxx> writes: > "Shawn O. Pearce" <spearce@xxxxxxxxxxx> 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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
