[Mono-dev] Restart my fork?

David Schmitt david at dasz.at
Mon Jun 18 08:23:12 UTC 2012 

Rob,

if you want to go the advanced-git-route, you can always "rebase" your 
patch on top of the current master.

This gives you a clean patch in the face of upstream changes, even in 
the same area of code. On the downside, it changes the commit-hashes and 
creates a "break" in the history of your branch.

Please read these docs for an in-depth explanation:

> http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html
> http://git-scm.com/book/en/Git-Branching-Rebasing

If you prefer a more manual method, you can create a new branch, like 
Alan described and use cherry-picking and amending to re-apply the 
patches from the old branch onto the new master in the correct order.


Thanks for your time and work!

Best Regards, David

On 18.06.2012 04:08, Rob Wilkens wrote:
> Thanks very much -- I started a branch for bug 2663 fixes this way just
> now.  But i need to test it against the latest source to make sure it
> still works (there's no reason it shouldn't, but for sanity).  I will
> probably finish this testing tomorrow since i need to test 'before' and
> 'after' my patch to make sure (1) the unit tests still pass (2) other
> unit tests don't fail unless they were failing before.
>
> -Rob
>
> On 06/17/2012 11:10 AM, Alan wrote:
>> 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<stifu at 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 at .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 at .ximian
>>>>>>>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>>>>>>> _______________________________________________
>>>>>>>> Mono-devel-list mailing list
>>>>>>>> Mono-devel-list at .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 at .ximian
>>>>>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>>>>> _______________________________________________
>>>>>> Mono-devel-list mailing list
>>>>>> Mono-devel-list at .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 at .ximian
>>>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>>> _______________________________________________
>>>> Mono-devel-list mailing list
>>>> Mono-devel-list at .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 at lists.ximian.com
>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>> _______________________________________________
>> Mono-devel-list mailing list
>> Mono-devel-list at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>

More information about the Mono-devel-list mailing list