[PATCH 0/3] cleaner bit-setting in cmd_push

From: Jeff King <peff@peff.net>
Date: Feb 16, 2015, 06:10 UTC
Message-ID: <20150216061051.GA29895@peff.net>
In-Reply-To: <CAPc5daU6VOmuNp3VbYgoFDXJshkC2AnRsZQQdoRMArYpezZr=A@mail.gmail.com>

On Sun, Feb 15, 2015 at 10:02:08PM -0800, Junio C Hamano wrote:

Show 15 quoted lines

> On Sun, Feb 15, 2015 at 9:54 PM, Jeff King <peff@peff.net> wrote:
> >
> > Or alternatively, we could pull the "flags" field from cmd_push out into
> > a static global "transport_flags", and manipulate it directly from the
> > config (or if we don't like a global, pass it via the config-callback
> > void pointer; but certainly a global is more common in git for code like
> > this). Then we do not have to worry about propagating values from
> > integers into flag bits at all.
> 
> Yup, that would be my preference. The largest problem I had with the
> original change was how to ensure that future new code would not
> mistakenly set the global follow_tags _without_ letting the command
> line option parser to override it. If the config parser flips the bit in the
> same flags, it would become much less likely for future code to make
> such a mistake.

So here's my take on it (on top of the two-patch series I just sent). Dave's patch is 3rd here, just to show its rebased form, but do not take that as a final endorsement. I still think it could use tests, but I will let him write them. I am just doing the cleanup in the area, none of which needs to be his problem. :)

  [1/3]: cmd_push: set "atomic" bit directly
  [2/3]: cmd_push: pass "flags" pointer to config callback
  [3/3]: push: allow --follow-tags to be set by config push.followTags

-Peff