Re: [Texmacs-dev] Compiling SVN on Linux

[Sam Liddicott]

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