Quoting Fritzek <[EMAIL PROTECTED]>:
> was my thought too, but I've tried it and it ended up in a deadlink of
> this submodule within my project. or do you mean to clone the fork
> directly under the vendor/plugins? A repo in a repo? 

I think there was probably something like a typo causing the dead link
because it should have been fine. You should be able to add your
public fork of the plugin to your private repository, make changes on
that checked out copy, and push them to your fork. See the git
submodule tutorial for details:
        http://git.or.cz/gitwiki/GitSubmoduleTutorial 
To get those changes included in the original plugin, you need to send
a pull request offering your public fork's changes to the original
plugin author.

> How about then
> with the security issues Cynthia mentioned before? The pull request
> was not working because of the private repo the submodule was
> included.
> The working way for me: project and fork are divided, changes of the
> plugin going to the fork, changes of the project to the repo, the
> submodule will be updated as of the state of the fork, the fork will
> updated after origin accepts the pull request
> 
> big thanks to all for help and thanks to github for perfect service
> 
> Fritzek
> 
> 
> On 9 Okt., 21:47, "GitHub Support" <[EMAIL PROTECTED]> wrote:
> > Fritzek,
> > The nice thing about submodules (maybe the only nice thing?) is that you can
> > work directly in the submodule repo and push from there, you don't have to
> > make a clone somewhere else to work on it.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"GitHub" group.
To post to this group, send email to github@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/github?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to