On Wed, Apr 24, 2013 at 04:44:29PM +0200, Adam Stankiewicz wrote:
> My proposal is to move default bare repository location from .git/modules
> to .git directory inside submodule, like every normal git repo do.
That's the way it was in old versions of git. The git-file approach was
implemented so git could deal with adding or removing submodules. For
example, if a submodule is not in version HEAD~ and you do a checkout
HEAD~ your working dir should not contain the submodule. (Unfortunately
we are not there quite yet).
> These are my arguments:
> 1. Why git submodule needs to know in which project it is embedded in? Or
> even that it's generally submodule? When cd to submodule, it behaves like
> normal repository. Only repository needs to know about its submodules.
A git submodule doesn't know about it's superproject. All git repos can
be used with git-files. I wouldn't say that a .git-file makes a git repo
aware that it's a subproject (which doesn't even had to be true).
The superproject needs to work with the working-tree, having repo data
in the worktree like svn and cvs is a bad thing. I really like having
all meta data in the same spot.
And there's the "checkout old commit without submodule" problem but
of course, your "mv-approach" would solve this.
> 2. You can't move submodule outside git repository and use it as normal git
> repo. You have to copy bare repo from .git/modules dir.
You can, if you edit .git-file. However in either case your can't use
your superrepo in a sane way if you move out your submodule. So why
would you do that?
If you only need the submodule repo, just clone the submodule repo.
> 3. It's not enough to delete submodule from workingdir to "refresh" it
> later. You have to go to .git/modules directory and delete appropriate
> What about performance on checkouts?
I think that performance penalty is too small to be cared about, if you
look at all the other file access stuff that git does every time.
Med vänliga hälsningar
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html