Re: [PATCH v2 2/4] git-send-email: refactor duplicate $? checks into a function
- From
Emily Shaffer <emilyshaffer@google.com>
- Date
- May 3, 2021, 20:30 UTC
- Message-ID
- <YJBdbi50Hz+ekOtt@google.com>
- In-Reply-To
- <xmqqblaopbep.fsf@gitster.g>
On Thu, Apr 08, 2021 at 05:08:30PM -0700, Junio C Hamano wrote:
Show 29 quoted lines
> > Ævar Arnfjörð Bjarmason <avarab@gmail.com> 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@evledraar.gmail.com/ > > 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