Re: [3/4] What's not in 1.5.2 (new topics)

["Michael S. Tsirkin" <mst@dev.mellanox.co.il>]

...

> > As relative path I would propose $SUPERURL/subproject/$SUBPROJECTNAME, ie.
> > if the superproject is at git://git.kernel.org/pub/super.git, the above
> > subproject would default to the URL
> > git://git.kernel.org/pub/super.git/subproject/linux24 which could be a
> > symlink on the server.
> 
> I'm really uncomfortable with the idea of relying on directory structure 
> passed the root repository path; from the
>  git://git.kernel.org/pub/super.git/
> point onwards; we don't have any right to expect that this is a real directory 
> tree.  As an example; svn URLs don't match up with what's on disk:
> 
>  svn://svnhost/pub/repo/trunk/src
>                        ^^^^^^^^^^
> 
> On disk there is no such directory as /trunk/src under the repository 
> directory.  In the same way, even technically what you suggest would work, 
> the part of the URL under git://git.kernel.org/pub/super.git/ is git's own 
> namespace - it's not the users to mess with.  E.g. if I had a subproject 
> called "refs" you'd be in trouble.

Oh, that's easily solvable: just stick a 'subprojects' directory in there.
That is, the default URL to find a subproject would be:

1. For non-bare repo foo/.git/, subproject bar will live in foo/bar/.git
   or foo/bar.git.
2. For a bare repo foo.git/, subproject bar will live in
   foo.git/subprojects/bar.git.

> > > 2. Suppose .gitmodules in upstream tree points at subproject repo at
> > > kernel.org, and I clone from there - my repo will point at kernel.org by
> > > default? But now, I'd like everyone who clones from *my* repo to get
> > > pointed at *my* server by default (e.g. for mirroring),
> > > but would not changing .gitmodules create a commit so my
> > > head will now differ from upstream  - so it won't be signed properly
> > > etc... Did I misunderstand something?
> >
> > No, that is correct. Supporting a relative URL specification as proposed
> > above should solve this issue.
> 
> I think that's the wrong solution.  A change of source URL for a submodule 
> from what upstream uses to your own server is a _fork_ from upstream, 
> therefore you would fork your own branch in your supermodule and 
> alter .gitmodules to point at your server.  Everybody is happy, and the fork 
> is recorded.

Why should I record it? If the content is the same, the commit name should
be the same, it shouldn't matter where did the content came from.

I wouldn't be happy: I have just cloned both project and superproject,
but to re-publish the superproject using my clone of subproject, I have
to create a new commit, which would have a different hash from the origin.
So how do people know they can trust my tree?
And what happens when the original super-project pulls from me -
it seems that his .gitmodules will now point to my server?

> The override system is only there for the local repository (which always takes 
> precedence) not for the server provider to hide detail from those checking 
> the repo out.

I really like it that currently, in git, there is no difference between a public
and local repository.  If the override system is only for the local repository,
we create a difference here - doesn't this break the distributed nature of git?

Take offline work as an example:

So I have have cloned the supermodule and the submodule to my laptop -
it's enough to edit .git/config and I can use the history locally - that's good.
But now I try to clone the local tree - and a clone will try to go out
to the URL which I cloned - bad.

-- 
MST