Ævar Arnfjörð Bjarmason writes:
> @@ -417,7 +415,6 @@ static void compile_fixed_regexp(struct grep_pat *p,
> struct grep_opt *opt)
> int regflags;
>
> basic_regex_quote_buf(&sb, p->pattern);
> - regflags = opt->regflags & ~REG_EXTENDED;
> if (opt->ignore_case)
>
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
You can find the changes described
Ævar Arnfjörð Bjarmason writes:
> Remove redundant assignments to the "regflags" variable. There are no
> code paths that have previously set the regflags to anything, and
> certainly not to `|= REG_EXTENDED`.
>
> This code gave the impression that it had to reset its environment,
> but it doesn
Junio C Hamano writes:
> g...@jeffhostetler.com writes:
>
>> From: Jeff Hostetler
>>
>> Version 8 of this patch converts the unit test to use
>> perl to corrupt the index checksum (rather than altering
>> a filename) and also verifies the fsck error message as
>> suggested in response to v7 on t
So all in all it seams as if there is a very old race condition here,
which we "never" have seen yet.
Moving the file to a different inode number fixes the test case,
Git doesn't treat it as unchanged any more.
Thanks a lot for investigating this! Would you mind posting the
fix as patch?
Th
g...@jeffhostetler.com writes:
> From: Jeff Hostetler
>
> Version 8 of this patch converts the unit test to use
> perl to corrupt the index checksum (rather than altering
> a filename) and also verifies the fsck error message as
> suggested in response to v7 on the mailing list.
>
> If there are
Ævar Arnfjörð Bjarmason writes:
> Right now this is all dead code, but I wonder if instead we should be
> partially reverting commit 70a8fc999d ("stop using fnmatch (either
> native or compat)", 2014-02-15) by Duy to the extent of being able to
> extend t/helper/test-wildmatch.c to test fnmatch()
Jeff King writes:
> I think the words "instruction list" may have come from my suggestion. I
> used them because that is the term used in the rebase.instructionFormat
> documentation directly above the option you are adding.
>
> It may be worth a follow-on patch to convert that one to "todo list"
Junio C Hamano writes:
> Johannes Schindelin writes:
>
>> In any case, it is a question unrelated to the work I performed in this
>> patch series: the raison d'être of these patches is to allow timestamps to
>> refer to dates that are currently insanely far in the future.
>
> Yes, but the job of
Johannes Schindelin writes:
> This patch series reimplements the expensive pre- and post-processing of
> the todo script in C.
>
> And it concludes the work I did to accelerate rebase -i.
I noticed (this is merely "I felt"; I didn't measure) that recent
"rebase -i" sessions I do on a Linux box i
Johannes Schindelin writes:
> Just in case that certain reviewers favor length over readability, let me
> offer this snippet:
>
> size=$(perl -e "print -s \".git/index\"") &&
> dd if=/dev/zero of=.git/index bs=1 seek=$(($size-20) count=20
Yup, this does sound like a good direction to
"Philip Oakley" writes:
> As I recall Christoph was using checkout to copy a file (e.g. a
> template file) from an older commit/revision into his worktree, and
> was suprised that this (git checkout ) also _staged_ the
> file, rather than simply letting it be in a modified/untracked state.
This
Jacob Keller writes:
> On Mon, Apr 24, 2017 at 11:29 PM, Junio C Hamano wrote:
>> Personally I am happy with the beginning of each instruction line
>> aligned, so from that point of view, this patch is a mild Meh to me,
>> even though I do a fair amount of "rebase -i" myself. But obviously
>> I
Jonathan Nieder writes:
> Jonathan Tan wrote:
>
>> Reported-by: Brian Norris
>> Signed-off-by: Jonathan Tan
>> ---
> [...]
>> sequencer.c | 11 +++
>> t/t3511-cherry-pick-x.sh | 14 ++
>> 2 files changed, 25 insertions(+)
>
> Reviewed-by: Jonathan Nieder
>
> T
Ævar Arnfjörð Bjarmason writes:
> Indeed, I've tried to be careful not to introduce bugs like that, but
> in this skipped case the tests look completely stand-alone to me.
Yes, the ones I commented on in the upthread looked like their side
effect were not felt in the later tests.
> In any case,
René Scharfe writes:
> I can't think of many ways to get future time stamps (broken clock,
> broken CMOS battery, bit rot, time travel), so I wouldn't expect a
> change towards better error reporting to affect a lot of users. (Not
> necessarily as part of this series, of course.)
Better error r
Johannes Schindelin writes:
> In any case, it is a question unrelated to the work I performed in this
> patch series: the raison d'être of these patches is to allow timestamps to
> refer to dates that are currently insanely far in the future.
Yes, but the job of the maintainer is to prevent narr
On Tue, Apr 25, 2017 at 08:13:27PM -0400, liam Beguin wrote:
> > > +rebase.abbrevCmd::
> > > + If set to true, `git rebase -i` will abbreviate the command-names in the
> > > + instruction list. This means that instead of looking like this,
> >
> > This is by no means your fault, but it is really
Brandon Williams writes:
> In some situations run-command will incorrectly try (and fail) to
> execute a directory instead of an executable file. This was observed by
> having a directory called "ssh" in $PATH before the real ssh and trying
> to use ssh protoccol, reslting in the following:
>
>
Jonathan Nieder writes:
> In other words, I think the commit message needs a bit more detail about
> the use case, to say why omitting those tags is useful. The use case
> is probably sane but it is not explained. A side effect (and my main
> motivation) is that this would make it crystal clear
Hi Johannes,
On Tue, 2017-04-25 at 22:08 +0200, Johannes Schindelin wrote:
> Hi Liam,
>
> On Tue, 25 Apr 2017, Liam Beguin wrote:
>
> > Add the 'rebase.abbrevCmd' boolean config option to allow `git rebase -i`
> > to abbreviate the command-names in the instruction list.
> >
> > This means that
Jonathan Tan wrote:
> Reported-by: Brian Norris
> Signed-off-by: Jonathan Tan
> ---
[...]
> sequencer.c | 11 +++
> t/t3511-cherry-pick-x.sh | 14 ++
> 2 files changed, 25 insertions(+)
Reviewed-by: Jonathan Nieder
This is still pretty subtle (using the added
In commit 967dfd4 ("sequencer: use trailer's trailer layout",
2016-11-29), sequencer was taught to use the same mechanism as
interpret-trailers to determine the nature of the trailer of a commit
message (referred to as the "footer" in sequencer.c). However, the
requirement that a footer end in a ne
Brandon Williams wrote:
> In some situations run-command will incorrectly try (and fail) to
> execute a directory instead of an executable file. This was observed by
> having a directory called "ssh" in $PATH before the real ssh and trying
> to use ssh protoccol, reslting in the following:
>
>
Brandon Williams wrote:
> Move the logic for 'is_executable()' from help.c to run_command.c and
> expose it so that callers from outside help.c can access the function.
> This is to enable run-command to be able to query if a file is
> executable in a future patch.
>
> Signed-off-by: Brandon Willi
In some situations run-command will incorrectly try (and fail) to
execute a directory instead of an executable file. This was observed by
having a directory called "ssh" in $PATH before the real ssh and trying
to use ssh protoccol, reslting in the following:
$ git ls-remote ssh://url
Move the logic for 'is_executable()' from help.c to run_command.c and
expose it so that callers from outside help.c can access the function.
This is to enable run-command to be able to query if a file is
executable in a future patch.
Signed-off-by: Brandon Williams
---
help.c| 43 +--
Johannes Schindelin wrote:
>> On Tue, Apr 25, 2017 at 2:51 PM, Jonathan Tan
>> wrote:
>>> On 04/25/2017 02:04 PM, Stefan Beller wrote:
Do we want to test for this use case in the future?
[...]
>>> I'm not sure of the value of including a test for this specific use case,
>>> because Git norm
I am not sure if this is a regression or not, but I wanted to get feedback.
It looks like this commit changed some behavior in git-http-backend
https://git.kernel.org/pub/scm/git/git.git/commit/?id=6bc0cb5176a5e42ca4a74e3558e8f0790ed09bb1
The change that it has made is that it no git-upload-pack
Hi Jake,
On Tue, 2017-04-25 at 01:29 -0700, Jacob Keller wrote:
> On Mon, Apr 24, 2017 at 11:29 PM, Junio C Hamano wrote:
> > Personally I am happy with the beginning of each instruction line
> > aligned, so from that point of view, this patch is a mild Meh to me,
> > even though I do a fair amo
Hi,
Jonathan Tan wrote:
> In commit 967dfd4 ("sequencer: use trailer's trailer layout",
> 2016-11-29), sequencer was taught to use the same mechanism as
> interpret-trailers to determine the nature of the trailer of a commit
> message (referred to as the "footer" in sequencer.c). However, the
> r
Hi Johannes,
On Tue, 2017-04-25 at 21:45 +0200, Johannes Schindelin wrote:
> Hi Liam,
>
> On Mon, 24 Apr 2017, liam BEGUIN wrote:
>
> > On Mon, 2017-04-24 at 12:26 +0200, Johannes Schindelin wrote:
> >
> > > On Sun, 23 Apr 2017, Liam Beguin wrote:
> > >
> > > > Add the 'rebase.abbrevCmd' boole
Hi Johannes,
On Tue, 2017-04-25 at 23:23 +0200, Johannes Schindelin wrote:
> Hi Andreas,
>
> On Tue, 25 Apr 2017, Andreas Schwab wrote:
>
> > On Apr 25 2017, Liam Beguin wrote:
> >
> > > diff --git a/Documentation/config.txt b/Documentation/config.txt
> > > index 475e874d5155..8b1877f2df91 10
Hi,
Ævar Arnfjörð Bjarmason wrote:
> Add a --no-tags option to "git clone" to clone without tags. Currently
> there's no easy way to clone a repository and end up with just a
> "master" branch via --single-branch, or track all branches and no
> tags. Now --no-tags can be added to "git clone" with
Hi,
Ævar Arnfjörð Bjarmason wrote:
> Add a --no-tags option to "git clone" to clone without tags. Currently
> there's no easy way to clone a repository and end up with just a
> "master" branch via --single-branch, or track all branches and no
> tags. Now --no-tags can be added to "git clone" with
On Tue, Apr 25, 2017 at 02:56:53PM -0700, Stefan Beller wrote:
> In that case: Is it needed to hint at how this bug occurred in the wild?
> (A different Git implementation, which may be fixed now?)
I might contact the original author, but it's easy enough to imagine
automated 'filter-branch' scrip
Hi René,
On Tue, 25 Apr 2017, René Scharfe wrote:
> Am 24.04.2017 um 15:57 schrieb Johannes Schindelin:
> > Git v2.9.2 was released in a hurry to accomodate for platforms like
> > Windows, where the `unsigned long` data type is 32-bit even for 64-bit
> > setups.
> >
> > The quick fix was to simp
Hi Stefan,
On Tue, 25 Apr 2017, Stefan Beller wrote:
> On Tue, Apr 25, 2017 at 2:51 PM, Jonathan Tan
> wrote:
> > On 04/25/2017 02:04 PM, Stefan Beller wrote:
> >>
> >> Thanks for the fix. :)
> >> Do we want to test for this use case in the future?
> >
> >
> > Thanks!
> >
> > I'm not sure of th
On Tue, Apr 25, 2017 at 2:51 PM, Jonathan Tan wrote:
> On 04/25/2017 02:04 PM, Stefan Beller wrote:
>>
>> Thanks for the fix. :)
>> Do we want to test for this use case in the future?
>
>
> Thanks!
>
> I'm not sure of the value of including a test for this specific use case,
> because Git normally
Hi Jonathan,
On Tue, 25 Apr 2017, Jonathan Tan wrote:
> Thanks for the bug report. Here's a fix - I've verified this with the
> way to reproduce provided in the original e-mail, and it seems to work
> now.
If there is a straight-forward way to convert the manual test into an
automated one, it wo
Am 24.04.2017 um 15:57 schrieb Johannes Schindelin:
Git v2.9.2 was released in a hurry to accomodate for platforms like
Windows, where the `unsigned long` data type is 32-bit even for 64-bit
setups.
The quick fix was to simply disable all the testing with "absurd" future
dates.
However, we can
On 04/25/2017 02:04 PM, Stefan Beller wrote:
Thanks for the fix. :)
Do we want to test for this use case in the future?
Thanks!
I'm not sure of the value of including a test for this specific use
case, because Git normally does not create commit messages with no
trailing newlines. (To test t
Hi Stepan,
as I commented on your post to the Git for Windows mailing list:
On Tue, 25 Apr 2017, Stepan Kasal wrote:
> I have installed git for windows sdk from the web and tried to build it.
Nobody in the project found the time to update the website yet, but we do
have a simpler way to install
On Tue, Apr 25, 2017 at 01:21:09PM -0400, Marc Branchaud wrote:
> So I have
>
> diff.indentHeuristic = true
>
> and I noticed that git-gui was not using the heuristic. This is because
> git-gui uses diff-index, and that does not respect the config setting, even
> though it supports the --
Hi Andreas,
On Tue, 25 Apr 2017, Andreas Schwab wrote:
> On Apr 25 2017, Liam Beguin wrote:
>
> > diff --git a/Documentation/config.txt b/Documentation/config.txt
> > index 475e874d5155..8b1877f2df91 100644
> > --- a/Documentation/config.txt
> > +++ b/Documentation/config.txt
> > @@ -2614,6 +26
Hi,
On Mon, 24 Apr 2017, suzuki-kenta wrote:
> Git image and capture screen,
> I'd like to get a license but is it possible?
If I understand correctly, you want to use screenshots of Git? As far as I
can tell, there is no need to license those. There are tons of examples
all over the internet wh
Change the grep PCRE v1 code to use JIT when available. When PCRE
support was initially added in commit 63e7e9d8b6 ("git-grep: Learn
PCRE", 2011-05-09) PCRE had no JIT support, it was integrated into
8.20 released on 2011-10-21.
When JIT support is enabled the PCRE performance usually improves by
Remove the support for concurrently using PCRE v1 & v2 by compiling
Git with support for both at the same time.
Having access to both at runtime via grep.patternType=[pcre1|pcre2]
makes it easier for the developer hacking on the PCRE implementations
to test them concurrently, but adds confusion fo
Change the USE_LIBPCRE=YesPlease & --with-libpcre flags to the
Makefile & configure script, respectively, to mean use PCRE v2, not
PCRE v1.
The legacy library previously available via those options is still
available on request via USE_LIBPCRE1=YesPlease or
--with-libpcre1. The existing USE_LIBPCR
Add support for v2 of the PCRE API. This is a new major version of
PCRE that came out in early 2015[1].
The regular expression syntax is the same, but while the API is
similar-ish, pretty much every function is either renamed or takes
different arguments. Thus using it via entirely new functions m
Add a very basic performance comparison test comparing the POSIX
extended & pcre1 engines.
I'm skipping the "basic" POSIX engine because supporting its alternate
regex syntax is hard, although it would be interesting to test it, at
least under glibc it seems to be an entirely different engine, sin
Make the pattern types "pcre" & "pcre1" synonyms for the long-standing
"perl" grep.patternType.
This change is part of a longer patch series to add pcre2 support to
Git. It's nice to be able to performance test PCRE v1 v.s. v2 without
having to recompile git, and doing that via grep.patternType ma
Add exhaustive tests for how the different grep.patternType options &
the corresponding command-line options affect git-log.
Before this change it was possible to patch revision.c so that the
--basic-regexp option was synonymous with --extended-regexp, and
--perl-regexp wasn't recognized at all, a
Rename the LIBPCRE prerequisite to PCRE. This is for preparation for
libpcre2 support, where having just "LIBPCRE" would be confusing as it
implies v1 of the library.
None of these tests are incompatible between versions 1 & 2 of
libpcre, it's less confusing to give them a more general name to mak
Stop promising in our grep & rev-list options documentation that we're
always going to be using libpcre when given the --perl-regexp option.
Instead talk about using "Perl-compatible regular expressions" and
using these types of patterns using "a compile-time dependency".
Saying "libpcre" strongl
Change the internal PCRE variable & function names to have a "1"
suffix. This is for preparation for libpcre2 support, where having
non-versioned names would be confusing.
The earlier "grep: change the internal PCRE macro names to be PCRE1"
change elaborates on the motivations behind this commit.
Change the internal USE_LIBPCRE define, & build options flag to use a
naming convention ending in PCRE1, without changing the long-standing
USE_LIBPCRE Makefile flag which enables this code.
This is for preparation for libpcre2 support where having things like
USE_LIBPCRE and USE_LIBPCRE2 in any m
Remove redundant assignments to the "regflags" variable. There are no
code paths that have previously set the regflags to anything, and
certainly not to `|= REG_EXTENDED`.
This code gave the impression that it had to reset its environment,
but it doesn't. This dates back to the initial introductio
Reword an outdated comment which suggests that only git-grep can use
PCRE.
This comment was added back when PCRE support was initially added in
commit 63e7e9d8b6 ("git-grep: Learn PCRE", 2011-05-09), and was true
at the time.
It hasn't been telling the full truth since git-log learned to use
PCRE
Add a short -P option as a synonym for the longer --perl-regexp, for
consistency with the options the corresponding grep invocations
accept.
This was intentionally omitted in commit 727b6fc3ed ("log --grep:
accept --basic-regexp and --perl-regexp", 2012-10-03) for unspecified
future use.
Since no
Add a test for backreferences such as (.)\1 in PCRE patterns. This
test ensures that the PCRE_NO_AUTO_CAPTURE option isn't turned
on. Before this change turning it on would break these sort of
patterns, but wouldn't break any tests.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
t/t7810-grep.sh | 7
Remove a redundant assignment to the "regflags" variable. This
variable is only used for POSIX regular expression matching, not when
the PCRE library is used.
This redundant assignment was added as a result of copy/paste
programming in commit 84befcd0a4 ("grep: add a grep.patternType
configuration
Trivial changes since last time. Just sending this because I'd like
the copy in pu updated. Changes noted below:
Ævar Arnfjörð Bjarmason (19):
grep: amend submodule recursion test in preparation for rx engine
testing
grep: add tests for grep pattern types being passed to submodules
A s/PC
Change two case statements added in commit 0281e487fd ("grep:
optionally recurse into submodules", 2016-12-16) so that they die if
new GREP_PATTERN_* enum fields are added without updating them.
These case statements currently check for an exhaustive list of
fields, but if a new field is added it'
Amend the submodule recursion test added in commit 0281e487fd ("grep:
optionally recurse into submodules", 2016-12-16) to prepare it for
subsequent tests of whether it passes along the grep.patternType to
the submodule greps.
This is just the result of searching & replacing:
foobar -> (1|2)d(
Add testing for grep pattern types being correctly passed to
submodules. The pattern "(.|.)[\d]" matches differently under
fixed (not at all), and then matches different lines under
basic/extended & perl regular expressions, so this change asserts that
the pattern type is passed along correctly.
S
Hi,
On Mon, 24 Apr 2017, Junio C Hamano wrote:
> Jeff Hostetler writes:
>
> >>> +test_expect_success 'detect corrupt index file in fsck' '
> >>> +cp .git/index .git/index.backup &&
> >>> +test_when_finished "mv .git/index.backup .git/index" &&
> >>> +echo > &&
> >>>
On Tue, Apr 25, 2017 at 12:06 PM, Jonathan Tan wrote:
> In commit 967dfd4 ("sequencer: use trailer's trailer layout",
> 2016-11-29), sequencer was taught to use the same mechanism as
> interpret-trailers to determine the nature of the trailer of a commit
> message (referred to as the "footer" in s
Hi Peff,
On Mon, 24 Apr 2017, Jeff King wrote:
> On Sun, Apr 23, 2017 at 08:29:11PM -0700, Junio C Hamano wrote:
>
> > Johannes Schindelin writes:
> >
> > > Changes since v3:
> > >
> > > - fixed the fix in archive-zip.c that tried to report a too large
> > > timestamp (and would have reporte
Hi Junio,
On Mon, 24 Apr 2017, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> >> Should we at least clamp in date_overflows() so that large values
> >> representable with timestamp_t that will become unrepresentable when
> >> we start allowing negative timestamps would be rejected? Th
Hi Liam,
On Tue, 25 Apr 2017, Liam Beguin wrote:
> Add the 'rebase.abbrevCmd' boolean config option to allow `git rebase -i`
> to abbreviate the command-names in the instruction list.
>
> This means that `git rebase -i` would print:
> p deadbee The oneline of this commit
> ...
>
> inste
Hi Liam,
On Mon, 24 Apr 2017, liam BEGUIN wrote:
> On Mon, 2017-04-24 at 12:26 +0200, Johannes Schindelin wrote:
>
> > On Sun, 23 Apr 2017, Liam Beguin wrote:
> >
> > > Add the 'rebase.abbrevCmd' boolean config option to allow the user
> > > to abbreviate the default command name while editing
On 04/25, Jonathan Nieder wrote:
> Brandon Williams wrote:
>
> > Subject: run-command: don't try to execute directories
>
> nit: this is also about non-executable files, now. That would mean
> something like
>
> run-command: don't try to execute directories or non-executable files
>
> or
>
>
Thought I'd just start another thread for this rather than tack it
onto the pathalogical case thread.
In commit 4c251e5cb5 ("wildmatch: make /**/ match zero or more
directories", 2012-10-15) Duy added support for ** in globs.
One test-case for this is:
match 1 0 'foo/baz/bar' 'foo/**/**/bar'
In commit 967dfd4 ("sequencer: use trailer's trailer layout",
2016-11-29), sequencer was taught to use the same mechanism as
interpret-trailers to determine the nature of the trailer of a commit
message (referred to as the "footer" in sequencer.c). However, the
requirement that a footer end in a ne
Brandon Williams wrote:
> Subject: run-command: don't try to execute directories
nit: this is also about non-executable files, now. That would mean
something like
run-command: don't try to execute directories or non-executable files
or
run-command: restrict PATH search to files we can execu
From: Jeff Hostetler
Version 8 of this patch converts the unit test to use
perl to corrupt the index checksum (rather than altering
a filename) and also verifies the fsck error message as
suggested in response to v7 on the mailing list.
If there are no other suggestions, I think this version
sho
From: Jeff Hostetler
Teach git to skip verification of the SHA1-1 checksum at the end of
the index file in verify_hdr() which is called from read_index()
unless the "force_verify_index_checksum" global variable is set.
Teach fsck to force this verification.
The checksum verification is for dete
On 04/25, Johannes Sixt wrote:
> Am 25.04.2017 um 19:54 schrieb Brandon Williams:
> >Move the logic for 'is_executable()' from help.c to exec_cmd.c and
> >expose it so that callers from outside help.c can access the function.
>
> The function is quite low-level. IMO, run-command.[ch] would be a
>
Am 25.04.2017 um 08:52 schrieb Junio C Hamano:
Johannes Sixt writes:
The idea of marking git-gui and gitk histories that none of their
commits is checked out: it erases all Git source code from the working
directory, and a later bisection step places all code back and it
requires a full build.
Am 25.04.2017 um 19:54 schrieb Brandon Williams:
Move the logic for 'is_executable()' from help.c to exec_cmd.c and
expose it so that callers from outside help.c can access the function.
The function is quite low-level. IMO, run-command.[ch] would be a better
home for it. Additionally, that wo
Hi,
Brandon Williams wrote:
> Move the logic for 'is_executable()' from help.c to exec_cmd.c and
> expose it so that callers from outside help.c can access the function.
> This is to enable run-command to be able to query if a file is
> executable in a future patch.
>
> Signed-off-by: Brandon Wil
In some situations run-command will incorrectly try (and fail) to
execute a directory instead of an executable file. This was observed by
having a directory called "ssh" in $PATH before the real ssh and trying
to use ssh protoccol, reslting in the following:
$ git ls-remote ssh://url
Move the logic for 'is_executable()' from help.c to exec_cmd.c and
expose it so that callers from outside help.c can access the function.
This is to enable run-command to be able to query if a file is
executable in a future patch.
Signed-off-by: Brandon Williams
---
exec_cmd.c | 42 +
> On 24 Apr 2017, at 21:48, Torsten Bögershausen wrote:
>
> On 2017-04-24 19:00, Torsten Bögershausen wrote:
>> On 2017-04-24 18:45, Lars Schneider wrote:
>>> Hi,
>>>
>>> "t0025.3 - crlf=true causes a CRLF file to be normalized" failed
>>> sporadically on next and master recently:
>>> https:/
So I have
diff.indentHeuristic = true
and I noticed that git-gui was not using the heuristic. This is because
git-gui uses diff-index, and that does not respect the config setting,
even though it supports the --indent-heuristic option.
And it looks like diff-files and diff-tree also
Am 25.04.2017 um 09:55 schrieb Peter Krefting:
René Scharfe:
This needs to be >=. The spec says that if the value is 0x,
there should be a zip64 record with the actual size (even if it is
0x).
Could you please cite the relevant part?
4.4.8 compressed size: (4 bytes)
4.4.9 un
On Mon, Apr 24, 2017 at 7:12 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> A similar bug report
>> https://public-inbox.org/git/CAG0BQX=wvpkJ=pqwv-nbmhupv8yzvd_kykzjmsfwq9xstz2...@mail.gmail.com/
>>
>> "checkout --recurse-submodules" (as mentioned in that report)
>> made it into Git by n
On Mon, Apr 24, 2017 at 5:57 PM, Jeff King wrote:
> When we init a submodule, we try to die when it has no URL
> defined:
>
> url = xstrdup(sub->url);
> if (!url)
> die(...);
>
> But that's clearly nonsense. xstrdup() will never return
> NULL, and if sub->url is NULL, we'll segfault.
Sorry if you get this twice, somehow Thunderbird converted my response
to HTML
On 4/24/2017 10:19 PM, Junio C Hamano wrote:
Ben Peart writes:
On 4/24/2017 12:21 AM, Junio C Hamano wrote:
Ben Peart writes:
+{
+ int len = packet_read(fd, NULL, NULL,
+ pa
On Tue, Apr 25, 2017 at 5:57 AM, Andreas Schwab wrote:
> On Apr 25 2017, Liam Beguin wrote:
>
>> Add the 'rebase.abbrevCmd' boolean config option to allow `git rebase -i`
>> to abbreviate the command-names in the instruction list.
>>
>> This means that `git rebase -i` would print:
>> p deadbe
This operation has quadratic complexity, which is especially painful
on Windows, where shell scripts are *already* slow (mainly due to the
overhead of the POSIX emulation layer).
Let's reimplement this with linear complexity (using a hash map to
match the commits' subject lines) for the common cas
In particular on Windows, where shell scripts are even more expensive
than on MacOSX or Linux, it makes sense to move a loop that forks
Git at least once for every line in the todo list into a builtin.
Signed-off-by: Johannes Schindelin
---
builtin/rebase--helper.c | 7 +-
git-rebase--intera
In particular on Windows, where shell scripts are even more expensive
than on MacOSX or Linux, it makes sense to move a loop that forks
Git at least once for every line in the todo list into a builtin.
Note: The original code did not try to skip unnecessary picks of root
commits but punts instead
These tests were a bit anal about the *exact* warning/error message
printed by git rebase. But those messages are intended for the *end
user*, therefore it does not make sense to test so rigidly for the
*exact* wording.
In the following, we will reimplement the missing commits check in
the sequenc
The commands used to be indented, and it is nice to look at, but when we
transform the SHA-1s, the indentation is removed. So let's do away with it.
For the moment, at least: when we will use the upcoming rebase--helper
to transform the SHA-1s, we *will* keep the indentation and can
reintroduce it
This is crucial to improve performance on Windows, as the speed is now
mostly dominated by the SHA-1 transformation (because it spawns a new
rev-parse process for *every* line, and spawning processes is pretty
slow from Git for Windows' MSYS2 Bash).
Signed-off-by: Johannes Schindelin
---
builtin
The `git commit --fixup` command unwraps wrapped onelines when
constructing the commit message, without wrapping the result.
We need to make sure that `git rebase --autosquash` keeps handling such
cases correctly, in particular since we are about to move the autosquash
handling into the rebase--he
The first step of an interactive rebase is to generate the so-called "todo
script", to be stored in the state directory as "git-rebase-todo" and to
be edited by the user.
Originally, we adjusted the output of `git log ` using a simple
sed script. Over the course of the years, the code became more
To avoid problems with short SHA-1s that become non-unique during the
rebase, we rewrite the todo script with short/long SHA-1s before and
after letting the user edit the script. Since SHA-1s are not intuitive
for humans, rebase -i also provides the onelines (commit message
subjects) in the script,
1 - 100 of 119 matches
Mail list logo
