Re: Preserving branches after merging on ancestor

[rhlee <richard@webdezign.co.uk>]

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.