On Sun, Feb 15, 2015 at 10:02:08PM -0800, Junio C Hamano wrote: > On Sun, Feb 15, 2015 at 9:54 PM, Jeff King <peff@xxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html