Generally speaking every time you want to fix something new which is unrelated to existing patches which have not been upstreamed you can simply do:
# Lets assume this step is already done and the mono repository is called 'mono_repo' in your fork git remote add mono_repo git://github.com/mono/mono.git # Pull all the latest commits from mono_repo git fetch mono_repo # Create a new branch based on the latest commit in mono_repo in the master branch git checkout -b NEW_BRANCH_TO_FIX_FOOBAR mono_repo/master That's the simplest way to get a 100% clean and up-to-date branch every time you want to make a new fix. When you are done you can push the new local branch to your fork using the syntax: git push origin NEW_BRANCH_TO_FIX_FOOBAR That pushes the curreny branch to a remote branch of the specified name. Hope that helps, Alan On 17 June 2012 15:29, Stifu <st...@free.fr> wrote: > One fix = one patch + one test (if possible). > As for the lock you added, just merge that with your earlier patch, so that > the patch really fully fixes the problem. > > If some patch requires another patch first, just specify that here. I'll > probably review the easiest patches first, to get them out of the way. If > you want to suggest a certain review order, go ahead. > > > Rob Wilkens wrote >> >> I was going to plan to break this up into individual commits, but >> instead when i get to this i may break it up into each file's worth of >> changes (or in the case of some commits, set of files) and document what >> fixes what in each, if that is ok with you? i.e. i'll try to document >> what was changed line by line or set of lines, and specifically when >> documenting it cover the 'why'. >> >> The reason for this is that i have some changes i made in earlier >> commits which 'worked' but every so often crashed while adding an idle >> handler i later found, and i fixed this with a lock (this) {} in a later >> commit around a very small section of code (2-4 lines).. But that was >> after i made unrelated changes elsewhere (the datagrid changes). >> >> Or if you prefer i get it commit by commit i'll do that, but in that >> cases, at least some of the commits will have to be applied in the same >> order because they have a dependency on a previous commit going through. >> >> -Rob >> >> On 06/17/2012 09:34 AM, Stifu wrote: >>> Alright, I'm not in a hurry. >>> >>> >>> Rob Wilkens wrote >>>> I won't have time to do that right now, but will later, please be >>>> patient.. I wouldn't wait around the keyboard right now for an e-mail >>>> because i'm next in line for the shower then we're heading out for >>>> morning. >>>> >>>> The bug reports are listed on the pull page, but i will try to separate >>>> the changes out into what fixes what. >>>> >>>> -Rob >>>> >>>> >>>> On 06/17/2012 09:26 AM, Stifu wrote: >>>>> Please separate each patch, so I can review them one by one. This is >>>>> just >>>>> too >>>>> big to review, and I don't know even know what it's trying to fix. >>>>> Also, please give me the concerned bug reports, if any. >>>>> >>>>> >>>>> Robert Wilkens wrote >>>>>> Ok, if you are willing to look at it, i've attached it if i did it >>>>>> right... >>>>>> >>>>>> I did a git diff <commit just before first commit> <last commit> >>>>>> >>>>>> That should have the whole range of changes of all the commits, >>>>>> hopefully i've attached the right file too. >>>>>> >>>>>> This should align with the following pull request on github.com: >>>>>> https://github.com/mono/mono/pull/322 >>>>>> Which originally was a closed pull request which i cancelled when i >>>>>> needed to make additional changes: >>>>>> https://github.com/mono/mono/pull/312 >>>>>> >>>>>> I'm probably not going to be home all day today, so if you have >>>>>> questions, i am willing to answer them but i may be delayed. I'll try >>>>>> to bring my laptop if i do go out. >>>>>> >>>>>> -Rob >>>>>> >>>>>> On 06/17/2012 08:21 AM, Stifu wrote: >>>>>>> Can't really give Git-related advices, I suck at it, but I can easily >>>>>>> review >>>>>>> WinForms patches if you simply attach them to your messages the >>>>>>> old-school >>>>>>> way. >>>>>>> >>>>>>> >>>>>>> Robert Wilkens wrote >>>>>>>> My master branch contains two unrelated winforms changes (one change >>>>>>>> for >>>>>>>> idle, one change for DataGrid - not DataGridView don't worry i'm not >>>>>>>> duplicating work), it's becoming clear that they are not going to >>>>>>>> receive priority and i have no problem with that. >>>>>>>> >>>>>>>> But i do have at least one non-winforms fix which i'd like to at >>>>>>>> least >>>>>>>> get reviewed. That's not going to happen since the winforms changes >>>>>>>> have to go thru first. >>>>>>>> >>>>>>>> Is it considered a safe thing to: >>>>>>>> 1) Backup the files that i changed for each fix >>>>>>>> 2) Delete my fork >>>>>>>> 3) Create a new fork >>>>>>>> 4) Create branches for each change and submit them separately >>>>>>>> >>>>>>>> I think this would help me get past my current state of 'i can't >>>>>>>> really >>>>>>>> do anything until my master branch is approved or rejected'... >>>>>>>> >>>>>>>> I probably won't do this today, but if I don't hear back i might do >>>>>>>> that >>>>>>>> sometime this week. >>>>>>>> >>>>>>>> -Rob >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Mono-devel-list mailing list >>>>>>>> Mono-devel-list@.ximian >>>>>>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list >>>>>>>> >>>>>>> -- >>>>>>> View this message in context: >>>>>>> http://mono.1490590.n4.nabble.com/Restart-my-fork-tp4650004p4650006.html >>>>>>> Sent from the Mono - Dev mailing list archive at Nabble.com. >>>>>>> _______________________________________________ >>>>>>> Mono-devel-list mailing list >>>>>>> Mono-devel-list@.ximian >>>>>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list >>>>>> _______________________________________________ >>>>>> Mono-devel-list mailing list >>>>>> Mono-devel-list@.ximian >>>>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list >>>>>> >>>>> -- >>>>> View this message in context: >>>>> http://mono.1490590.n4.nabble.com/Restart-my-fork-tp4650004p4650009.html >>>>> Sent from the Mono - Dev mailing list archive at Nabble.com. >>>>> _______________________________________________ >>>>> Mono-devel-list mailing list >>>>> Mono-devel-list@.ximian >>>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list >>>> _______________________________________________ >>>> Mono-devel-list mailing list >>>> Mono-devel-list@.ximian >>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list >>>> >>> >>> -- >>> View this message in context: >>> http://mono.1490590.n4.nabble.com/Restart-my-fork-tp4650004p4650011.html >>> Sent from the Mono - Dev mailing list archive at Nabble.com. >>> _______________________________________________ >>> Mono-devel-list mailing list >>> Mono-devel-list@.ximian >>> http://lists.ximian.com/mailman/listinfo/mono-devel-list >> >> _______________________________________________ >> Mono-devel-list mailing list >> Mono-devel-list@.ximian >> http://lists.ximian.com/mailman/listinfo/mono-devel-list >> > > -- > View this message in context: > http://mono.1490590.n4.nabble.com/Restart-my-fork-tp4650004p4650013.html > Sent from the Mono - Dev mailing list archive at Nabble.com. > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list _______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list