On Mon, Jul 7, 2014 at 6:46 AM, Julian Taylor <jtaylor.deb...@googlemail.com > wrote:
> 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. > Yes, what I did was like one big cherry-pick. But I think we end up in the same place with two divergent branches. I think git history is just a string of changesets and each changeset has a hash. Same hash, same changeset, and I think that was preserved, so in that sense history was preserved. The 1.9.x branch pushed without trouble. Anyway, six of one, half dozen of the other. I was going to do the merge route originally, even did the merge. Chuck
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
