On Thu, 1 May 2014 07:00:03 -0300 Dalai Felinto <[email protected]> wrote:
> Hi all, > > I have a public branch (bake-cycles in git.blender.org) that started from a > local branch, where I was using rebase from master all the time, but moved > to upstream, where I've been doing merges from master often. > > Now that the time to merge back to master is coming close, I want to squash > most of my old commits in logical blocks. The problem is, although when I > was working locally my commits were all nicely stacked together (due to > rebase), they are now scattered all over the git log (due to merge). > > Is there an automatic way to convert a "merge branch" into a "rebase > branch"? Once I had a "rebase branch" it would be much easier for me to do > some rebase -i for squashing and re-order commits for the final merge. > > Otherwise I will have to resort to splitting the commits based on the > files, which is not ideal in my case. > Rebasing a public branch is discouraged in git, as people who pulled already from that branch may see duplicated commits (the rebase operation creates "new" commits with the same contents, in fact the hashes change). You can always create a new local branch from the public branch (e.g. bake-cycles-final) and rebase that one and publish it when you are ready. This is the generic way, I don't know the details about the blender workflow, sorry. Ciao, Antonio -- Antonio Ospite http://ao2.it A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
