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

[Andy Parkins <andyparkins@gmail.com>]

On Friday 2007 May 18, Michael S. Tsirkin wrote:

> > 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.

Because you have changed something that the upstream repository supplied with 
no way of detecting it.  It's the same as if upstream supplied 
important_login_function.c and then you clone it; if your clone had a way of 
changing important_login_function.c to add a backdoor and passing that to 
people who clone from you without changing the commit hash that would be bad.

Submodules is the same; upstream might say
 kernel git://git.kernel.org/kernel-2.6.git
Then you clone it and use the override system to override that to
 kernel git://git.dodgykernel.org/backdoors.git
without having to change the repository.

The server should not be allowed to override the url that the client sees.  
Only the client should make that decision.

> 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?

That problem exists regardless of the method of changing URL - in your method 
though the change is entirely unrecorded because you've changed something 
that upstream supplied in an out-of-band manner.

> And what happens when the original super-project pulls from me -
> it seems that his .gitmodules will now point to my server?

Now that one is a good defence.  Okay; I accept that changing .gitmodules 
won't work.  However, I don't accept that the server should be allowed to 
supply overrides to the client.  Another method is needed.

> > 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

Of course there is a difference.  .git/config is different; .git/refs is 
different; .git/info/exclude is different; etc.  These are all per-repository 
settings - and there is no way for a server to force it's version of those 
files on a client.

> 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.

Yep.  That is the problem.  In the end the only practical solution might be to 
allow the server to supply part of the .git/config (which is essentially what 
your suggestion would do); but I think that that is a big step to take and 
has potential to be abused.



Andy
-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com