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<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
_______________________________________________
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
