All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Ramkumar Ramachandra <artagnon@gmail.com>
Cc: Philip Oakley <philipoakley@iee.org>, Git List <git@vger.kernel.org>
Subject: Re: What's cooking in git.git (Mar 2014, #03; Fri, 14)
Date: Mon, 17 Mar 2014 11:01:25 -0700	[thread overview]
Message-ID: <xmqq4n2wg0wa.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <CALkWK0npxgi2gWQbuYZLn_N0GxgTdPTR8c-yhgCxEV=mM2Zngw@mail.gmail.com> (Ramkumar Ramachandra's message of "Sun, 16 Mar 2014 19:15:06 -0400")

Ramkumar Ramachandra <artagnon@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.

  reply	other threads:[~2014-03-17 18:01 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-14 22:09 What's cooking in git.git (Mar 2014, #03; Fri, 14) Junio C Hamano
2014-03-15  8:15 ` Torsten Bögershausen
2014-03-17 17:01   ` Junio C Hamano
2014-03-19 10:53     ` Max Horn
2014-03-19 12:32       ` Max Horn
2014-03-19 17:04       ` Junio C Hamano
2014-03-19 17:21         ` Max Horn
2014-03-19 18:53           ` Junio C Hamano
2014-03-15 12:34 ` Duy Nguyen
2014-03-17 18:05   ` Junio C Hamano
2014-03-16 18:30 ` Philip Oakley
2014-03-16 23:15   ` Ramkumar Ramachandra
2014-03-17 18:01     ` Junio C Hamano [this message]
2014-03-17 22:41     ` Philip Oakley
2014-03-17 17:21   ` Junio C Hamano
2014-03-18  0:16     ` Philip Oakley
2014-03-18  4:40   ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqq4n2wg0wa.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=artagnon@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=philipoakley@iee.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.