2010/10/29 Konstantin Kudryashov <[email protected]>: > Ok. You fork original repo, change something on master, push it to GitHub, > then do Pull Request & this request gets canceled by original repo owner. > Then original repo owner push own commits. Now, how'd you revert your > changes (remember, they already pushed to GitHub) & merge latest original > repo into your fork, if you doing all this on master?
Hmm... This should be done this way: git pull (all latest changes from master) git branch my_new_feature do something git commit git push my_tree my_new_feature send request - please pull: git pull git://mytree.com/my_tree_path my_new_feature Now tree owner pulls this to his master. Basicaly this is how Linux developer works. Kind regards, Michal > > 2010/10/29 Michał Piotrowski <[email protected]> >> >> Hi, >> >> 2010/10/28 Marijn <[email protected]>: >> > Hi everybody, >> > >> > I would like to propose the following: should we adapt Vincent >> > Driesens branching model for git? >> > >> > http://nvie.com/posts/a-successful-git-branching-model/ >> >> I'm using git for five years (I started when Torvalds released first >> version for Linux - I was doing OS research) and IMHO this model is >> _totally broken_. >> >> IMHO the best solution is develop on master branch - almost everyone >> is doing it this way. I do not understand why anyone would invent such >> a model 8) >> >> My simple git usage rules: >> - develop on master >> - tag releases >> - create branches from tags >> - fix bugs on master, cherry pick for stable releases >> (this is nothing new and inventive - 99% peoples uses git in such way) >> >> Best regards, >> Michal >> >> > >> > I understand that everything is under heavy development at the moment >> > so right now it may not be so applicable. But in my opinion it could >> > provide us with a little bit more structure when comparing all the >> > different forks out there.. >> > >> > There is also a command line tool which makes the whole branching + >> > merging experience even simple (is that even possible). Which wouldn't >> > hurt for managing those pull requests. >> > >> > http://github.com/nvie/gitflow >> > >> > Just a thought, kindest regards, >> > >> > Marijn >> > >> > -- >> > If you want to report a vulnerability issue on symfony, please send it >> > to security at symfony-project.com >> > >> > You received this message because you are subscribed to the Google >> > Groups "symfony developers" group. >> > To post to this group, send email to [email protected] >> > To unsubscribe from this group, send email to >> > [email protected] >> > For more options, visit this group at >> > http://groups.google.com/group/symfony-devs?hl=en >> > >> >> -- >> If you want to report a vulnerability issue on symfony, please send it to >> security at symfony-project.com >> >> You received this message because you are subscribed to the Google >> Groups "symfony developers" group. >> To post to this group, send email to [email protected] >> To unsubscribe from this group, send email to >> [email protected] >> For more options, visit this group at >> http://groups.google.com/group/symfony-devs?hl=en > > -- > If you want to report a vulnerability issue on symfony, please send it to > security at symfony-project.com > > You received this message because you are subscribed to the Google > Groups "symfony developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/symfony-devs?hl=en > -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
