git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Ilya Bobyr <ilya.bobyr@gmail.com>
Cc: git@vger.kernel.org, Jeff King <peff@peff.net>,
	Jonathan Nieder <jrnieder@gmail.com>
Subject: Re: [PATCH] rev-parse --parseopt: option argument name hints
Date: Wed, 12 Mar 2014 09:59:05 -0700	[thread overview]
Message-ID: <xmqq38innyjq.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <53200C1A.7070002@gmail.com> (Ilya Bobyr's message of "Wed, 12 Mar 2014 00:26:18 -0700")

Ilya Bobyr <ilya.bobyr@gmail.com> writes:

> I though that an example just to describe `argh' while useful would
> look a bit disproportional, compared to the amount of text on
> --parseopt.
>
> But now that I've added a "Usage text" section to looks quite in place.

Good thinking.

> I was also wondering about the possible next step(s).  If you like
> the patch will you just take it from the maillist and it would
> appear in the next "What's cooking in git.git"?  Or the process is
> different?

It goes more like this:

 - A topic that is in a good enough shape to be discussed and moved
   forward is given its own topic branch and then merged to 'pu', so
   that we do not forget.  The topic enters "What's cooking" at this
   stage.

 - Discussion on the topic continues on the list, and the topic can
   be replaced or built upon while it is still on 'pu' to polish it
   further.

   . We may see a grave issue with the change and may discard it
     from 'pu'.  

   . We may see a period of inaction after issues are pointed out
     and/or improvements are suggested, which would cause the topic
     marked as stalled; this may cause it to be eventually discarded
     as "abandoned" if nobody cares deeply enough.

 - After a while, when it seems that we, collectively as the Git
   development circle, agree that we would eventually want that
   change in a released version in some future (not necessarily in
   the upcoming release), the topic is merged to 'next', which is
   the branch Git developers are expected to run in their daily
   lives.

    . We may see some updates that builds on the patches merged to
      'next' so far to fix late issues discovered.

    . We may see a grave issue with the change and may have to
      revert & discard it from 'next'.

 - After a while, when the topic proves to be solid, it is merged to
   'master', in preparation for the upcoming release.

  reply	other threads:[~2014-03-12 16:59 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-03 10:32 [PATCH] rev-parse --parseopt: option argument name hints Ilya Bobyr
2014-03-04 19:22 ` Junio C Hamano
2014-03-10  5:47   ` Ilya Bobyr
2014-03-10  5:55     ` [PATCH v2] " Ilya Bobyr
2014-03-10 19:55     ` [PATCH] " Junio C Hamano
2014-03-11 19:10       ` Junio C Hamano
2014-03-12  7:26         ` Ilya Bobyr
2014-03-12 16:59           ` Junio C Hamano [this message]
2014-03-19  9:02             ` Ilya Bobyr
2014-03-19 18:46               ` Junio C Hamano
2014-03-20  8:38                 ` Ilya Bobyr
2014-03-20  8:44                   ` [PATCH v3] " Ilya Bobyr
2014-03-20 18:38                     ` Junio C Hamano
2014-03-20 23:19                       ` Ilya Bobyr
2014-03-21  7:55                         ` Ilya Bobyr
2014-03-21 17:04                         ` Junio C Hamano
2014-03-22  9:47                           ` [PATCH v4] " Ilya Bobyr
2014-03-24 17:52                             ` [PATCH 0/3] Parse-options: spell multi-word placeholders with dashes Junio C Hamano
2014-03-24 17:52                               ` [PATCH 1/3] parse-options: multi-word argh should use dash to separate words Junio C Hamano
2014-03-24 17:52                               ` [PATCH 2/3] update-index: teach --cacheinfo a new syntax "mode,sha1,path" Junio C Hamano
2014-03-24 17:52                               ` [PATCH 3/3] parse-options: make sure argh string does not have SP or _ Junio C Hamano
2014-03-20 20:18                     ` [PATCH v3] rev-parse --parseopt: option argument name hints Eric Sunshine
2014-03-21  3:38                       ` Ilya Bobyr

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=xmqq38innyjq.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=ilya.bobyr@gmail.com \
    --cc=jrnieder@gmail.com \
    --cc=peff@peff.net \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).