git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* git-new-workdir submodules interact poorly with core.worktree
@ 2014-09-12 13:58 Edward Z. Yang
  2014-09-13 11:25 ` Jens Lehmann
  0 siblings, 1 reply; 2+ messages in thread
From: Edward Z. Yang @ 2014-09-12 13:58 UTC (permalink / raw)
  To: git

tl;dr You can't git-new-workdir checkouts which use core.worktree.  This
is unfortunate because 'git submodule init' uses core.worktree by
default, which means you can't recursively git-new-workdir without a
hack.

In the beginning, the Developer created the remote Git repository and
the submodule.

    mkdir -p remote/sub
    (cd remote/sub && git init && touch a && git add a && git commit -m "sub init")
    mkdir remote/top
    cd remote/top
    git init
    git submodule add ../sub
    git commit -m "top init"
    cd ../..

And the Developer said, "Let there be a local clone and submodule", and
lo, there was a local clone and submodule:

    git clone remote/top top
    (cd top && git submodule init && git submodule update)

the Developer blessed the working copy, and said "Be fruitful and
increase in number with git-new-workdir":

    git-new-workdir top worktop

Unfortunately, this workdir didn't have the submodules initialized.

    $ ls worktop/sub/
    $

Now, the Developer could have run:

    $ (cd worktop && git submodule init && git submodule update)

but the resulting submodule would not have been shared with the original
submodule, in the same way that git-new-workdir shared the Git metadata.

The Developer sought to create the submodule in its own likeness, but it
did not work:

    $ rmdir worktop/sub && git-new-workdir top/sub worktop/sub
    fatal: Could not chdir to '../../../sub': No such file or directory

What was the Developer's fall from grace?  A glance at the config of
the original and new submodule shed light on the matter:

    $ cat top/sub/.git
    gitdir: ../.git/modules/sub
    $ cat top/.git/modules/sub/config
    [core]
            repositoryformatversion = 0
            filemode = true
            bare = false
            logallrefupdates = true
            worktree = ../../../sub
    $ cat worktop/sub/.git/config
    [core]
            repositoryformatversion = 0
            filemode = true
            bare = false
            logallrefupdates = true
            worktree = ../../../sub

git-new-workdir sought to reuse the config of top/sub/.git, but this
configuration had core.worktree set.  For the original checkout,
this worked fine, since its location was .git/modules/sub; but for the
new workdir, this relative path was nonsense.

I do not think there is really a way to make this work with
core.worktree.  Our saving grace, however, is there is a hack that can
make this work: we just need to use the
pre-501770e1bb5d132ae4f79aa96715f07f6b84e1f6 style of cloning
submodules:

    git clone remote/top oktop
    git clone remote/sub oktop/sub
    (cd oktop && git submodule init && git submodule update)

Now recursive git-new-workdir will work.

What's the upshot?  I propose two new features:

1. A flag for git submodule update which reverts to the old behavior
of making a seperate .git directory rather than collecting them together
in the top-level .git/modules

2. Teach git-new-workdir to complain if core.worktree is set in the
source config, and how to recursively copy submodules.

What do peopl think?

Thanks,
Edward

^ permalink raw reply	[flat|nested] 2+ messages in thread
end of thread, other threads:[~2014-09-13 11:25 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-09-12 13:58 git-new-workdir submodules interact poorly with core.worktree Edward Z. Yang
2014-09-13 11:25 ` Jens Lehmann

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).