From: Roman Shaposhnik <rvs@sun.com>
Date: Wed, 09 Apr 2008 04:39:01 GMT
Subject: Re: Migrating svn to git with heavy use of externals
Message-ID: <49E9DCEC-8A9E-4AD7-BA58-5A40F475F2EA@sun.com>
In-Reply-To: <32541b130804082033q55c795b5ieaa4e120956ff030@mail.gmail.com>

On Apr 8, 2008, at 8:33 PM, Avery Pennarun wrote:

> On Tue, Apr 8, 2008 at 11:03 PM, Roman Shaposhnik <rvs@sun.com> wrote:
>> On Apr 8, 2008, at 2:01 PM, Avery Pennarun wrote:
>>> The way to understand git-submodule's operation is in terms of  
>>> what it
>>> actually does.  Roughly speaking, git-submodule-add puts things into
>>> .gitmodules and .git/config;
>>
>> I could be mistaken, but I don't think "git submodule add" does  
>> anything
>> to the .git/config. In fact, how settings migrate between .gitmodules
>> and .git/config has been a long standing source of slight confusion
>> for me.
>>
>> Please correct me if I'm wrong, but it seems that the only reason
>> for the file .gitmodules to be there at all is because it can be
>> revved through commits, just as any file under Git's control.
>> .git/config doesn't have such a property. Other than that, it is not
>> really needed, right?
>
> You have the last paragraph right, but I think the first paragraph  
> wrong :)

Well, may be we are talking about slightly different things, or   
there's a version mismatch,
but here's what I get with 1.5.4.5:
    $ git init
    $ git submodule add /tmp/GIT/1
    Initialized empty Git repository in /tmp/GIT/3/1/.git/
     $ cat .git/config
     [core]
	repositoryformatversion = 0
	filemode = true
	bare = false
	logallrefupdates = true
Now, .gitmodules is there alright, so if I do:
     $ git submodule init
I get the migration of settings to .git/config:
      $ cat .git/config
      [core]
	repositoryformatversion = 0
	filemode = true
	bare = false
	logallrefupdates = true
      [submodule "1"]
	url = /tmp/GIT/1/.git

>> Speaking of complications, it took me awhile to realize that 90%
>> of the Submodule magic seems to be based on the secret ability of
>> tree objects to hold references not only to blobs and trees but
>> also to *commits*:
>
> Indeed, this is the majority of the coolness right there.  The rest of
> the screwiness with .gitmodules and so on is really just to support
> fetching the objects for the submodules from repos than the primary
> supermodule one.

Yeap. It all reminds me a bit of symbolic links in file systems. With  
the
key difference being that symbolic links can only point to an object,
where we can actually reference a particular *state* of that object.

I like this ability very much. It comes especially handy when a single
component participates in multiple superprojects (being referenced
as a submodule) and every single one of them can reference a state
of the component that they like.

That said, I still can't quite figure out how to do a very basic thing:
how can I change the SHA1 that a tree objects refers to without
checking out a corresponding submodule first? IOW, suppose I've
just cloned ~/Superproject into /tmp/super-clone. All of the submodules
are still empty (nothing has been cheked out into them yet) and all
I want to do is to bump the version of one submodule
     /tmp/super-clone/foo
and then push the changes back to the ~/Superproject, so that everybody
who pulls from it get the newer foo. It seems that the procedure  
outlined
in Git's manual seems to be pretty heavyweight for such a simple thing.

>> That's exactly what makes me doubtful about .gitmodules being the
>> best place for storing the url, but then again, I don't have any
>> better ideas. :-( Yet ;-)
>
> There's definitely no better place; .git/config isn't versioned, and
> URLs don't belong in the tree objects themselves, which are otherwise
> location-neutral and transport-neutral.

Agreed. But I guess I'd be less confused if "git submodule" didn't muck
with .git/config at all. Or are there any other consumers of the  
information
that it puts there (except itself)?

> In my own use case, I think having all the objects from the
> supermodule *and* submodules all be in the same repo is what I want.
> This kind of obviates the need for .gitmodules entirely, if
> git-checkout and friends will do the right thing.  I think I'll submit
> some patches eventually once I have this figured out properly.

Hm. But what about those who might want to pull from you? .git/config
doesn't propagate, which means that they'll be kind of stuck, don't
you think?

Thanks,
Roman.