On 7 Jul 2014 14:12, "Charles R Harris" <charlesr.har...@gmail.com> wrote:. > > 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.
No, git history hashes are effectively a hash of <history hash of base revision, new changes>. So when you rebase, you keep the same changes but move them to be based on a different base revision. This means that the rebased changes get new hashes, and git has no idea that the changes are related. If you merge, then git marks the original changes as being parents of the merge node, so it can answer questions like "what changes have been applied to maintenance/1.9.x since it branched from master?", and can do better cherrypicks because it can use a more recent common ancestor. -n
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
