Re: [PATCH v2 2/4] git-send-email: refactor duplicate $? checks into a function

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Apr 08, 2021 at 05:08:30PM -0700, Junio C Hamano wrote:
> 
> Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:
> 
> > On Fri, Apr 09 2021, Junio C Hamano wrote:
> > ...
> >> What's the status of that topic, if there weren't other topics in
> >> flight that interfere with it, by the way?  Is it otherwise a good
> >> enough shape to be given priority and stable enough to get other
> >> topics rebased on top of it?
> >
> > I see I've mentioned [1] in passing to you before, but in summary I have
> > some major qualms about parts of it, but very much like the overall
> > direction/goal of having hooks in config.
> >
> > Elevator pitch summary of the lengthy [1]: hooks in config: good, but
> > having a "git hook" command introduce some nascent UI for managing a
> > subset of git-config: somewhere between "meh" / "bad idea" (see security
> > concerns in [1]) / "not needed". I.e. I demonstrated that we can replace
> > it with a trivial git-config wrapper, if the series doesn't go out of
> > its way to make it difficult (i.e. we can/should stick all config for a
> > given hook in the same <prefix>, and not re-invent the
> > "sendemail.identity" special-case).
> >
> > I'd very much like the author to respond to that :) And/or for others to
> > chime in with what they think.
> >
> > 1. https://lore.kernel.org/git/87mtv8fww3.fsf@xxxxxxxxxxxxxxxxxxx/
> 
> OK, Emily, I guess the ball is in your court now?

The topic is not ready for submission besides interference. I have a
list of things to do and was sidetracked with other work (the submodule
RFC, etc.). This week I am working on getting this series polished and
ready to go.

 - Emily



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux