* Re: [RFC PATCH 1/2] grep: fallback to interpreter if JIT fails with pcre1
From: Junio C Hamano @ 2018-12-10 6:42 UTC (permalink / raw)
To: brian m. carlson
Cc: Ævar Arnfjörð Bjarmason,
Carlo Marcelo Arenas Belón, git, pcre-dev
In-Reply-To: <20181210004252.GK890086@genre.crustytoothpaste.net>
"brian m. carlson" <sandals@crustytoothpaste.net> writes:
> Considering that some Linux users use PaX kernels with standard
> distributions and that most BSD kernels can be custom-compiled with a
> variety of options enabled or disabled, I think this is something we
> should detect dynamically.
> ...
> My view is that JIT is a nice performance optimization, but it's
> optional. I honestly don't think it should even be exposed through the
> API: if it works, then things are faster, and if it doesn't, then
> they're not. I don't see the value in an option for causing things to be
> broken if someone improves the security of the system.
I agree to both of these two points. Thanks for a thoughtful
discussion, all.
^ permalink raw reply
* Re: [RFC PATCH 1/2] grep: fallback to interpreter if JIT fails with pcre1
From: Junio C Hamano @ 2018-12-10 6:48 UTC (permalink / raw)
To: Carlo Marcelo Arenas Belón; +Cc: git, avarab
In-Reply-To: <20181209230024.43444-2-carenas@gmail.com>
Carlo Marcelo Arenas Belón <carenas@gmail.com> writes:
> JIT support was added to 8.20 but the interface we rely on is only
> enabled after 8.32 so try to make the message clearer.
Could you add some word before 8.20 and 8.32 (e.g. "pcre library
version 8.20", if that is what you are referring to, and if 8.32 is
also taken from the same context, adding such phrase to clarify the
context only to 8.20 is sufficient)?
> in systems where there are restrictions against creating executable
> pages programatically (like OpenBSD, NetBSD, macOS or seLinux) JIT
> will fail, resulting in a error message to the user.
>
> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com>
> ---
The change to the code looked sensible.
^ permalink raw reply
* Re: [RFC PATCH 1/2] grep: fallback to interpreter if JIT fails with pcre1
From: Junio C Hamano @ 2018-12-10 6:54 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: Carlo Marcelo Arenas Belón, git, pcre-dev
In-Reply-To: <87r2eqxnru.fsf@evledraar.gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>> @@ -32,14 +32,14 @@ all::
>> # USE_LIBPCRE is a synonym for USE_LIBPCRE2, define USE_LIBPCRE1
>> # instead if you'd like to use the legacy version 1 of the PCRE
>> # library. Support for version 1 will likely be removed in some future
>> -# release of Git, as upstream has all but abandoned it.
>> +# release of Git, as upstream is focusing all development for new
>> +# features in the newer version instead.
>
> I think whatever we do here it makes sense to split this into its own
> patch, since it doesn't have to do with this fallback mechanism.
>
> FWIW I was trying to word this in some way that very briefly described
> the v1 v.s. v2 situation. Just saying "new features" doesn't quite
> capture it, e.g. some bugs in v1 are closed with some resolution like
> "this isn't trivial to fix, use v2 instead".
I actually think we should remove the paragraph that says "Support
for version 1 will likely to be removed...", as I do not see how it
helps the users. If they have both available, on the day they hear
that we are planning to remove pcre1 support and realize that they
need to plan to upgrade to the first version of Git that drops pcre1
support, they can switch to pcre2 just fine, so telling them about
our future that we do not even know definite plan yet does not help
them. It is quite unlikely, given that "upstream has all but
abandoned it", that there only is pcre1 support without pcre2 for an
obscure platform, and even if there are such platforms, the users on
them won't have much choice. Discouraging them from using pcre1
would not help them make better choices anyway.
^ permalink raw reply
* Re: [RFC PATCH 2/2] grep: fallback to interpreter if JIT fails with pcre2
From: Junio C Hamano @ 2018-12-10 7:00 UTC (permalink / raw)
To: Carlo Marcelo Arenas Belón; +Cc: git, avarab
In-Reply-To: <20181209230024.43444-3-carenas@gmail.com>
Carlo Marcelo Arenas Belón <carenas@gmail.com> writes:
> starting with 10.23, and as a side effect of the work for bug1749[1] (grep
> -P crash with seLinux), pcre2grep was modified to ignore any errors from
> pcre2_jit_compile so the interpreter could be used as a fallback
That may (or may not---I do not know and I do not particularly feel
the need to know or care about pcre2grep that is somebody else's
project) describe what happened in the pcre2grep project, but it
solicits a "so what?" response without the rest of the sentence you
omitted.
I am guessing that the missing end of the sentence is "we should
follow suit because ...", i.e. something like
Starting from 10.23 [of what??? pcre2grep's version, libpcre's
version, or something else???], pcre2grep falls back to
interpreted pcre when JIT compilation fails. We should follow
suit in "git grep", because ...
> [1] https://bugs.exim.org/show_bug.cgi?id=1749
>
> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com>
> ---
> grep.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/grep.c b/grep.c
> index 5ccc0421a1..c751c8cc74 100644
> --- a/grep.c
> +++ b/grep.c
> @@ -530,8 +530,11 @@ static void compile_pcre2_pattern(struct grep_pat *p, const struct grep_opt *opt
> pcre2_config(PCRE2_CONFIG_JIT, &p->pcre2_jit_on);
> if (p->pcre2_jit_on == 1) {
> jitret = pcre2_jit_compile(p->pcre2_pattern, PCRE2_JIT_COMPLETE);
> - if (jitret)
> - die("Couldn't JIT the PCRE2 pattern '%s', got '%d'\n", p->pattern, jitret);
> + if (jitret) {
> + /* JIT failed so fallback to the interpreter */
> + p->pcre2_jit_on = 0;
> + return;
> + }
>
> /*
> * The pcre2_config(PCRE2_CONFIG_JIT, ...) call just
^ permalink raw reply
* Re: [RFC PATCH 1/2] grep: fallback to interpreter if JIT fails with pcre1
From: Ævar Arnfjörð Bjarmason @ 2018-12-10 8:24 UTC (permalink / raw)
To: brian m. carlson; +Cc: Carlo Marcelo Arenas Belón, git, pcre-dev
In-Reply-To: <20181210004252.GK890086@genre.crustytoothpaste.net>
On Mon, Dec 10 2018, brian m. carlson wrote:
> On Mon, Dec 10, 2018 at 12:51:01AM +0100, Ævar Arnfjörð Bjarmason wrote:
>> Obviously this & what you have in 2/2 needs to be fixed in some way.
>>
>> Is the issue on SELinux, OpenBSD, NetBSD etc. *how* PCRE is creating the
>> the JIT'd code? I.e. presumably Google Chrome's JIT engine, Java JIT and
>> the like work on those setup, or not? I.e. is this something upstream
>> can/is likely to fix eventually?
>
> From the cover letter (but without testing), it seems like it would
> probably be fine to first map the pages read-write to write the code and
> then, once that's done, to map them read-executable. I know JIT
> compilation does work on the BSDs, so presumably that's the technique to
> make it do so.
>
> Both versions of PCRE map pages both write and executable at the same
> time, which is presumably where things go wrong. I assume it can be
> fixed, but whether that's easy in the context of PCRE, I wouldn't know.
>
>> Are we mixing a condition where one some OS's or OS versions this just
>> won't work at all, and thus maybe should be something turned on in
>> config.mak.uname, v.s. e.g. SELinux where presumably it'll dynamically
>> change.
>
> Considering that some Linux users use PaX kernels with standard
> distributions and that most BSD kernels can be custom-compiled with a
> variety of options enabled or disabled, I think this is something we
> should detect dynamically.
Right. I'm asking whether we're mixing up cases where it can always be
detected at compile-time on some systems v.s. cases where it'll
potentially change at runtime.
>> I'm inclined to suggest that we should have another ifdef here for "if
>> JIT fails I'd like it to die", so that e.g. packages I build (for
>> internal use) don't silently slow down in the future, only for me to
>> find some months later that someone enabled an overzealous SELinux
>> policy and we swept this under the rug.
>
> My view is that JIT is a nice performance optimization, but it's
> optional. I honestly don't think it should even be exposed through the
> API: if it works, then things are faster, and if it doesn't, then
> they're not. I don't see the value in an option for causing things to be
> broken if someone improves the security of the system.
For many users that's definitely the case, but for others that's like
saying a RDBMS is still going to be functional if the "ORDER BY"
function degrades to bubblesort. The JIT improves performance my
multi-hundred percents sometimes, so some users (e.g. me) rely on that
not being silently degraded.
So I'm wondering if we can have something like:
if (!jit)
if (must_have_jit)
BUG(...); // Like currently
else
fallback(); // new behavior
^ permalink raw reply
* Re: [PATCH] rebase docs: drop stray word in merge command description
From: Johannes Schindelin @ 2018-12-10 8:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Kyle Meyer, git
In-Reply-To: <xmqqk1ki2h32.fsf@gitster-ct.c.googlers.com>
Hi Junio,
On Mon, 10 Dec 2018, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Hi Kyle,
> >
> > On Sat, 8 Dec 2018, Kyle Meyer wrote:
> >
> >> Delete a misplaced word introduced by caafecfcf1 (rebase
> >> --rebase-merges: adjust man page for octopus support, 2018-03-09).
> >>
> >> Signed-off-by: Kyle Meyer <kyle@kyleam.com>
> >
> > ACK.
>
> Thanks.
>
> > Too bad this did not make it into v2.20.0, but at least it can make it
> > into a future version.
>
> The right way to fix it is to prepare a topic that can be merged
> down to the 2.19.x track, and proceed normally to percolate it down
> via 'next', 'master' and 'maint' as any other fixes. That is
> already happening.
>
> The original documentation bug is older than where the 2.20 track
> forked; the bug is in 2.19. Any such old bugs, users have survived
> without it being fixed for a cycle already, and the fix is not that
> urgent to interrupt the release engineering that is already underway
> and redo it.
>
> A regression that appears only in -rc and a known bug in a new
> feature that appears only in -rc are different matters. It is
> prudent to always first access how serious they are and we must be
> prepared to even delay the final as necessary. But I do not think
> this one is.
You are right, of course, this was not as critical a bug fix as others you
integrated last minute.
Thanks,
Dscho
^ permalink raw reply
* Re: [PATCH v3 1/1] git clone <url> C:\cygwin\home\USER\repo' is working (again)
From: Johannes Schindelin @ 2018-12-10 8:32 UTC (permalink / raw)
To: Torsten Bögershausen; +Cc: git, svnpenn
In-Reply-To: <20181208151109.2097-1-tboegi@web.de>
Hi Torsten,
On Sat, 8 Dec 2018, tboegi@web.de wrote:
> And, before any cleanup is done, I sould like to ask if anybody
> can build the code with VS and confirm that it works, please ?
Can you give me an easy-to-fetch branch?
Thanks,
Dscho
^ permalink raw reply
* Re: [PATCH] mailmap: update brandon williams's email address
From: Johannes Schindelin @ 2018-12-10 8:36 UTC (permalink / raw)
To: Brandon Williams; +Cc: gitster, sbeller, jrnieder, git
In-Reply-To: <CALN-EhSQZiOsXwOyDJo_muTcP9HsifmqyD1oLxMunv5CfAdHgg@mail.gmail.com>
Hi,
On Fri, 7 Dec 2018, Brandon Williams wrote:
> On Fri, Dec 7, 2018 at 10:08 PM Junio C Hamano <gitster@pobox.com>
> wrote:
> >
> > Stefan Beller <sbeller@google.com> writes:
> >
> > > On Fri, Dec 7, 2018 at 1:40 PM Jonathan Nieder <jrnieder@gmail.com>
> > > wrote:
> > >>
> > >> Brandon Williams wrote:
> > >>
> > >> > Signed-off-by: Brandon Williams <bwilliams.eng@gmail.com>
> > >> > ---
> > >> > .mailmap | 1 +
> > >> > 1 file changed, 1 insertion(+)
> > >>
> > >> I can confirm that this is indeed the same person.
> > >
> > > What would be more of interest is why we'd be interested in this
> > > patch as there is no commit/patch sent by Brandon with this email in
> > > gits history.
> >
> > Once I "git am" the message that began this thread, there will be a
> > commit under this new ident, so that would be somewhat a moot point.
> >
> > If this were "Jonathan asked Brandon if we want to record an address
> > we can reach him in our .mailmap file and sent a patch to add one",
> > then the story is different, and I tend to agree with you that such a
> > patch is more or less pointless. That's not the purpose of the
> > mailmap file.
> >
>
> Turns out this is exactly the reason :) I've had a couple of people
> reach out to me asking me to do this because CCing my old email bounces
> and they've wanted my input/comments on something related to work I've
> done. If that's not the intended purpose then please ignore this patch
Unless we come up with a better way to indicate the current address of a
Git contributor (I seem to remember that David Turner used the same
approach after leaving Twitter so that people could Cc: him with the
correct address), I suggest that we keep using .mailmap for that purpose.
Thanks,
Dscho
^ permalink raw reply
* Re: [PATCH v4 2/7] pretty: allow %(trailers) options with explicit value
From: Junio C Hamano @ 2018-12-10 8:45 UTC (permalink / raw)
To: Anders Waldenborg; +Cc: git, Jeff King, Olga Telezhnaya
In-Reply-To: <20181208163647.19538-3-anders@0x63.nu>
Anders Waldenborg <anders@0x63.nu> writes:
> In addition to old %(trailers:only) it is now allowed to write
> %(trailers:only=yes)
s/$/. Similarly the unfold option can take a boolean./
> By itself this only gives (the not quite so useful) possibility to have
> users change their mind in the middle of a formatting
> string (%(trailers:only=true,only=false)). However, it gives users the
> opportunity to override defaults from future options.
Makes sense.
> +** 'unfold[=val]': make it behave as if interpret-trailer's `--unfold`
> + option was given. In same way as to for `only` it can be followed
> + by an equal sign and explicit value. E.g.,
> + `%(trailers:only,unfold=true)` unfolds and shows all trailer lines.
> +static int match_placeholder_bool_arg(const char *to_parse, const char *candidate,
> + const char **end, int *val)
> +{
> + const char *p;
> + if (!skip_prefix(to_parse, candidate, &p))
> + return 0;
> +
> + if (match_placeholder_arg(p, "=no", end) ||
> + match_placeholder_arg(p, "=off", end) ||
> + match_placeholder_arg(p, "=false", end)) {
> + *val = 0;
> + return 1;
> + }
> +
> + if (match_placeholder_arg(p, "", end) ||
> + match_placeholder_arg(p, "=yes", end) ||
> + match_placeholder_arg(p, "=on", end) ||
> + match_placeholder_arg(p, "=true", end)) {
> + *val = 1;
> + return 1;
> + }
Hmph. Is there a possibility to arrenge the code so that we do not
have to maintain these variants of true/false representations here,
when we should already have one in config.c?
The match_placeholder_arg() function is a bit too limiting as it can
only recognize the value that we know about for a thing like this.
Instead, perhaps we can cut what follows "=" syntactically, looking
for either NUL, ',', or ')', and then call git_parse_maybe_bool() on
it. That way, we can handle %(trailers:only=bogo) more sensibly,
no? Syntactically we can recognize that the user wanted to give
'bogo' as the value to 'only', and say "'bogo' is not a boolean" if
we did so.
> + return 0;
> +}
> +
^ permalink raw reply
* Re: [PATCH v2 1/3] git clone <url> C:\cygwin\home\USER\repo' is working (again)
From: Johannes Schindelin @ 2018-12-10 8:46 UTC (permalink / raw)
To: Steven Penny; +Cc: tboegi, git
In-Reply-To: <CAAXzdLVTjCVDmBik-j9B_Z_2wgSj=_6baqmjmGEGBFOsjkyOsw@mail.gmail.com>
Hi Steven,
please stop dropping me from the Cc: list. Thanks.
On Fri, 7 Dec 2018, Steven Penny wrote:
> On Fri, Dec 7, 2018 at 11:04 AM wrote:
>
> > The solution is to implement has_dos_drive_prefix(),
> > skip_dos_drive_prefix() is_dir_sep(), offset_1st_component() and
> > convert_slashes() for cygwin in the same way as it is done in 'Git for
> > Windows' in compat/mingw.[ch]
> >
> > Instead of duplicating the code, it is extracted into
> > compat/mingw-cygwin.[ch] Some need for refactoring and cleanup came up
> > in the review, they are adressed in a seperate commit.
>
> i have applied the 3 patches against current master, and my original
> test passes, so looks good to me.
>
> however like Johannes i take issue with the naming. as he said "mingw-cygwin"
> really isnt appropriate. ideally it would be "windows.h", but as that is
> conspicuously in use, something like these:
>
> - pc-windows
> - pc-win
> - win
I find all of those horrible.
> i disagree with him on using "win32" - that doesnt really make sense,
... except if you take into account that this has been our convention for,
what, almost 9 years (since 44626dc7d5 (MSVC: Windows-native
implementation for subset of Pthreads API, 2010-01-15), to be precise)? In
that case, it makes a ton of sense, and one might be tempted to ask who
the person wanting to change that thinks they are...
> as obviously you can compile 64-bit Git for Windows. if you wanted to go
> that route you would want to use something like:
>
> - windows-api
> - win-api
> - winapi
>
> further - i disagree with the "DOS" moniker being used at all. DOS is a
> defunkt operating system that i dont think Git has *ever* supported, so
> it doesnt make sense to be referring to it this way. again, a more
> approriate name would be something like "win_drive_prefix".
You may disagree all you want, but given that Torsten has been a lot more
active on this code than you have been so far, I'll go with Torsten's
taste. Which incidentally happens to match my tastes, so that's an added
bonus.
Ciao,
Johannes
^ permalink raw reply
* Re: [PATCH v4 4/7] pretty: allow showing specific trailers
From: Junio C Hamano @ 2018-12-10 8:56 UTC (permalink / raw)
To: Anders Waldenborg; +Cc: git, Jeff King, Olga Telezhnaya
In-Reply-To: <20181208163647.19538-5-anders@0x63.nu>
Anders Waldenborg <anders@0x63.nu> writes:
> -static int match_placeholder_arg(const char *to_parse, const char *candidate,
> - const char **end)
> +static int match_placeholder_arg_value(const char *to_parse, const char *candidate,
> + const char **end, const char **valuestart, size_t *valuelen)
> {
> const char *p;
>
> if (!(skip_prefix(to_parse, candidate, &p)))
> return 0;
> + if (valuestart) {
> + if (*p != '=')
> + return 0;
> + *valuestart = p + 1;
> + *valuelen = strcspn(*valuestart, ",)");
> + p = *valuestart + *valuelen;
> + }
> if (*p == ',') {
> *end = p + 1;
> return 1;
> @@ -1074,6 +1081,12 @@ static int match_placeholder_arg(const char *to_parse, const char *candidate,
> return 0;
> }
>
> +static int match_placeholder_arg(const char *to_parse, const char *candidate,
> + const char **end)
> +{
> + return match_placeholder_arg_value(to_parse, candidate, end, NULL, NULL);
> +}
> +
OK. The unified parsing of boolean value I mentioned on an earlier
step can naturally be done using martch_placeholder_arg_value(), I
think, in match_placeholder_bool_arg().
> +static int format_trailer_match_cb(const struct strbuf *key, void *ud)
> +{
> + const struct string_list *list = ud;
> + const struct string_list_item *item;
> +
> + for_each_string_list_item (item, list) {
> + if (key->len == (uintptr_t)item->util &&
> + !strncasecmp (item->string, key->buf, key->len))
Remove SP after strncasecmp.
We won't have too many elements in this string list, so O(N*M)
search like this one would be OK.
> + return 1;
> + }
> return 0;
> }
>
> @@ -1337,6 +1362,7 @@ static size_t format_commit_one(struct strbuf *sb, /* in UTF-8 */
>
> if (skip_prefix(placeholder, "(trailers", &arg)) {
> struct process_trailer_options opts = PROCESS_TRAILER_OPTIONS_INIT;
> + struct string_list filter_list = STRING_LIST_INIT_NODUP;
> size_t ret = 0;
>
> opts.no_divider = 1;
> @@ -1344,8 +1370,20 @@ static size_t format_commit_one(struct strbuf *sb, /* in UTF-8 */
> if (*arg == ':') {
> arg++;
> for (;;) {
> - if (!match_placeholder_bool_arg(arg, "only", &arg, &opts.only_trailers) &&
> - !match_placeholder_bool_arg(arg, "unfold", &arg, &opts.unfold))
> + const char *argval;
> + size_t arglen;
> +
> + if (match_placeholder_arg_value(arg, "key", &arg, &argval, &arglen)) {
> + uintptr_t len = arglen;
> + if (len && argval[len - 1] == ':')
> + len--;
> + string_list_append(&filter_list, argval)->util = (char *)len;
> +
> + opts.filter = format_trailer_match_cb;
> + opts.filter_data = &filter_list;
> + opts.only_trailers = 1;
> + } else if (!match_placeholder_bool_arg(arg, "only", &arg, &opts.only_trailers) &&
> + !match_placeholder_bool_arg(arg, "unfold", &arg, &opts.unfold))
> break;
> }
> }
> @@ -1353,6 +1391,7 @@ static size_t format_commit_one(struct strbuf *sb, /* in UTF-8 */
> format_trailers_from_commit(sb, msg + c->subject_off, &opts);
> ret = arg - placeholder + 1;
> }
> + string_list_clear (&filter_list, 0);
Remove SP after string_list_clear.
> return ret;
> }
>
^ permalink raw reply
* Re: What's cooking in git.git (Dec 2018, #01; Sun, 9)
From: Junio C Hamano @ 2018-12-10 10:26 UTC (permalink / raw)
To: Denton Liu; +Cc: git
In-Reply-To: <20181210035238.GA2104@archbookpro.localdomain>
Denton Liu <liu.denton@gmail.com> writes:
> On Mon, Dec 10, 2018 at 12:21:05PM +0900, Junio C Hamano wrote:
>
>> And the "story" is not "If you have remote.$name.url and want to
>> move its value to remote.$name.pushurl while setting the former to a
>> new value, then..." I want to know why the user gets in such a
>> situation in the first place.
> ...
> The following is the story that led to me writing the feature in the
> first place:
> ...
OK, so in essense, it is quite similar to the following,
>> .... Perhaps you originally had a R/W URL that always
>> require authentication, but now you want to use an anonymous R/O URL
>> for your fetch traffic without having to authenticate? If there is
>> a model situation to make all of these four hold, perhaps it can be
>> added somewhere to help users who would find the new feature useful
>> discover it.
i.e.
You may have started your interaction with the repository
with a single authenticated URL that can be used for both
fetching and pushing, but over time you may have become sick
of having to authenticate only to fetch. In such a case,
you can feed an unauthenticated/anonymous fetch URL to
set-url with this option, so that the authenticated URL that
you have been using for pushing becomes the pushURL, and the
new, unauthenticated/anonymous URL will be used for
fetching.
With something like that in the documentation, I think the users
won't be puzzled by a feature that is seemingly a bit too niche, I
would think.
Thanks.
^ permalink raw reply
* Re: pw/add-p-select, was Re: What's cooking in git.git (Dec 2018, #01; Sun, 9)
From: Phillip Wood @ 2018-12-10 10:42 UTC (permalink / raw)
To: Johannes Schindelin, Junio C Hamano; +Cc: git
In-Reply-To: <nycvar.QRO.7.76.6.1812092101570.43@tvgsbejvaqbjf.bet>
Hi Dscho
On 09/12/2018 20:31, Johannes Schindelin wrote:
> Hi Junio,
>
> On Sun, 9 Dec 2018, Junio C Hamano wrote:
>
>> * pw/add-p-select (2018-07-26) 4 commits
>> - add -p: optimize line selection for short hunks
>> - add -p: allow line selection to be inverted
>> - add -p: select modified lines correctly
>> - add -p: select individual hunk lines
>>
>> "git add -p" interactive interface learned to let users choose
>> individual added/removed lines to be used in the operation, instead
>> of accepting or rejecting a whole hunk.
>>
>> Will discard.
>> No further feedbacks on the topic for quite some time.
>
> That is not quite true. I did comment that this feature
Sorry I meant to reply to that comment but never got round to it.
> (which I take as
> being inspired by Git GUI's "Stage Selected Line"),
not particularly, I don't use git gui I just wanted a way to easily
stage a subset of lines without editing the hunk.
> and thought that it would be useful.
>
> I could imagine, however, that it would make sense for `git add -p` to
> imitate that feature more closely: by allowing to stage a single line and
> then presenting the current hunk (re-computed) again.
that sounds like it would be quite tedious to stage more than a couple
of lines, and it could be awkward to get it to stage modified lines
correctly (While I was writing the feature I tried git gui, I think it
is supposed to be able to stage modified lines correctly but I never
persuaded it to do it for me. I also tried gitg, tig and hg commit -i
but I couldn't get them to do modified lines either)
I'll try and re-roll in the New Year, when does the outreachy project
for converting add -i start? - it would be good to try and get this
pinned down before then.
Best Wishes
Phillip
> Ciao,
> Dscho
>
^ permalink raw reply
* Re: [PATCH] sideband: color lines with keyword only
From: Han-Wen Nienhuys @ 2018-12-10 11:03 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Stefan Beller, Junio C Hamano, git
In-Reply-To: <20181203232353.GA157301@google.com>
On Tue, Dec 4, 2018 at 12:23 AM Jonathan Nieder <jrnieder@gmail.com> wrote:
> > When bf1a11f0a1 (sideband: highlight keywords in remote sideband output,
> > 2018-08-07) was introduced, it was carefully considered which strings
> > would be highlighted. However 59a255aef0 (sideband: do not read beyond
> > the end of input, 2018-08-18) brought in a regression that the original
> > did not test for. A line containing only the keyword and nothing else
> > ("SUCCESS") should still be colored.
I had intended SUCCESS on a line of its to be highlighted too, and
some earlier versions of my patch did that, but it regressed as the
patch was reworked. The SUCCESS on a line of its own is a recent
behavior of Gerrit, and is live in Gerrit 2.16.
--
Google Germany GmbH, Erika-Mann-Strasse 33, 80636 Munich
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
^ permalink raw reply
* [Outreachy] My blog
From: Slavica Djukic @ 2018-12-10 12:40 UTC (permalink / raw)
To: git
Hi everyone,
I am one of the new Outreachy participants for Git.
I'll be working on project "Turn git add -i into built-in", with
Johannes Schindelin as mentor.
You can read my blog here: https://slavicadj.github.io/blog/.
There will be new posts every one or two weeks about my experience as
intern.
-Slavica Djukic
^ permalink raw reply
* Re: [PATCH v2 1/3] git clone <url> C:\cygwin\home\USER\repo' is working (again)
From: Steven Penny @ 2018-12-10 12:45 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <nycvar.QRO.7.76.6.1812100938140.43@tvgsbejvaqbjf.bet>
On Mon, Dec 10, 2018 at 2:46 AM Johannes Schindelin wrote:
> please stop dropping me from the Cc: list. Thanks.
i dropped you specifically because i knew you were going to flame like you just
did below. oh well, i guess you cant avoid the inevitable.
> > - pc-windows
> > - pc-win
> > - win
>
> I find all of those horrible.
they arent great, but "win32" simply isnt valid. as soon as we started compiling
for 64-bit and using 64-bit APIs it didnt make sense to keep using it. if you
want to refer to all versions of the Microsoft OS you say "Windows", not
"Windows XP", as that would be confusing for people using Windows 10. In the
same vein you shouldnt refer to the current Windows API as "Win32" because its
no longer just 32-bit.
> ... except if you take into account that this has been our convention for,
> what, almost 9 years (since 44626dc7d5 (MSVC: Windows-native
> implementation for subset of Pthreads API, 2010-01-15), to be precise)? In
> that case, it makes a ton of sense, and one might be tempted to ask who
> the person wanting to change that thinks they are...
"That's the way it's always been done" is not a good reason to keep doing
something. I would say the justification goes the other way, as to why we should
keep using an old moniker when its past making sense.
> You may disagree all you want, but given that Torsten has been a lot more
> active on this code than you have been so far, I'll go with Torsten's
> taste. Which incidentally happens to match my tastes, so that's an added
> bonus.
in the end i dont really care what your taste is, or Torsten for that matter. I
care that the issue be fixed.
^ permalink raw reply
* Questions about ubifs,ubi and mtd?
From: 武井 克明 @ 2018-12-10 12:22 UTC (permalink / raw)
To: git@vger.kernel.org; +Cc: 武井 克明
Hi all,
We are developing the product using file system using ubi, ubifs on hardware with NAND flash memory.
Although the development of the product was completed, we are seeking your help as the customer who is using it is having trouble with it.
The product we have developed has 6 MTD partitions for NAND flash memory.
These consist of 6 MTDs named 'kernel-a' 'kernel-b', 'rootfs-a', 'rootfs-b', 'data-1', 'data-2', and online program only accesses 'data-1' and 'data-2' for write access.
Nevertheless, when loading our program from 'rootfs-a', trying to read the inode with the ubifs_read_node() function will result in "bad node type" (ex: 193 but expected 9) and the LEB can not be read with the expected value. (Even though you do not have write access to rootfs)
Is there anyone who encountered such a problem? Is there patch?
Please let me know, if you have any questions.
Best regards,
Katsuaki Takei/Oki Electric Industry Co., Ltd./JP
^ permalink raw reply
* [PATCH v4] remote: add --save-to-push option to git remote set-url
From: Denton Liu @ 2018-12-10 14:15 UTC (permalink / raw)
To: git; +Cc: gitster
In-Reply-To: <8fded8b84b593497177de740f80b3499c4269758.1541740174.git.liu.denton@gmail.com>
This adds the --save-to-push option to `git remote set-url` such that
when executed, we move the remote.*.url to remote.*.pushurl and set
remote.*.url to the given url argument.
For example, if we have the following config:
[remote "origin"]
url = git@github.com:git/git.git
`git remote set-url --save-to-push origin https://github.com/git/git.git`
would change the config to the following:
[remote "origin"]
url = https://github.com/git/git.git
pushurl = git@github.com:git/git.git
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Denton Liu <liu.denton@gmail.com>
---
This patch improves upon v3 by adding the use-case for the new option,
as discussed here[1].
[1]: https://public-inbox.org/git/xmqqtvjlisnu.fsf@gitster-ct.c.googlers.com/
---
Documentation/git-remote.txt | 12 ++++++++++++
builtin/remote.c | 26 +++++++++++++++++++++-----
t/t5505-remote.sh | 11 +++++++++++
3 files changed, 44 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
index 0cad37fb81..47aaae22c1 100644
--- a/Documentation/git-remote.txt
+++ b/Documentation/git-remote.txt
@@ -19,6 +19,7 @@ SYNOPSIS
'git remote set-url' [--push] <name> <newurl> [<oldurl>]
'git remote set-url --add' [--push] <name> <newurl>
'git remote set-url --delete' [--push] <name> <url>
+'git remote set-url --save-to-push' <name> <url>
'git remote' [-v | --verbose] 'show' [-n] <name>...
'git remote prune' [-n | --dry-run] <name>...
'git remote' [-v | --verbose] 'update' [-p | --prune] [(<group> | <remote>)...]
@@ -155,6 +156,17 @@ With `--delete`, instead of changing existing URLs, all URLs matching
regex <url> are deleted for remote <name>. Trying to delete all
non-push URLs is an error.
+
+With `--save-to-push`, the current URL is saved into the push URL before
+setting the URL to <url>. Note that this command will not work if more than one
+URL is defined because the behavior would be ambiguous. A use-case for this
+feature is that you may have started your interaction with the repository with
+a single authenticated URL that can be used for both fetching and pushing, but
+over time you may have become sick of having to authenticate only to fetch. In
+such a case, you can feed an unauthenticated/anonymous fetch URL to set-url
+with this option, so that the authenticated URL that you have been using for
+pushing becomes the pushURL, and the new, unauthenticated/anonymous URL will be
+used for fetching.
++
Note that the push URL and the fetch URL, even though they can
be set differently, must still refer to the same place. What you
pushed to the push URL should be what you would see if you
diff --git a/builtin/remote.c b/builtin/remote.c
index f7edf7f2cb..d683e67ba6 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -24,8 +24,9 @@ static const char * const builtin_remote_usage[] = {
N_("git remote set-branches [--add] <name> <branch>..."),
N_("git remote get-url [--push] [--all] <name>"),
N_("git remote set-url [--push] <name> <newurl> [<oldurl>]"),
- N_("git remote set-url --add <name> <newurl>"),
- N_("git remote set-url --delete <name> <url>"),
+ N_("git remote set-url --add [--push] <name> <newurl>"),
+ N_("git remote set-url --delete [--push] <name> <url>"),
+ N_("git remote set-url --save-to-push <name> <url>"),
NULL
};
@@ -77,8 +78,9 @@ static const char * const builtin_remote_geturl_usage[] = {
static const char * const builtin_remote_seturl_usage[] = {
N_("git remote set-url [--push] <name> <newurl> [<oldurl>]"),
- N_("git remote set-url --add <name> <newurl>"),
- N_("git remote set-url --delete <name> <url>"),
+ N_("git remote set-url --add [--push] <name> <newurl>"),
+ N_("git remote set-url --delete [--push] <name> <url>"),
+ N_("git remote set-url --save-to-push <name> <url>"),
NULL
};
@@ -1519,7 +1521,7 @@ static int get_url(int argc, const char **argv)
static int set_url(int argc, const char **argv)
{
- int i, push_mode = 0, add_mode = 0, delete_mode = 0;
+ int i, push_mode = 0, save_to_push = 0, add_mode = 0, delete_mode = 0;
int matches = 0, negative_matches = 0;
const char *remotename = NULL;
const char *newurl = NULL;
@@ -1532,6 +1534,8 @@ static int set_url(int argc, const char **argv)
struct option options[] = {
OPT_BOOL('\0', "push", &push_mode,
N_("manipulate push URLs")),
+ OPT_BOOL('\0', "save-to-push", &save_to_push,
+ N_("change fetching URL behavior")),
OPT_BOOL('\0', "add", &add_mode,
N_("add URL")),
OPT_BOOL('\0', "delete", &delete_mode,
@@ -1543,6 +1547,8 @@ static int set_url(int argc, const char **argv)
if (add_mode && delete_mode)
die(_("--add --delete doesn't make sense"));
+ if (save_to_push && (push_mode || add_mode || delete_mode))
+ die(_("--save-to-push cannot be used with other options"));
if (argc < 3 || argc > 4 || ((add_mode || delete_mode) && argc != 3))
usage_with_options(builtin_remote_seturl_usage, options);
@@ -1564,6 +1570,16 @@ static int set_url(int argc, const char **argv)
urlset = remote->pushurl;
urlset_nr = remote->pushurl_nr;
} else {
+ if (save_to_push) {
+ if (remote->url_nr != 1)
+ die(_("--save-to-push can only be used when only one url is defined"));
+
+ strbuf_addf(&name_buf, "remote.%s.pushurl", remotename);
+ git_config_set_multivar(name_buf.buf,
+ remote->url[0], "^$", 0);
+ strbuf_reset(&name_buf);
+ }
+
strbuf_addf(&name_buf, "remote.%s.url", remotename);
urlset = remote->url;
urlset_nr = remote->url_nr;
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index d2a2cdd453..434c1f828a 100755
--- a/t/t5505-remote.sh
+++ b/t/t5505-remote.sh
@@ -1194,6 +1194,17 @@ test_expect_success 'remote set-url --delete baz' '
cmp expect actual
'
+test_expect_success 'remote set-url --save-to-push bbb' '
+ git remote set-url --save-to-push someremote bbb &&
+ echo bbb >expect &&
+ echo "YYY" >>expect &&
+ echo ccc >>expect &&
+ git config --get-all remote.someremote.url >actual &&
+ echo "YYY" >>actual &&
+ git config --get-all remote.someremote.pushurl >>actual &&
+ cmp expect actual
+'
+
test_expect_success 'extra args: setup' '
# add a dummy origin so that this does not trigger failure
git remote add origin .
--
2.19.2
^ permalink raw reply related
* Re: [PATCH v3 06/16] sequencer: refactor sequencer_add_exec_commands() to work on a todo_list
From: Phillip Wood @ 2018-12-10 14:33 UTC (permalink / raw)
To: Johannes Schindelin, phillip.wood; +Cc: Alban Gruin, git, Junio C Hamano
In-Reply-To: <nycvar.QRO.7.76.6.1811302002340.41@tvgsbejvaqbjf.bet>
On 30/11/2018 19:06, Johannes Schindelin wrote:
> Hi,
>
> On Fri, 30 Nov 2018, Phillip Wood wrote:
>
>>> diff --git a/sequencer.c b/sequencer.c
>>> index 900899ef20..11692d0b98 100644
>>> --- a/sequencer.c
>>> +++ b/sequencer.c
>>> @@ -4394,24 +4394,29 @@ int sequencer_make_script(FILE *out, int argc, const
>>> char **argv,
>>> return 0;
>>> }
>>>
>>> -/*
>>> - * Add commands after pick and (series of) squash/fixup commands
>>> - * in the todo list.
>>> - */
>>> -int sequencer_add_exec_commands(const char *commands)
>>> +static void todo_list_add_exec_commands(struct todo_list *todo_list,
>>> + struct string_list *commands)
>>> {
>>> - const char *todo_file = rebase_path_todo();
>>> - struct todo_list todo_list = TODO_LIST_INIT;
>>> - struct strbuf *buf = &todo_list.buf;
>>> - size_t offset = 0, commands_len = strlen(commands);
>>> - int i, insert;
>>> + struct strbuf *buf = &todo_list->buf;
>>> + const char *old_buf = buf->buf;
>>> + size_t base_length = buf->len;
>>> + int i, insert, nr = 0, alloc = 0;
>>> + struct todo_item *items = NULL, *base_items = NULL;
>>>
>>> - if (strbuf_read_file(&todo_list.buf, todo_file, 0) < 0)
>>> - return error(_("could not read '%s'."), todo_file);
>>> + for (i = 0; i < commands->nr; ++i) {
>>> + strbuf_addstr(buf, commands->items[i].string);
>>> + strbuf_addch(buf, '\n');
>>> + }
>>
>> This could cause buf->buf to be reallocated in which case all the
>> todo_list_item.arg pointers will be invalidated.
>
> I guess it is a good time for me to admit that the `arg` idea was not my
> best. Maybe it would be good to convert that from a pointer to an offset,
> e.g. `size_t arg_offset_in_buf;`? Or maybe we should just drop the
> `_in_buf` suffix and clarify in a comment next to the declaration of the
> fields that they are offsets in the strbuf?
I think that sounds sensible (though I haven't looked at how much work
it would be), having a comment and calling it arg_offset would be my
preference.
Best Wishes
Phillip
>
> Ciao,
> Dscho
>
^ permalink raw reply
* Re: A case where diff.colorMoved=plain is more sensible than diff.colorMoved=zebra & others
From: Phillip Wood @ 2018-12-10 14:43 UTC (permalink / raw)
To: Stefan Beller, Phillip Wood; +Cc: Ævar Arnfjörð Bjarmason, git
In-Reply-To: <CAGZ79kZVfMNELXuir+t9U8bSg2PVF=oX8aya-OqmRaP0gHRgFw@mail.gmail.com>
On 06/12/2018 18:11, Stefan Beller wrote:
> On Thu, Dec 6, 2018 at 6:58 AM Phillip Wood <phillip.wood@talktalk.net> wrote:
>
>>> So is there some "must be at least two consecutive lines" condition for
>>> not-plain, or is something else going on here?
>>
>> To be considered a block has to have 20 alphanumeric characters - see
>> commit f0b8fb6e59 ("diff: define block by number of alphanumeric chars",
>> 2017-08-15). This stops things like random '}' lines being marked as
>> moved on their own.
>
> This is spot on.
>
> All but the "plain" mode use the concept of "blocks" of code
> (there is even one mode called "blocks", which adds to the confusion).
>
>> It might be better to use some kind of frequency
>> information (a bit like python's difflib junk parameter) instead so that
>> (fairly) unique short lines also get marked properly.
>
> Yes that is what I was initially thinking about. However to have good
> information, you'd need to index a whole lot (the whole repository,
> i.e. all text blobs in existence?) to get an accurate picture of frequency
> information, which I'd prefer to call entropy as I come from a background
> familiar with https://en.wikipedia.org/wiki/Information_theory, I am not
> sure where 'frequency information' comes from -- it sounds like the
> same concept.
>
> Of course it is too expensive to run an operation O(repository size)
> just for this diff, so maybe we could get away with some smaller
> corpus to build up this information on what is sufficient for coloring.
>
> When only looking at the given diff, I would imagine that each line
> would not carry a whole lot of information as its characters occur
> rather frequently compared to the rest of the diff.
I was thinking of using lines rather than characters as the unit of
information (if that's the right phrase). I was hoping that seeing how
often a given line occurs within the set of files being diffed would be
good enough to tell is if it is an "interesting" move or not. In the
mean time I wonder if decreasing the block limit to 10 alphanumeric
characters would be enough to prevent too much noise in the output
without suppressing matches that it would be useful to highlight.
Best Wishes
Phillip
>
> Best,
> Stefan
>
^ permalink raw reply
* Re: Questions about ubifs,ubi and mtd?
From: Ævar Arnfjörð Bjarmason @ 2018-12-10 14:46 UTC (permalink / raw)
To: 武井 克明; +Cc: git@vger.kernel.org
In-Reply-To: <TY2PR01MB2700AD659601C0341B5C06929DA50@TY2PR01MB2700.jpnprd01.prod.outlook.com>
On Mon, Dec 10 2018, 武井 克明 wrote:
> Hi all,
>
> We are developing the product using file system using ubi, ubifs on hardware with NAND flash memory.
>
> Although the development of the product was completed, we are seeking your help as the customer who is using it is having trouble with it.
>
> The product we have developed has 6 MTD partitions for NAND flash memory.
> These consist of 6 MTDs named 'kernel-a' 'kernel-b', 'rootfs-a', 'rootfs-b', 'data-1', 'data-2', and online program only accesses 'data-1' and 'data-2' for write access.
> Nevertheless, when loading our program from 'rootfs-a', trying to read the inode with the ubifs_read_node() function will result in "bad node type" (ex: 193 but expected 9) and the LEB can not be read with the expected value. (Even though you do not have write access to rootfs)
>
> Is there anyone who encountered such a problem? Is there patch?
>
> Please let me know, if you have any questions.
>
> Best regards,
> Katsuaki Takei/Oki Electric Industry Co., Ltd./JP
Hi. I think you're on the wrong mailing list (git@). You probably want
to contact one of the linux lists, perhaps
http://lists.infradead.org/mailman/listinfo/linux-mtd ?
^ permalink raw reply
* [PATCH 1/1] completion: complete <rev> in `git worktree add <path> <rev>`
From: Johannes Schindelin via GitGitGadget @ 2018-12-10 15:10 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Johannes Schindelin
In-Reply-To: <pull.82.git.gitgitgadget@gmail.com>
From: Johannes Schindelin <johannes.schindelin@gmx.de>
The second non-option argument to `git worktree`'s `add` command is an
optional revision. Let's complete it.
Inspired by https://github.com/git-for-windows/git/pull/1681.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
contrib/completion/git-completion.bash | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 9e8ec95c3c..4194b4a2e7 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2773,6 +2773,11 @@ _git_worktree ()
add,--*)
__gitcomp_builtin worktree_add
;;
+ add,*)
+ if [ $(__git_count_arguments "worktree") -eq 2 ]; then
+ __git_complete_refs
+ fi
+ ;;
list,--*)
__gitcomp_builtin worktree_list
;;
--
gitgitgadget
^ permalink raw reply related
* [PATCH 0/1] worktree: add completion for the rev argument in git worktree add <path> <rev>
From: Johannes Schindelin via GitGitGadget @ 2018-12-10 15:10 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
This is inspired by one of those half-finished contributions in the Git for
Windows project. Fall cleaning, if you like.
Johannes Schindelin (1):
completion: complete <rev> in `git worktree add <path> <rev>`
contrib/completion/git-completion.bash | 5 +++++
1 file changed, 5 insertions(+)
base-commit: d166e6afe5f257217836ef24a73764eba390c58d
Published-As: https://github.com/gitgitgadget/git/releases/tags/pr-82%2Fdscho%2Fcomplete-worktree-add-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-82/dscho/complete-worktree-add-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/82
--
gitgitgadget
^ permalink raw reply
* Re: Retrieving a file in git that was deleted and committed
From: Sergey Organov @ 2018-12-10 15:12 UTC (permalink / raw)
To: biswaranjan panda; +Cc: git
In-Reply-To: <CADHAf1Y_d=-9By4jC2xd+BmWJgfGmBNUr=uSuQtfuHDrarN4kw@mail.gmail.com>
biswaranjan panda <biswaranjan.nitrkl@gmail.com> writes:
> I have the following scenario:
>
> On a branch A, I deleted a file foo.txt and committed the change. Then
> I did a bunch of other changes.
> Now I want to undelete foo.txt.
[...]
> I would appreciate if anyone knows how to preserve git blame history.
Provided you deleted the file by mistake and you didn't yet publish the
history, just rewrite the history, fixing the commit that deleted the
file. "git rebase -i" is a suitable way to do it.
-- Sergey
^ permalink raw reply
* Re: [PATCH] parse-options: fix SunCC compiler warning
From: Duy Nguyen @ 2018-12-10 15:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: avarab, git, sunshine, szeder.dev
In-Reply-To: <xmqqy38xkhvd.fsf@gitster-ct.c.googlers.com>
On Mon, Dec 10, 2018 at 03:36:54PM +0900, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>
> > The compiler reports this because show_gitcomp() never actually
> > returns a value:
> >
> > "parse-options.c", line 520: warning: Function has no return
> > statement : show_gitcomp
> >
> > The function calls exit() and will never return. Update and mark it
> > NORETURN.
>
> Yuck. This should do for now, but I am not impressed by the choice
> to hook show_gitcomp() call into parse_options_step(), which forces
> such an abnormal exit deeper in the callchain [*1*]. For readers
> (not compilers), it would help to have a comment at the caller that
> says that show_gitcomp() never returns and exits.
>
> side note #1. Perhaps parse_options_start() would have been
> a better place, instead of parse_options_step() that is
> repeatedly called in a loop and itself has a loop. ANd
> worse yet, the check is done inside the loop even though the
> call is to be made only when the --git-completion-helper
> option is given as the sole request.
The reason it's in parse_options_step() is because -h is also handled
in there. Although -h does not bury exit() deep in the call chain. So
how about this as a replacement?
-- 8< --
diff --git a/parse-options.c b/parse-options.c
index 3b874a83a0..6932eaff61 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -516,7 +516,7 @@ static int show_gitcomp(struct parse_opt_ctx_t *ctx,
show_negated_gitcomp(original_opts, -1);
show_negated_gitcomp(original_opts, nr_noopts);
fputc('\n', stdout);
- exit(0);
+ return PARSE_OPT_COMPLETE;
}
static int usage_with_options_internal(struct parse_opt_ctx_t *,
@@ -638,6 +638,8 @@ int parse_options(int argc, const char **argv, const char *prefix,
case PARSE_OPT_HELP:
case PARSE_OPT_ERROR:
exit(129);
+ case PARSE_OPT_COMPLETE:
+ exit(0);
case PARSE_OPT_NON_OPTION:
case PARSE_OPT_DONE:
break;
diff --git a/parse-options.h b/parse-options.h
index 6c4fe2016d..a650a7d220 100644
--- a/parse-options.h
+++ b/parse-options.h
@@ -208,6 +208,7 @@ extern int opterror(const struct option *opt, const char *reason, int flags);
/*----- incremental advanced APIs -----*/
enum {
+ PARSE_OPT_COMPLETE = -2,
PARSE_OPT_HELP = -1,
PARSE_OPT_DONE,
PARSE_OPT_NON_OPTION,
-- 8< --
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox