On Mon, Oct 9, 2023 at 7:44 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > 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. I completely agree with you. The #1 conversation I have with friends who are new to Git is figuring out which of the major workflows they should use, and what are the drawbacks and benefits. And how to diagnose based on the existing commit history, review tool in use, etc which one is used by their peers. Having this documented somewhere - maybe in Pro Git book, maybe in manpage - would be hugely useful. I could envision a diagram of a sample commit history, and "if it already looks like this or you want it to look like this, your workflow should be blah" and finally a list of some drawbacks, benefits, and warnings about what to avoid in that workflow. Plus, perhaps, many shout-outs to `git reflog` for fixing when you misunderstood and made a mess. (that's the #2 conversation I have :) ) > 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.
