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

Am 23.07.2012 20:21, schrieb Junio C Hamano:

Jens Lehmann [off-list ref] writes:

quoted

Am 23.07.2012 07:09, schrieb Junio C Hamano:

quoted

Daniel Graña [off-list ref] writes:

quoted

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 <redacted>
---

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.

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.