Elijah Newren <newren@xxxxxxxxx> writes: >> [Footnote] >> ... > > Thanks for writing this up. In the past, I didn't know how to put > into words why I didn't particularly care for this mode. You explain > it rather well. I am glad it helped non-zero number of people. It probably owes big to my failing, but because we strongly view it a virtue not to be opinionated, we have many discrete tools and features that can be used in combination to support a workflow well, even when some of these tools and features are not useful for a different workflow. It indeed is a good thing to be flexible and to support different workflows well, and we tend not to single out a workflow among many and advocate it, but because our documentation lacks description of major possible workflows, what their underlying philosophies and their strengths are, how some of our tools and features support them, and why some others are not good fit. Being given a toolbox with too many tools without being taught how they are to be used together and for what purpose may be a fun puzzle to figure out for tinkerers, but when you have a problem to solve and tinkering is not your main focus, which is true for most people, it is not fun. In short, in pursuit of not to be opinionated, we fail to give the readers best current practices. The first place to start rectifying it might be to have some write-ups for various major workflows and the worldview behind them. The importance given to first-parenthood offers two quite different worldviews that affects the choice of tools (e.g. "merge --no-ff", "checkout origin/master && merge mine && branch -f mine" aka "reverse merge"). I suspect that this also relates to your "would --cc be totally unnecessary now we have --remerge-diff?" as well. What kind of conflicts are interesting highly depends on what you are looking for, which in turn is influenced by the workflow employed by the project and what role you are playing in it.
