Re: [PATCH] Solve git-submodule issues with detached work trees

From: Jens Lehmann <jens.lehmann@web.de>
Date: Jul 23, 2012, 20:02 UTC
Message-ID: <500DADEE.9060700@web.de>
In-Reply-To: <7v7gtumj88.fsf@alter.siamese.dyndns.org>

Am 23.07.2012 20:21, schrieb Junio C Hamano:

Show 42 quoted lines

> Jens Lehmann <Jens.Lehmann@web.de> writes:
> 
>> Am 23.07.2012 07:09, schrieb Junio C Hamano:
>>> Daniel Graña <dangra@gmail.com> writes:
>>>
>>>> A common way to track dotfiles with git is using GIT_DIR and
>>>> GIT_WORK_TREE to move repository out of ~/.git with something like:
>>>>
>>>>     git init --bare ~/.dotfiles
>>>>     alias dotfiles="GIT_DIR=~/.dotfiles GIT_WORK_TREE=~ git"
>>>>
>>>>     dotfiles add ~/.bashrc
>>>>     dotfiles commit -a -m "add my bashrc"
>>>>     ...
>>>>
>>>> but git-submodule complains when trying to add submodules:
>>>>
>>>>     dotfiles submodule add http://path.to/submodule
>>>>     fatal: working tree '/home/user' already exists.
>>>>
>>>>     git --git-dir ~/.dotfiles submodule add http://path.to/submodule
>>>>     fatal: /usr/lib/git-core/git-submodule cannot be used without a
>>>> working tree.
>>>>
>>>> Signed-off-by: Daniel Graña <dangra@gmail.com>
>>>> ---
>>>
>>> I think this is in line with what we discussed earlier on list when
>>> the interaction between GIT_DIR/GIT_WORK_TREE and submodules came up
>>> the last time.  Jens?
>>
>> Yes, I think this is the only way submodules in current git can
>> be used with the GIT_DIR and GIT_WORK_TREE environment variables:
>> set them when adding or initializing the submodule and always use
>> the same settings when accessing them later. Daniel's dotfile
>> alias achieves exactly that, so his fix looks good. But I agree
>> the tests should be improved as you already pointed out.
> 
> Thanks for a quick review.  The "the only way ... in current git can
> be used" part makes it sound as if it is a somewhat suboptimal ugly
> workaround, but if that is what you meant, what is a more optimal
> and less ugly way that you have in mind?

I don't see it as an ugly workaround, I just don't see a way to get the flexibility GIT_DIR and GIT_WORK_TREE offer for repos without submodules (e.g. put the work tree temporarily somewhere else for deployment or compare the current work tree with the history in a different git directory) without changing core git. I have no idea how many people use this flexibility but when submodules are involved, you have to stick to the choices you made in the first place or things will break. Right now the two relative links tie exactly two directories together as git dir and work tree. I suspect e.g. some setups using symlinks could benefit if we could get rid of one of them or even both.

We could get rid of the core.worktree setting by assuming that the directory a gitfile was found in is the root of the repo's work tree (unless configured otherwise). And we could introduce a new gitfile notation which gives the git dir relative to a parent repo's git dir (e.g. "parent: modules/name" or such). But I'm not sure if it is worth the hassle.

Show 6 quoted lines

> If you want to move .git out of way with GIT_DIR and if you want to
> sit somewhere different from the top of your working tree, you must
> use GIT_WORK_TREE (or core.worktree) to tell where the top resides,
> whether your project use submodules or not, so I do not think it is
> an ugly workaround but is the one true way to use such a dismembered
> layout, I would think.

That is a perfect use case and we should make it work.