git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Raman Gupta <rocketraman@fastmail.fm>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 2/2] Add feature release instructions to gitworkflows man page
Date: Mon, 30 Mar 2009 11:14:43 -0700	[thread overview]
Message-ID: <7vljqmdgj0.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <49D10875.2060008@fastmail.fm> (Raman Gupta's message of "Mon, 30 Mar 2009 13:59:17 -0400")

Raman Gupta <rocketraman@fastmail.fm> writes:

> Junio C Hamano wrote:
> ...
> If you wish to remove discussion of 'next' from this document, that is
> probably better done in a separate followup change. Though personally
> I think its a useful concept for readers to learn about as they are
> setting up their own workflows.

I do not have a particularly strong feeling about 'next' either way.

As the document states at the top, it lists ingredients from git.git
management and it is left up to the readers to adopt parts that suit their
needs, while not using others.  In that spirit, the description of 'next'
as "ahead of master that is supposed to be rock solid" may be a good thing
to keep.  It is orthogonal if the project wants to rewind and rebuild
'next' after every feature release---they do not need to (and we didn't do
so for quite some time).  One valid choice by readers is to adopt the
concept of 'next' in their project but never rewind and rebuild it, and
you made that clear that it is optional.  So I think this part of your
patch is good as-is.

>> Other parts (except for the "branch -f" bit I've already told you
>> about in the other message) looked good.
>
> I'll add some discussion about the branch -f bit -- I hope you agree
> that in this document that is distributed with git, some
> beginner-level explanation of the difference between the branch -f and
> the merge approach is warranted?

Surely and thanks.

  reply	other threads:[~2009-03-30 18:16 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-30  5:35 [PATCH 1/2] Add feature release instructions to MaintNotes addendum rocketraman
2009-03-30  5:35 ` [PATCH 2/2] Add feature release instructions to gitworkflows man page rocketraman
2009-03-30  6:57   ` Junio C Hamano
2009-03-30 17:59     ` Raman Gupta
2009-03-30 18:14       ` Junio C Hamano [this message]
2009-03-30 18:40         ` Raman Gupta
2009-04-01 16:15           ` Junio C Hamano
2009-03-30  6:56 ` [PATCH 1/2] Add feature release instructions to MaintNotes addendum Junio C Hamano
2009-03-30 17:57   ` Raman Gupta
  -- strict thread matches above, loose matches on Subject: below --
2009-03-26  1:56 rocketraman
2009-03-26  1:56 ` [PATCH 2/2] Add feature release instructions to gitworkflows man page rocketraman
2009-03-26  6:48   ` Junio C Hamano
2009-03-26 14:35     ` Raman Gupta

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=7vljqmdgj0.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=rocketraman@fastmail.fm \
    /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 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 NNTP newsgroup(s).