On Sun, Oct 17, 2010 at 1:48 PM, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
2010/10/17 Stéfan van der Walt <stefan@sun.ac.za>:
On Sun, Oct 17, 2010 at 12:23 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
IIRC, they recommended pushing from local branches to master on github and not merging master to the development branches. That doesn't sound right to me, but perhaps I misunderstood...
The idea is not to keep merging the master branch into your development branch to keep up to date (this makes for really ugly history).
Another merge commit: http://github.com/numpy/numpy/commit/427d3fcabe5
For single commits, merge back into master (hopefully this should be a fast-forward merge), which then creates an svn-like timeline.
Actually I think that the "push local branch to github master" approach that Charles referred to above is better. Because that will fail if the merge is not fast-forward, so you never get merge commits if you don't want them. The "merge into local master" way will give you a merge (which is why you said "hopefully" above) if you forgot to rebase your feature branch first.
For pull requests of 1 or 2 commits on github, this should work: $ git co -b local-branch http:github.com/username/branch-to-pull $ git rebase master # (or maintenance/1.5.x) $ git push origin local-branch:master This will either give a ff merge or fail. Right now it's turning into a bit of a mess, with completely unrelated commits forming small branches: http://github.com/numpy/numpy/network Cheers, Ralf
For bunches of commits, merge back into master with the --no-ff switch to ensure that a merge message is generated (this makes it much easier to find those grouped commits later).
After the merge, push back upstream.
Regards Stéfan _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion