On 04/22/2012 12:41 AM, Junio C Hamano wrote:
Junio C Hamano<gitster@xxxxxxxxx> writes:As you analyzed correctly, core.worktree lets a GIT_DIR to declare that there is a single working tree associated with it. It fundamentally is incompatible with new-workdir, which is a hack to let more than one working tree associated with a single GIT_DIR. I however do not think a simplistic "unset core.worktree" is a good suggestion, though, as we do not know why the original repository has that variable set pointing at somewhere. Blindly removing it will break the use of the original repository. If somebody _really_ wants to use new-workdir for whatever reason in such a setting, I would imagine that doing something like this: ... may work.I am too lazy to try it out myself, but a hack something along the line of the attached patch _might_ turn out to work well. At least, it gives an incentive to people to update to more recent versions of git ;-) I dunno. -- >8 -- Subject: new-workdir: use its own config file Instead of letting a new workdir share the same config, we simply include the original config and override core.worktree in it. This obviously changes the behaviour from the traditional workdir, by making any update to the config in a workdir private to that workdir and not reflected back to the original repository. Because a workdir is supposed to be just a peek only window to check out a branch that is different from the main working tree, and you are not expected to modify the config file in any way (e.g. you do not create a new branch with remote configuration in a workdir), it may not be a huge issue.
This change will break my use of new-workdir, which is maintaining multiple checked out branches in separate directories, some with embedded modules, and being able to share changes and remote branches between them. These directories are time-consuming to set up, so the usually suggested approach of "git-checkout $other_branch" is not very useful. All of the workdirs are set up off of a common set of bare repos kept elsewhere.
There are other ways to share between multiple independent repositories on the same machine, but new-workdir is the simplest as there is no push / pull / patch / am involved.
I think the "peek-only" use case is better supported by clone, which on a local machine does not copy the object store, and is of course well-documented and in core-git. Perhaps a better patch is to just suggest "clone" to the user who has core.worktree and/or submodules in use?
Mark -- 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
[Newbies FAQ] [Linux Kernel Development] [Free Online Dating] [Gcc Help] [IETF Annouce] [DCCP] [Netdev] [Networking] [Security] [V4L] [Bugtraq] [Free Online Dating] [Photo] [Yosemite] [MIPS Linux] [ARM Linux] [Linux Security] [Linux RAID] [Linux SCSI] [Fedora Users] [Linux Resources]