Michael J Gruber wrote:
"pull -s strategy repo master" does a fetch followed by "merge -s
strategy repomaster", where repomaster is the ref for master on repo.
So, if you got that branch (repomaster=ThingOne/master) by cloning from
main you can do the merge (subtree or other) on your clone, even without
the remote repo config for ThingOne on clone.
I'm afraid I'm having trouble translating what you're saying into actual
git commands (or are you proposing some new git functionality?). How
would I get the ThingOne/master branch into the clone?
After some more thought I realized that the clone can just pull directly
from the ThingOne repository:
clone/$ git pull -s subtree git://thing/ThingOne.git master
(I'm still getting used to git's ability to match commit IDs from
anywhere -- it's magic! :) )
This goes a long way to where we want to be, in that we don't have to do
our merging work in the original main repository.
It would be nice, though, if the clone were able to use the main
repository's definition of the ThingOne remote. I can think of some
plausible scenarios where a person could get confused about which
repo/branch they're supposed to pull. It's easy to recover from that
kind of mistake, but there'd be less chance of a mistake if one could
tell git to "pull from X as defined in the origin repository".
And actually, git's remote functionality feels a bit crippled if clones
can't make some use of the origin's remotes. Is there a reason for
keeping remote definitions out of a clone?
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
