Am 08.08.2012 04:21, schrieb Aaron Meurer:
IMHO, rebasing has too high of a potential of making the history not make sense even if you don't squash, because of the way that changes can be "rebased out" of commits.
The only situation where that happened to me was when I accidentally resolved a merge conflict in favor of "drop my change" without noticing it. You really need to know what you're doing when rebasing.
However, I wouldn't ban rebasing to the back seat. Commit histories often need to be cleaned up to remove dead ends (so people don't hit them during a bisect), or to protect the developer from embarrassment or publishing private data. Such a rebase can be done in a separate step that doesn't merge with master. I don't have the exact incantation memorized, I think its
git rebase -i origin or something like that. Just my 2c. -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
