On 22/03/15 22:21, Roland Haeder wrote: > On Sun, 22 Mar 2015 21:40:41 +0000 > Matthew Toseland <mj...@cam.ac.uk> wrote: > >> On 22/03/15 19:22, Ian Clarke wrote: >> Unfortunately, sometimes it is necessary to make big changes. > One good example is the initial import of all files for a new project. > There you commit a huge chunk of files and directories. > > As I'm (different project) a newcomer to a project's development, I > had started cloning the original repository (creating a "personal > clone") and started developing. I did this by committing carefully and > I tried to avoid huge changes (not always possible, more below) to let > them easily review them. > > Then I stepped towards them and my commits got rejected because I > didn't make a "feature branch" or "fix branch" ... :-( That is kind of > frustrating because my commits won't make it in. > > What I mean here is that the maintainer should not be so bureaucratic > to newcomers as this could turn them away and they may never come back. > > The maintainer can then still review commits relatively easily by > setting up a "merge branch" > > git checkout master # or wherever your development branch is > git remote add rolands_code git://git.bla.example/some/foo.git --track > master > git checkout -b code_reviewed_okay/master > git checkout master > git checkout -b rolands_master > git pull rolands_code > > This way you can check your code with changes from developer > "roland" (yes, my name) without mixing it so quickly with your own > code. Then start the review process by looking at each commit and > cherry-pick it into "code_reviewed_okay/master" branch: > > git checkout code_reviewed_okay/master > git cherry-pick xxxxxx > git checkout rolands_master > > Then you can check them again (on functionality) in the review branch > (as not all commits from "rolands_master" are in) and continue with next > one. > > Maybe there is a better way. :-) But this way may work. After that > merge all reviewed commits into master: > > git checkout master > git merge -S code_reviewed_okay/master > > That seems to be a fine way to me. > > My 2 cents. :-) Your code should not be rejected because it is on master on your own repository IMHO. However, if you are going to make multiple pull requests you really need to use separate branches. If you have several different changes on the same branch then you definitely need to separate them out before making a pull request.
However, this is pretty easy using git branch, git reset and git cherry-pick.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
