Hi John, Björn and Eric, Thank you very much for your replies from which I gained a lot insight about git merging and different workflows. Yes, I have tried out --no-ff and it does the job for me. (Incidentally, doing that take it look neater in git gui as all the master nodes appear on top of each other. Using empty commits, the merged branches appear on top the master nodes in the graph.) Jonathan Nieder-2 wrote: > > Then your response pushed me towards the question of whether --no-ff is a > good idea in general > John, I get the feeling from what you say in general that fast forwards are default behaviour for merges for a reason and by using the --no-ff option I am making my workflow and git history uncessesarily awkward and working against best practices? Jonathan Nieder-2 wrote: > >> I guess Richard took the "branch topic1, merge topic1, branch topic2, >> merge topic2" thing just as an example because that ends up with two >> fast-forwards. > > Hmm, I found Richard’s example pretty realistic. I used to work like > that, and I don’t think I am the only one. > I'm not saying there is any one "right" workflow. But is there a more suitable workflow than than "branch topic1, merge topic1, branch topic2, merge topic2"? Thanks, Richard -- View this message in context: http://n2.nabble.com/Preserving-branches-after-merging-on-ancestor-tp3954131p3959325.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html