Subject : git best practices
Jeroen van Meeuwen (Kolab Systems)
vanmeeuwen at kolabsys.com
Tue Sep 6 06:50:46 EDT 2011
Olivier ROLAND wrote:
> 2011/8/19 Henrique de Moraes Holschuh <hmh at 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]
$ 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
Jeroen van Meeuwen
Senior Engineer, Kolab Systems AG
e: vanmeeuwen at kolabsys.com
t: +44 144 340 9500
m: +44 74 2516 3817
pgp: 9342 BF08
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Cyrus-devel