Re: [PATCH v2 1/2] status: refactor output format to represent "default"
- From
Jeff King <peff@peff.net>
- Date
- Oct 18, 2012, 02:03 UTC
- Message-ID
- <20121018020308.GA24484@sigill.intra.peff.net>
- In-Reply-To
- <1350525480-30395-1-git-send-email-pclouds@gmail.com>
On Thu, Oct 18, 2012 at 08:57:59AM +0700, Nguyen Thai Ngoc Duy wrote:
Show 30 quoted lines
> From: Jeff King <peff@peff.net> > > When deciding which output format to use, we default an > internal enum to STATUS_FORMAT_LONG and modify it if > "--porcelain" or "--short" is given. If this enum is set to > LONG, then we know the user has not specified any format, > and we can kick in default behaviors. This works because > there is no "--long" which they could use to explicitly > specify LONG. > > Let's expand the enum to have an explicit STATUS_FORMAT_NONE, > in preparation for adding "--long". Then we can distinguish > between LONG and NONE when setting other defaults. There are > two such cases: > > 1. The user has asked for NUL termination. With NONE, we > currently default to turning on the porcelain mode. > With an explicit --long, we would in theory use NUL > termination with the long mode, but it does not support > it. So we can just complain and die. > > 2. When an output format is given to "git commit", we > default to "--dry-run". This behavior would now kick in > when "--long" is given, too. > > Signed-off-by: Jeff King <peff@peff.net> > Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> > --- > Two die()s with --long are moved to the next patch where --long is > introduced.
I think that is fine to split it like this, but you would want to update the commit message above. Probably just remove those two cases and say something like:
Note that you cannot actually trigger STATUS_FORMAT_LONG, as we do not yet have "--long"; that will come in a follow-on patch.
And then move the reasoning for how "--long" works with each case into the commit message of the next patch.
Other than that, the patches look OK to me.
-Peff