Re: [PATCH] Teach git submodule update to use distributed repositories

From: Nigel Magnay <nigel.magnay@gmail.com>
Date: Jul 17, 2008, 15:07 UTC
Message-ID: <320075ff0807170807l1537e34ev510deda537e4d11e@mail.gmail.com>
In-Reply-To: <alpine.DEB.1.00.0807171513560.8986@racer>

On Thu, Jul 17, 2008 at 3:16 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 15 quoted lines

> Hi,
>
> On Thu, 17 Jul 2008, Nigel Magnay wrote:
>
>> Your attitude seems to be that the status-quo is in some way desirable;
>> "It's no wonder that this tool is awkward to use in your workflow.".
>> This workflow is really common, and there's actual, real people on this
>> list complaining about it. Don't we think it could be improved to be
>> non-awkward ?
>
> I do not think that the status quo is the best possible.
>
> But I think that the way you go makes things so confusing that those who
> use it apart from you will have problems.
>

Ok

Show 10 quoted lines

> For example, in your setup everybody would have to install _different_
> remotes in every submodule.
>
> And then some would ask themselves why the original origin was not good
> enough.
>
> And others would specify "-o origin" all the time, thinking it was
> required.
>
> There must be a better way to promote submodules to a usable state,

My attempt was to try and do some small simple things, but you could well be right, that might make some commands bloat out with unneccessary options just to get something done, and that would be bad.

Stepping back - lets try to come up with a better way (please comment and and critique)

What we'd like (to start with) is for $ git pull fred

perhaps with --submodules (as Petr mentions), perhaps with config settings and caveats, to produce a result that means you don't need to be aware that there were submodules, they're automatically fetched and updated based on commits that may only exist in fred's repository.

So currently, you can do $ git pull origin && git submodule init && git submodule update

And it works, but

$ git pull fred $ git submodule update

Can leave you with problems, because if a submodule wasn't pushed to origin, you won't have it available. This is because the commands are equivalent to

$ git pull fred
for each submodule()
  cd submodule
  git fetch origin
  git checkout <sha1>

So somehow, you need to replace 'git fetch origin' with the "correct" repository (on fred's computer). My patch was really just about being able to pass parameters to 'git fetch'. The problems are that if you did

$ git submodule update fred

Unless each submodule had a [remote] specified for "fred", you'd be stuffed. But what you could do is either by passing the right URL, or looking at the superproject [remote] for "fred" - i.e: If in the superproject you have

[remote "fred"]
        url = ssh://git@fred.local/pub/scm/git/workspace/thing/.git
[submodule "module"]
        url = ssh://git@repo/pub/scm/git/module.git

Then the submodule "module" on fred, if it's a working-copy, can be calculated
       ssh://git@fred.local/pub/scm/git/workspace/thing/module/.git

If it isn't a WC then you'd have to have a [remote "fred"] in that submodule, but I'm thinking that'd be a rare case.

I'd assumed (possibly wrongly?) that there was resistance to putting any of the submodule logic in things other than git-submodules.

As a starter for 10, how about
- a '--submodules' option to git fetch / pull
- using the remote name if known, calculate it if not based on the above

WDYT?