Hi, I just found out that many projects use this guide (with nice graphical explanations) as their model workflow when using git
http://nvie.com/posts/a-successful-git-branching-model/ As a side note: github is really really well done. It is a pleasure to work there. -á. On Sun, Mar 25, 2012 at 14:53, Sam Liddicott <[email protected]> wrote: > 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 >>> >>> (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 >>> >>> >>> >>> >>> >>> 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 >>> >>> >>> _______________________________________________ >>> Texmacs-dev mailing list >>> [email protected] >>> https://lists.gnu.org/mailman/listinfo/texmacs-dev >> >> >> >> >> _______________________________________________ >> Texmacs-dev mailing list >> [email protected] >> https://lists.gnu.org/mailman/listinfo/texmacs-dev > > > _______________________________________________ > Texmacs-dev mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/texmacs-dev > _______________________________________________ Texmacs-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/texmacs-dev
