Re: contrib/workdir/git-new-workdir broken in 1.7.10 after introducing gitfiles

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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]

Add to Google