Re: [Texmacs-dev] Compiling SVN on Linux

[Alvaro Tejero Cantero]

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 <address@hidden> 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"
> <address@hidden> 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
>>> <address@hidden>  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
>>>> address@hidden
>>>> https://lists.gnu.org/mailman/listinfo/texmacs-dev
>>>
>>>
>>> _______________________________________________
>>> Texmacs-dev mailing list
>>> address@hidden
>>> https://lists.gnu.org/mailman/listinfo/texmacs-dev
>>
>>
>>
>>
>> _______________________________________________
>> Texmacs-dev mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/texmacs-dev
>
>
> _______________________________________________
> Texmacs-dev mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/texmacs-dev
>