On Apr 8, 2008, at 8:33 PM, Avery Pennarun wrote:
On Tue, Apr 8, 2008 at 11:03 PM, Roman Shaposhnik <rvs@xxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
