Hi! On another thread, there was talk about "avoiding unnecessary merge comits". I agree that a nice git history is, well, nice. But I need some pointers to achieve it.
Situation: I have a local branch "branch_local" (not published) that I'd like to rebase on top of the latest develop, in order to have a nice history. However, "git rebase develop" fails due to several conflicts. But, to my slight surprise, "git merge develop" works without conflict. Additional complication: My local branch contains (or depends on) another branch "branch_public" that is published on trac but isn't in "develop" yet. Thus (if one accepts git's notion of history), it would be bad to rebase it. Questions: 1. Why does "git merge develop" work when "git rebase develop" doesn't? 2. Is "git merge develop" followed by "git rebase develop" the right thing to do in order to obtain a good revision history for "branch_local" before publishing it? Or would that be bad, since it would also involve rebasing "branch_public", which already is published? In that case, what should I do instead? Best regards, Simon -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
