Re: git+patch workflow [WAS: bundled intl stuff necessary]
Am Samstag 03 Januar 2009 21:53:20 schrieb Enrico Weigelt: * Slava Zanko slavaza...@gmail.com wrote: (bouncing back to the list ;-p) Hi, I not fully understand... How automate process of patch submission, in your mind? Okay, let's take an example: I'm currently working on some sub-project. Now I've did my work, everything seems okay for me and I'd like to publish it. All I now (ideally) would have to do is enter some quick command line (eg. including some description) and the rest goes automatic: my work is published, ticket opened, etc. Okay I work so: (on master branch): git checkout -b foobar [do some work] git add new files/changed files 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. Coming from the other side, it would be cool to have some command get me the changes from ticket xyz, so we don't have to download and apply the patches manually. Well... :) such a tool would be nice but doesn't exist atm. The best solution - use git branches for tracking patches, IMHO. hmm, heard of that, but never used it. How does it work ? hmm, do my changes then go to the current branch (assuming I've cloned from there) ? Yes, your changes will applyed to the main branch (named 'master'). You may create any count of commits (via git-commit), but this commits placed only in your local copy of repro. You may delete some of this commits, verge, revert commits... Okay, that's just normal working in the local repo ... but if you will run command 'git-push', all of your commits will frozen for changes. Because this commits transferred in parent repro and will see by any developer (via git-pull). git-pull will get latest changes from parent repro (like svn up, or full command: svn update). But this commits directly to our master repo, thus breaking our workflow, right ? Yes of course... Only commit the patch after it is acked... :) If you want to have own 'sandbox' with some patches (not included in 'master'), you may create new local branch: Can I freely create branches within the master repo ? And more important: *should* I do this ? Yes why not.. they are local as long as you don't push them to the server via git push $localbranch origin and this is something which should be done _very_ rare. As I think that there are several people not very familiar with git I'll write a small Howto use the git repro together with our workflow. After I'm finished I'll publish the url here. Greetings Winnie -- . '' ` . Patrick Winnertz win...@debian.org : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~winnie - http://www.der-winnie.de `- Debian - when you have better things to do than fixing systems signature.asc Description: This is a digitally signed message part. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: git+patch workflow [WAS: bundled intl stuff necessary]
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 everything. 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. Greetings Winnie -- . '' ` . Patrick Winnertz win...@debian.org : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~winnie - http://www.der-winnie.de `- Debian - when you have better things to do than fixing systems signature.asc Description: This is a digitally signed message part. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: git+patch workflow [WAS: bundled intl stuff necessary]
On Sun, Jan 04, 2009 at 06:10:06PM +0100, Patrick Winnertz wrote: Am Sonntag 04 Januar 2009 17:48:56 schrieb Oswald Buddenhagen: 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. to alleviate that one could have a collector branch to which all halfways ready feature branches (and master) are merged. but from that branch no-one would ever merge; it would be a constant dead end. unless it was decided that all branches are ready at the same time, in which case it *could* be merged. 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? you can have just one testing branch from which you constantly merge fixes to master and to which you merge master each time you want all new features for a new stabilization phase. but note the *all*. merging in git is always a wholesale thing (well, in fact, you can stop the merge before the current head of a branch, but you cannot omit changes in between). 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. that way you give up almost all of the power of git, including showing cool merge history graphs. you could have the same by creating local svn repositories for disconnected development and doing the merging via patches to a conventional central repository. git just doesn't work well for the freebsd model. it is optimized for the linux model, and of that only the main line (the stable series are a little cherry-pick sucker) - for obvious reasons. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
