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
