[Numpy-discussion] Another merge at github
Sun Oct 17 04:11:59 CDT 2010
On Sun, Oct 17, 2010 at 1:48 PM, Ralf Gommers
> 2010/10/17 Stéfan van der Walt <firstname.lastname@example.org>:
>> On Sun, Oct 17, 2010 at 12:23 AM, Charles R Harris
>> <email@example.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
> 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
>> 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.
>> NumPy-Discussion mailing list
More information about the NumPy-Discussion