Olivier ROLAND wrote: > 2011/8/19 Henrique de Moraes Holschuh <h...@debian.org>: > > IMHO, if you're going to come up with rules for that, better do as it is > > done in the Linux kernel or in git itself. > > > > The rules are: > > * detailed changelogs on every commit > > * only cleaned up commits are sent up for merging in the mainline. > > > > The cleaned-up commits are not large squashes (those are impossible > > to understand), instead they should look like you did everything > > perfectly at the first try, but step-by-step. > > > > * Bissectability is very important and should be preserved, so the > > > > tree should build _and run_ at every commit. > > > > * Don't rebase topic branches on top of the latest mainline, unless > > > > you actually need to do it for it to run. Base topic branches on > > stable points of the mainline. > > Sounds good to me. > Bron, you ask us to just point you to a git branch with our patches. > The problem is that sometimes we discuss things and the branch become a > development branch with (useless for master) history. > Maybe it would be more convenient if we can work with pull request > like on github : http://help.github.com/send-pull-requests/ >
If genuinely a topic-branch, try the following: $ git checkout --track -b dev-something origin/master $ git config branch.dev-something.autosetuprebase always ^ I have this in my ~/.gitconfig to apply globally, BTW $ <make edit #1> $ git commit $ <send patch to mailing list / attach to ticket> $ <receive feedback, further edits> $ git commit (possibly git pull rebasing your working copy changes) $ git diff [options] origin/master [-- files and paths] or $ git diff dev-something...master For what [options] can give you (such as -c and --cc). Is that acceptable? Should we document such (with comments and feedback appreciated!)? Kind regards, Jeroen van Meeuwen -- Senior Engineer, Kolab Systems AG e: vanmeeuwen at kolabsys.com t: +44 144 340 9500 m: +44 74 2516 3817 w: http://www.kolabsys.com pgp: 9342 BF08
