On Mon, Jul 7, 2014 at 2:34 PM, Charles R Harris <charlesr.har...@gmail.com> wrote: > On Mon, Jul 7, 2014 at 2:02 AM, Julian Taylor > <jtaylor.deb...@googlemail.com> wrote: >> >> On 07.07.2014 07:53, Charles R Harris wrote: >> > Just so. The fixes for 1.9.0b1 are now in that branch ready for the next >> > beta. >> > >> >> how did you do that without a merge commit? > > > git branch tmp maintenance/1.9.x > git co tmp > git branch -f maintenance/1.9.x d244ec7 > git rebase -p --onto tmp 10098da maintenance/1.9.x > >> >> however you did it you have git has lost ancestry which is not so nice >> for backporting. > > > Same changesets, I believe. If '-p' is omitted the merges are omitted. > >> >> If there are no objections I'd like to rewind the maintenance branch >> back to beta1 and merge master in properly. > > > I thought this somewhat cleaner than a merge :0 >
By rebasing or cherry-picking git loses the information that the changeset originates from another branch. So when you try to merge or cherrypick more changes from the branch the changes are coming from the automerging bails or is at least less useful. So if you are moving changes from one branch to another one should merge whenever possible. Now that both branches have diverged, 1.9 by the release commit, and 1.10 by the opening commit, there is no easy way for git to track the origins of a changeset and we have to do the usual cherry picking, as to my knowledge git does not have partial merges. _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
