On Thu, Jul 17, 2008 at 3:16 PM, Johannes Schindelin
<Johannes.Schindelin@xxxxxx> wrote:
> 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
> 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@xxxxxxxxxx/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@xxxxxxxxxx/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?
--
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
