Jakub Narebski [off-list ref] writes:
"Nigel Magnay" [off-list ref] writes:
quoted
Fred is a person (and != origin). His tree(s) are entirely correct and
consistent, and he doesn't yet wish to push to origin (and perhaps he
cannot, because he does not have permission to do so).
...
I _think_ that you can currently work around this problem by using
URL rewriting (url.<base>.insteadOf).
Doesn't it also involve config modification?
I think the right thing to do for this kind of "trial merge" should be the
same as cases that do not involve submodules. You *DO NOT* give a handy
way to muck with your configuration to make "origin" point at fred.
Instead, you would do something like:
$ git fetch ../fred master
$ git checkout FETCH_HEAD
... review test fix ...
... when you are done, go back, discarding the state from Fred
$ git checkout master
What submodule changes from the above workflow would be what happens after
you switch to the trial state (the above example detaches HEAD temporarily
while peeking into Fred's history). It is understandable that you would
want to script something that recurses into the submodules that you have
checked out (or submodules that Fred wants you to look at), do the
equivalent of "git fetch ../fred" you did at the toplevel to automate that
step, but I very much agree with Pasky here in that it feels very wrong to
hijack "submodule update" for it.
Junio C Hamano wrote:
[...] It is understandable that you would
want to script something that recurses into the submodules that you have
checked out (or submodules that Fred wants you to look at), do the
equivalent of "git fetch ../fred" you did at the toplevel to automate that
step, but I very much agree with Pasky here in that it feels very wrong to
hijack "submodule update" for it.
There were two proposals how to deal with fetching all submodules:
(a) git-submodule recursing into submodules, IIRC even with some
implementation (b) new "git submodule fetch" command.
--
Jakub Narebski
Poland
On Fri, Jul 18, 2008 at 10:07 AM, Jakub Narebski [off-list ref] wrote:
Junio C Hamano wrote:
quoted
[...] It is understandable that you would
want to script something that recurses into the submodules that you have
checked out (or submodules that Fred wants you to look at), do the
equivalent of "git fetch ../fred" you did at the toplevel to automate that
step, but I very much agree with Pasky here in that it feels very wrong to
hijack "submodule update" for it.
There were two proposals how to deal with fetching all submodules:
(a) git-submodule recursing into submodules, IIRC even with some
implementation (b) new "git submodule fetch" command.
Yes - I think there's a few more options and possible combinations
a. git submodule update having <repository> <refspec> to recurse into
submodules (a)(original patch)
b. git submodule fetch
c. git fetch --submodules
d. git fetch (automatically recurse if there are submodules)
e. git fetch (automatically recurse if there is some setting in .git/config)
I started at (a) and agree that it's a bad choice.
Any of b-e would work for me.
My (personal) preferences would be for d/e, then c, then b - but -
that's based on my belief that submodules are a pretty fundamental
thing and having a separate UI is bad.