Ramkumar Ramachandra <artag...@gmail.com> writes: > ... I'd first fix the main issue: stale content. I'm not sure > who uses git show-branch or mailx anymore, for instance.
Unfortunately, I haven't seen a representation better than what show-branch gives me when assessing what needs to happen during rebases of multiple topics some of which depend on other topics. "git log --oneline --graph" is *not* it, with too much clutter. I do not think "stale" is the issue. Common-ness may be an issue, as the usage of Git surely does not have to involve show-branch for a simple workflow, e.g. a beginning standalone developer's. The show-branch (and mailx) example are headed by "My typical Git day" in the "Integrator" section (emphasis on "My"---it was not meant to be "You ought to do like I do because I know this is the best current practice" back when it was written, as none of us had enough experience to declare what the BCP was). You may argue the command set shown there may be specific to "My" usage, and it is atypical for the "Integrator" workflow. We could try to come up with a different/better workflows for each classes of developers to replace that "examples" sections, and that will be the first step to update the listed set of commands for each classes, I would think. You need to realize that the workflow described in the examples section is a real, battle tested one, not something that came out of thin air, though. The way forward would be to think about the following things, in the order listed here: (1) Review the classes of developers. Is the classification we have in the document still good? Do we need to add new classes of developers? Do we need to collapse some into one? (2) For each class of developers, review the workflow illustrated in the "Examples": . Do the steps illustrate a typical flow of activities for the class of developers? Are there steps that typically happens during a developer's day that are missing in the flow? Are some of the steps in the example unnecessary? . Have we made improvements to various Porcelain commands since the document was written? Do we have better ways to achieve some steps illustrated there? (3) For each class of developers, review the commands listed before the "Examples" section and adjust to the "Examples" updated in the second step. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html