Re: [PATCH 5/5] Add gitmodules(5)

From: Lars Hjemli <hjemli@gmail.com>
Date: Jun 12, 2007, 10:23 UTC
Message-ID: <8c5c35580706120323t52b0d095v6ab6013ee2c8fdea@mail.gmail.com>
In-Reply-To: <200706121145.22699.Josef.Weidendorfer@gmx.de>

On 6/12/07, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:

Show 13 quoted lines

> On Tuesday 12 June 2007, Lars Hjemli wrote:
> > This is somewhat intentional. I want to move the submodule repos into
> > .git/submodules/$name/ (with working dir) and symlink this directory
> > when 'checking out' the submodule. This would be a simple solution for
> > the following problems:
> >   -keeping submodule modifications between checkouts
> >   -having submodules within submodules
>
> Interesting idea.
>
> How does this work
> (1) if the submodule checkout changes with the supermodule checkout?
> You still would have to store the modifications somewhere.

If you're thinking about the detached HEAD: yeah, that's a problem. My initial plan (with later modifications) was something like this:

[path "lib1"]
  submodule=lib
  branch=stable

[path "lib2"]
  submodule=lib
  branch=bleeding

[submodule "lib"]
  url=git://example.com/lib.git

$ git-submodule init
  git-config submodule.lib.url git://example.com/lib.git

$ git-submodule update
  git-clone --bare git://example.com/lib.git .git/submodules/lib.git
  git-clone -l -s -n .git/submodules/lib.git lib1
  (cd lib1 && git-checkout $sha1)
  git-clone -l -s -n .git/submodules/lib.git lib2
  (cd lib2 && git-checkout $sha2)

git-submodule push:
  (cd lib1 && git-push origin $branch1)
  (cd lib2 && git-push origin $branch2)

I thought I could avoid 'git-submodule push' by using symlinks, but you're right. It will not work. Back to the drawing board (again...)

> (2) on platforms which do not allow symlinks

Ok, bad idea.

>
> A workaround for problem (1) would be to create multiple checkouts of the
> same submodule if modified, e.g. in .git/submodule/$name/$sha1 .

And the $sha1 would be the sha1 found in the index? I don't think this would work either. If two branches in the superproject checkout the same submodule sha1, you could possibly want to keep different changes in the submodule depending on which branch of the superproject is checked out.

I guess the user will have to both commit and push submodule changes before switching branches etc. But that might not be too bad, at least for the initial submodule support.

Show 5 quoted lines

>
> Allowing people to work like that is nice, but it should not be forced.
> It would also be nice to allow the user to specify another place where
> submodule checkouts are to be stored, e.g. when multiple supermodules
> share the same submodule.

True. Maybe submodule.<name>.repopath in .git/config? (If not specified, default to .git/submodules/<name>.git)

-- larsh