Re: [RFC 0/5] Date Mode: Add --time-zone; deprecate --date=local

From: Michael Witten <mfwitten@gmail.com>
Date: Apr 20, 2011, 14:22 UTC
Message-ID: <7963bbbe-9b85-492c-ad10-24a80e4eb1b8-mfwitten@gmail.com>
In-Reply-To: <20110420064318.GF28597@sigill.intra.peff.net>

On Wed, 20 Apr 2011 02:43:18 -0400, Jeff King wrote:

Show 11 quoted lines

> On Wed, Apr 20, 2011 at 02:53:36AM +0000, Michael Witten wrote:
>
>> These patches apply cleanly to the current tip of Junio's `next' branch:
>
> Why not "master"? Usually we try to develop features independently on
> top of master, and then merge them. That way topics can graduate
> independently to master, and it is easier to see which topics are
> responsible for breakages. If you really need something in another topic
> (because you are directly building on it, or the merge would just be too
> painful), then build straight on that topic's commits, not on top of
> next (and of course tell everyone which topic it's built on).

Interesting points.

I was building on `master', but I figured I would expedite the testing of my patch by making sure that it applies to the recent tip of `next' without trouble.

In fact, when I did rebase onto `next', there were a couple of minor conflicts that I had to resolve, so I can safely say that the current patch series depends upon the following 2 topics:

  commit 84393bfd731c435120dc1dda63432a70124821cb
  Author: Namhyung Kim <namhyung@gmail.com>
  Date:   Wed Apr 6 11:20:50 2011 +0900

      blame: add --abbrev command line option and make it honor core.abbrev
      
      If user sets config.abbrev option, use it as if --abbrev was given.  This
      is the default value and user can override different abbrev length by
      specifying the --abbrev=N command line option.
      
      Signed-off-by: Namhyung Kim <namhyung@gmail.com>
      Signed-off-by: Junio C Hamano <gitster@pobox.com>

  commit ef803fd4b09bca707c7c27669a2789bb050b488c
  Author: Michael J Gruber <git@drmicha.warpmail.net>
  Date:   Fri Apr 1 11:20:31 2011 +0200

      builtin/log.c: separate default and setup of cmd_log_init()
      
      cmd_log_init() sets up some default rev options and then calls
      setup_revisions(), so that a caller cannot set up own defaults: Either
      they get overriden by cmd_log_init() (if set before) or they override
      the command line (if set after). We even complain about this in a
      comment to cmd_log_reflog().
      
      Therefore, separate the two steps so that one can still call
      cmd_log_init() or, alternatively, cmd_log_init_defaults() followed by
      cmd_log_init_finish() (and set defaults in between).
      
      No functional change so far.
      
      Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
      Signed-off-by: Junio C Hamano <gitster@pobox.com>

Those look likely to go into master, so it actually seems like a good idea to have gone ahead and taken care of the conflict. However, in the future, I will send patches to `master' only.