From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Andreas Heiduk <asheiduk@gmail.com>, git@vger.kernel.org
Subject: Re: [PATCH 1/2] add setup step to filter-branch
Date: Fri, 09 Jun 2017 22:11:40 +0900 [thread overview]
Message-ID: <xmqqo9tx71bn.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <20170609054955.y52cro2c3bwhl2sh@sigill.intra.peff.net> (Jeff King's message of "Fri, 9 Jun 2017 01:49:55 -0400")
Jeff King <peff@peff.net> writes:
> I have a feeling that if we were ever to rewrite filter-branch, it would
> probably be worth allowing people to write snippets in a better language
> (possibly even a domain-specific language). I'm sure that most of the
> program being written in shell doesn't help, but if we're spawning one
> or more shell instances per commit (plus the Git programs they spawn!),
> it's always going to be slow.
>
> But I suspect that would be an uphill battle, as our only stable API
> involves starting external processes anyway. You'd probably do better to
> pick a language you like and rewrite it in using libgit2's bindings to
> that language. It's not feature complete, but basic stuff like "put this
> entry in the tree" is certainly mature.
>
>> *1* The issue is *not* that these individual filter commands expect
>> <command> written as a shell scriptlet; it is that these
>> scriptlets expect to be evaled inside a single shell process,
>> making an update to a shell variable in one command visible to
>> the next command that runs.
>
> I think you'd need a shell "helper" that's a single long-running process
> and just reads "eval the index snippet now" instructions from the C
> controller. At which point I don't think Andreas's "setup" feature is
> any harder to support. We just send an "eval the setup snippet"
> instruction first.
Yes. I do not think this particular one makes things any worse than
it already is. As I said, I do not have a strong opinion against
the topic; as long as people find the feature useful, I do not mind
applying it.
Thanks.
next prev parent reply other threads:[~2017-06-09 13:11 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-03 10:17 [PATCH 1/2] add setup step to filter-branch Andreas Heiduk
2017-06-03 10:17 ` [PATCH 2/2] add [--] to usage of filter-branch Andreas Heiduk
2017-06-05 8:51 ` Andreas Heiduk
2017-06-09 13:14 ` Junio C Hamano
2017-06-09 14:33 ` Andreas Heiduk
2017-06-05 2:15 ` [PATCH 1/2] add setup step to filter-branch Junio C Hamano
2017-06-09 5:49 ` Jeff King
2017-06-09 13:11 ` Junio C Hamano [this message]
2017-06-10 8:54 ` [PATCH v2 " Andreas Heiduk
2017-06-10 8:54 ` [PATCH v2 2/2] add [--] to usage of filter-branch Andreas Heiduk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqo9tx71bn.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=asheiduk@gmail.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.