If you don't like to merge a branch into master then rebase the branch on master and then it becomes the new master.
git checkout branch git rebase master After the rebase and any fixups to make the branch commits apply to master, then: git checkout master git reset --hard branch Branch and master are now at the same place and branch could be deleted. We only do reset like that's because after rebase the branch contains and builds on the master tip, so the reset just adds the rebased branch commits. Rebasing like that will give you a set of clean patches to send to Joris with git format-patch. If you send to Joris you would : git svn rebase So that you master is now on top of svn And then something like git format patch $( git merge-base svn/master master) HEAD Which spits out a bunch if patches ( or can upload to inappropriate drafts folder) or something. Joris will apply and when you next git svn rebase you patches should drop out as they are now upstream. Like the Bible, reading git man pages again and again can give great personal insight! Sam On Mar 25, 2012 12:26 PM, "Miguel de Benito Delgado" <[email protected]> wrote: > After only one week using git I must say thanks guys for insisting! I've > branched like crazy, often in the past with > > git branch -m master somenewbranch > git branch master HEAD~N > > for some natural number N, ;-P. I currently have a few branches with > subprojects and I branch again for bugfixes or experiments and everything > is FAST! Merging is smooth (although I still hate it) and another feature I > love is the stashing away of changes. > > For the browsing of changes and regular use I love SourceTree for MacOS, > it's free and it's great. You can browse everything really fast, stage or > discard hunks from your changes before committing and you can do almost > anything in an easy way. Not opensource, though. > > Thanks for convincing me to switch! > > Miguel. > > Alvaro Tejero Cantero wrote: > >> I found a nice description of a workflow[1] that, if I am not >> mistaken, would please Joris: contributors prepare carefully thought >> out pull requests, eventually rebasing them if necessary so that no >> conflicts arise upon merging, and shoot out a pull request. This is >> how it looks like from the main developer's (main branch) control >> center: >> >> https://github.com/pydata/**pandas/pulls<https://github.com/pydata/pandas/pulls> >> >> (of course, core devs will have something similar, so that you can >> think of a hierarchical structure whereby a new dev would request pull >> from a core dev and only after some time in the tree of a core dev >> would a pull request be issued against the main branch). >> >> -á. >> >> [1] This is the description of the workflow that includes instructions >> on how to test, etc. >> >> http://pandas.pydata.org/**developers.html#working-with-**the-code<http://pandas.pydata.org/developers.html#working-with-the-code> >> >> >> >> >> >> On Fri, Mar 16, 2012 at 05:09, Joris van der Hoeven >> <[email protected]> wrote: >> >>> On Thu, Mar 15, 2012 at 04:32:05PM +0100, Joris van der Hoeven wrote: >>> >>>> On Thu, Mar 15, 2012 at 02:53:06PM +0000, Sam Liddicott wrote: >>>> >>>>> Forgive me if this has been discussed to death, but I haven't seen much >>>>> discussion on it re:-) >>>>> >>>>> If you use git then people can sit on commits a bit longer before they >>>>> have >>>>> to push them. Less rushing and more testing means less bad commits. >>>>> >>>> One more thing about this issue: the main difference between SVN and >>> GIT is >>> that GIT would allow me to extract useful patches from a contributors >>> GIT repository. >>> If contributors have write access, then both SVN and GIT allow for >>> erroneous commits. >>> >>> Now I do not want to _extract_ useful patches from contributors code. >>> It is up to contributors to carefully _prepare_ patches that are as >>> comprehensive as possible for me. Contributors who are sure >>> about what they are doing may commit themselves. >>> >>> This does not withstand that _you_ may use GIT for maintaining a local >>> copy >>> and preparing your patches. Max maintains a GIT mirror for this. >>> >>> Best wishes, --Joris >>> >>> ______________________________**_________________ >>> Texmacs-dev mailing list >>> [email protected] >>> https://lists.gnu.org/mailman/**listinfo/texmacs-dev<https://lists.gnu.org/mailman/listinfo/texmacs-dev> >>> >> >> ______________________________**_________________ >> Texmacs-dev mailing list >> [email protected] >> https://lists.gnu.org/mailman/**listinfo/texmacs-dev<https://lists.gnu.org/mailman/listinfo/texmacs-dev> >> > > > > ______________________________**_________________ > Texmacs-dev mailing list > [email protected] > https://lists.gnu.org/mailman/**listinfo/texmacs-dev<https://lists.gnu.org/mailman/listinfo/texmacs-dev> >
_______________________________________________ Texmacs-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/texmacs-dev
