Thanks for joining the thread, Michael!
Michael J Gruber wrote:
I don't think there is a direct gittish way for transferring the remote
config from one repo to a clone (other than copying what git submodule
does with .gitmodules etc.).
That's my impression, too, so I'm suggesting that the clone/push/pull
commands get an option to work with remotes in config.
Would it be sufficient for you if a clone could trigger the main repo to
update its remotes (i.e. git remote update)?
Hmmm, I'm not sure... How would the overall
merge-in-changes-from-upstream process work in that case?
Say the main repo has the code for "ThingOne" merged under a top-level
thing-one/ directory:
main/$ git remote add -f ThingOne git://thing/ThingOne.git
main/$ git merge -s ours --no-commit ThingOne/master
main/$ git read-tree --prefix=thing-one/ -i ThingOne/master
main/$ git commit -m "Merged ThingOne into /thing-one/"
Then the ThingOne folks update their code, so we want to incorporate
their changes into our version of their code. I think you're suggesting
that we might make a clone of the main repo then trigger a "git remote
update" in the clone's origin:
clone/$ make-origin-do-git-remote-update
What's not clear to me is how to proceed from here. At this point I'm
hoping there's some way I could do some work in the clone to merge the
changes the ThingOne folks did into our code. I'm too new to git to
know if there is a way forward -- is there?
(With the subtree merge pattern I'd run "git pull -s subtree ThingOne
master" in the main repo -- is there an equivalent achievable in the
clone if the main has done a "git remote update"?)
Thanks,
Marc
--
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
