Am Sonntag 04 Januar 2009 17:48:56 schrieb Oswald Buddenhagen:
> On Sun, Jan 04, 2009 at 05:21:29PM +0100, Patrick Winnertz wrote:
> > git diff master > /tmp/$new-patch-to-publish.patch
> > git reset --hard $sumoflastcommit (e.g. atm:
> > 4c58d938cbe836c48c105eeb525a2ffc8dd519e5)
> >
> > git show # now everything should be clean and no changes should be there.
> > git checkout master
> > git branch -d foobar (or -D foobar if there are changes which are not
> > merged into master)
> > publish now the patch on trac via email or webinterface.
> you want to play with
>   git rebase -i
>   git format-patch
>   more?
Yes.. this tools are cooler than this way I described above, that's true. I 
picked the above because it's using only rudimental functions of git which 
should already be known from other vcs systems. 
> fwiw, the suggested backporting workflow is quite a nightmare with git,
> as all the merging goodies work only with forwardporting.
I know but having many many branches with patches inside is also a nightmare.. 
in order to have a overview. 

> instead, you need to develop on master (the conventional name for the
> trunk), branch for stabilization of each release, do *all* bugfixing in
> the current stable branch and merge it back into master each time fixes
> have been applied.
A improvement of the situation atm would be to make master the stable branch 
and creating one testing branch which is based on master, wouldn't it? 
This would be the easiest change in oder to do not completly rework 
> major new features have to be developed on branches
> of master, so they can be merged back into master. everything else
> results in use of cherry-pick,
cherry-pick was the tool I wanted to use. 

 . '' ` .   Patrick Winnertz <>
:  :'   :   proud Debian developer, author, administrator, and user
`. `'` -
  `-  Debian - when you have better things to do than fixing systems

Attachment: signature.asc
Description: This is a digitally signed message part.

Mc-devel mailing list

Reply via email to