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