Junio C Hamano writes:
> Ævar Arnfjörð Bjarmason writes:
>
>> if (rev->rdiff1) {
>> +struct diff_options opts;
>> +memcpy(, >diffopt, sizeof(opts));
>> +opts.output_format &= ~(DIFF_FORMAT_DIFFSTAT |
>> DIFF_FORMAT_SUMMARY);
>> +
>>
Ævar Arnfjörð Bjarmason writes:
> Change the narrow test added in 31e2617a5f ("format-patch: add
> --range-diff option to embed diff in cover letter", 2018-07-22) to
> test the full output. This test would have spotted a regression in the
> output if it wasn't beating around the bush and tested
"Johannes Schindelin via GitGitGadget"
writes:
> From: Johannes Schindelin
>
> The `%lld` format is supported on Linux and macOS, but not on Windows.
> This issue has been reported ten days ago (Message-ID:
> nycvar.qro.7.76.6.1811121300520...@tvgsbejvaqbjf.bet), but the
> corresponding topic
Thanks for a patch.
Greg Hurrell writes:
> Commit 7cb6ac1e4b made the diff format omit ellipses by default, but
> there is still this place in the documentation where we show examples of
> output with ellipses.
We prefer to cite an existing commit with its title and date these
days, not just
Jeff King writes:
>> +if ((o->pickaxe_opts & DIFF_PICKAXE_KIND_G) &&
>> +((!textconv_one && diff_filespec_is_binary(o->repo, p->one)) ||
>> + (!textconv_two && diff_filespec_is_binary(o->repo, p->two
>> +return 0;
>
> If the user passes "-a" to treat binary
Ævar Arnfjörð Bjarmason writes:
> On Wed, Nov 21 2018, Thomas Braun wrote:
>
>> The -S option of log looks for differences that changes the
>> number of occurrences of the specified string (i.e. addition/deletion)
>> in a file.
>>
> ...
> This should just be part of 1/2 since the behavior is
Ævar Arnfjörð Bjarmason writes:
> if (rev->rdiff1) {
> + struct diff_options opts;
> + memcpy(, >diffopt, sizeof(opts));
> + opts.output_format &= ~(DIFF_FORMAT_DIFFSTAT |
> DIFF_FORMAT_SUMMARY);
> +
> fprintf_ln(rev->diffopt.file, "%s",
Jeff King writes:
> Yeah, my intent had been to circle back around to this, but I just
> hadn't gotten to it. I'm still pondering a config option or similar,
> though I remain unconvinced that the cases in which you've showed it
> being slow are actually realistic or worth worrying about (and
Denton Liu writes:
> I just realised that there is a slight problem with the proposed change.
> When we do a merge and there are no merge conflicts, at the end of the
> merge, we get dropped into an editor with this text:
>
> Merge branch 'master' into new
>
> # Please enter a commit
Johannes Schindelin writes:
> To fix this, I prepared a GitGitGadget PR
> (https://github.com/gitgitgadget/git/pull/87) and will submit it as soon
> as I am satisfied that the build works.
Thanks. This won't be in the upcoming release anyway, so we can fix
it up without "oops, let's pile
Am 23.11.18 um 19:19 schrieb Frank Schäfer:
The CR marker ^M doesn't show up in '-' lines of diffs when the ending
of the removed line is CR+LF.
It shows up as expected in '-' lines when the ending of the removed line
is CR only.
It also always shows up as expected in '+' lines.
Is your
Tested-by: Carlo Marcelo Arenas Belón
IMHO leaving the shebang might be better if only for consistency but
could go eitherway
Carlo
On Thu, Nov 22, 2018 at 3:43 PM Max Kirillov wrote:
> also edited the test to include only push_plain case,
> and repeat it several times, to avoid running irrelevant
> cases, the failure never happened again.
as I explained previously[1] and as odd as it might seem the
push_plain case ONLY
On Fri, 23 Nov 2018 at 11:13, Johannes Schindelin
wrote:
> On Mon, 30 Oct 2017, Pranit Bauva wrote:
>
> > On Fri, Oct 27, 2017 at 10:58 PM, Martin Ågren
> > wrote:
> > > On 27 October 2017 at 17:06, Pranit Bauva wrote:
> > >> +static void free_terms(struct bisect_terms *terms)
> > >> +{
> > >>
Hi Carlo,
On Thu, 22 Nov 2018, Carlo Marcelo Arenas Belón wrote:
> Subject: [PATCH] entry: remove windows fallback to inode checking
>
> this test is really FS specific, so is better to avoid any compiled
> assumptions about the platform and let the user drive the fallback
> through
Hi Peff,
On Thu, 22 Nov 2018, Jeff King wrote:
> On Thu, Nov 22, 2018 at 01:48:53PM +0100, Johannes Schindelin wrote:
>
> > So YMMV with git-s. My rule of thumb is: if I want to use this
> > myself only, I'll make it an alias. If I want to ship it (e.g. with Git
> > for Windows), I'll make it a
Hi Pranit,
(Cc:ing Tanushree because they will try to pick up this patch series as
part of the Outreachy program.)
On Mon, 30 Oct 2017, Pranit Bauva wrote:
> On Fri, Oct 27, 2017 at 10:58 PM, Martin Ågren wrote:
> > On 27 October 2017 at 17:06, Pranit Bauva wrote:
> >> +static void
Hi Paul,
On Thu, 22 Nov 2018, Paul Gureghian wrote:
> I installed 2.19.2 on windows 7 , 32 bit and it wont launch.
This has been reported on Gitter and fixed in
https://github.com/git-for-windows/MINGW-packages/commit/deb0395d031401ffe55024fb066267e2ea8d032b
For the time being, please either
Hi GB,
On Fri, 23 Nov 2018 at 04:23, Mgr Georg Black wrote:
>
> Hello everyone.I red git manual but I can't figure out how to propagate
> critical change from master branch to long live develop branch. I red chapter
> about rebasing that I think could solve it but at the end of this chapter is
On Thu, Nov 22, 2018 at 11:17:22AM -0500, Jeff King wrote:
> The script I use is at:
>
> https://github.com/peff/git/blob/meta/stress
>
> which you invoke like "/path/to/stress t5562" from the top-level of a
> git.git checkout. It basically just runs a loop of twice as many
> simultaneous
On Thu, Nov 22, 2018 at 8:28 AM Ævar Arnfjörð Bjarmason
wrote:
> Range-diff:
> By the way, is there any way to
> Pass the equivalent of "git range-diff origin/master topic-2 topic-3"
> to git-format-patch?
git-range-diff documentations says that the three-argument form:
git range-diff
in
>> https://public-inbox.org/git/e5148b8c-9a3a-5d2e-ac8c-3e536c0f2...@web.de/
>> that we should hold off the [89]/9 of this series due to the performance
>> regressions this introduces in some cases (while fixing other cases).
>>
>> I hadn't had time to follow u
series due to the performance
> regressions this introduces in some cases (while fixing other cases).
>
> I hadn't had time to follow up on that, and figured it could wait until
> post-2.20 for a re-roll.
Yeah, my intent had been to circle back around to this, but I just
hadn't gotte
On Mon, Nov 12, 2018 at 11:04:52AM -0800, Stefan Beller wrote:
> > for (odb = the_repository->objects->odb; odb; odb = odb->next) {
> > if (odb->local)
> > return odb->path;
> > }
> > return NULL; /* yikes? */
> >
> > ? That feels like it's making things more
On Thu, Nov 08, 2018 at 01:57:52PM -0500, Jeff Hostetler wrote:
> > Should we simply be disallowing sparse:path filters over upload-pack?
>
> The option to allow an absolute path over the wire probably needs more
> thought as you suggest.
>
> Having it in the traverse code was useful for local
On Sat, Nov 17, 2018 at 11:07:32PM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > I suspect it would be less confusing if the rewrite were inverted, like:
> >
> > [url "gh:"]
> > rewriteTo = https://github.com
> > rewritePrivate
> >
> > [url "git://github.com"]
> > rewriteTo =
Hi Stefan,
On Thu, 22 Nov 2018, stefan.na...@atlas-elektronik.com wrote:
> Just a quick note:
>
> I installed v2.20.0-rc0 with these options:
>
> $ cat /etc/install-options.txt
> Editor Option: VIM
> Custom Editor Path:
> Path Option: Cmd
> SSH Option: OpenSSH
> CURL Option: OpenSSL
> CRLF
we are talking about on the order of 4GB memory savings
there. You need a big machine to handle a repository of that size, but
4GB is still appreciable.
So I guess at this point, with all (known) bugs fixed, we should stick
with it for now. If it becomes a problem for development of a future
feature, then we can re-evaluate then.
-Peff
On Tue, Nov 20, 2018 at 10:06:57AM -0500, Derrick Stolee wrote:
> On 11/20/2018 4:44 AM, Jeff King wrote:
> > In cases like this I think it's often a good idea to have a perf test.
> > Those are expensive anyway, and we'd have the double benefit of
> > exercising the code and showing off the
On Wed, Nov 21, 2018 at 11:28:28AM -0800, Bryan Turner wrote:
> But that test code exists because Bitbucket Server provides a Java API
> [1][2] which allows third-party developers to easily build arbitrary
> Git commands to invoke for their own functionality. Setting
>
On Thu, Nov 22, 2018 at 11:16:38AM +0100, Ævar Arnfjörð Bjarmason wrote:
> > +test_expect_success 'log -G looks into binary files with textconv filter' '
> > + rm -rf .git &&
> > + git init &&
> > + echo "* diff=bin" > .gitattributes &&
> > + printf "a\0b" >data.bin &&
> > + git add
On Wed, Nov 21, 2018 at 09:52:27PM +0100, Thomas Braun wrote:
> diff --git a/diffcore-pickaxe.c b/diffcore-pickaxe.c
> index 69fc55ea1e..8c2558b07d 100644
> --- a/diffcore-pickaxe.c
> +++ b/diffcore-pickaxe.c
> @@ -144,6 +144,11 @@ static int pickaxe_match(struct diff_filepair *p, struct
>
On Thu, Nov 22, 2018 at 02:17:01AM -0800, Carlo Arenas wrote:
> Peff, could you elaborate on your "load testing" setup? which could
> give us any hints
> on what to look for?, FWIW I hadn't been able to reproduce the problem
> anywhere
> else (and not for a lack of trying)
The script I use is
On Thu, Nov 22, 2018 at 01:48:53PM +0100, Johannes Schindelin wrote:
> > So it's maybe do-able, but not quite as trivial as one might hope.
>
> A trivial alternative would be to recommend adding a man page for
> 3rd-party git-s.
>
> In other words, as soon as `git-sizer` is accompanied by
On Wed, Nov 21, 2018 at 6:08 PM Stephen P. Smith wrote:
>
> Picking up someones stalled patch is one thing, picking up Linus' patch is in
> a different league.
No, I think it works the other way - my random patches are likely the
_least_ important ones, simply because I can carry them around in
On Thu, Nov 22, 2018 at 11:58:36AM +0100, Greg Hurrell wrote:
> I was troubleshooting some breakage in some code that consumes the
> output of `git log --raw` and looking on two machines with different
> versions of Git just now I discovered the output format has changed
> somewhere between
Hi Peff,
On Sat, 17 Nov 2018, Jeff King wrote:
> On Fri, Nov 16, 2018 at 08:22:11PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
> > So maybe we should just document this interface better. It seems one
> > implicit dependency is that we expect a manpage for the tool to exist
> > for --help.
>
>
Hi Junio,
On Wed, 21 Nov 2018, Junio C Hamano wrote:
> Оля Тележная writes:
>
> >> I am OK if we avoid PRIdMAX and use PRIuMAX instead with a cast to
> >> the corresponding size in this codepath, as long as we properly
> >> handle negative oi.disk_size field, which may be telling some
> >>
On Thu, Nov 22, 2018 at 11:31 AM Stephen P. Smith wrote:
>
> On Wednesday, November 21, 2018 2:00:16 AM MST Junio C Hamano wrote:
> > [Stalled]
> >
> > * lt/date-human (2018-07-09) 1 commit
> > - Add 'human' date format
> >
> > A new date format "--date=human" that morphs its output depending
>
On Wed, Nov 21, 2018 at 10:37 PM Max Kirillov wrote:
>
> On Wed, Nov 21, 2018 at 05:04:25PM -0800, Carlo Arenas wrote:
> > the last child of its children long gone with an error as shown by :
> >
> > 9255 1 git-http-backend CALL close(1)
> ...
> > 9255 1 git-http-backend CALL
>
On Wed, Nov 21 2018, Thomas Braun wrote:
> The -G option of log looks for the differences whose patch text
> contains added/removed lines that match regex.
>
> The concept of differences only makes sense for text files, therefore
> we need to ignore binary files when searching with -G as
On Wed, Nov 21 2018, Thomas Braun wrote:
> The -S option of log looks for differences that changes the
> number of occurrences of the specified string (i.e. addition/deletion)
> in a file.
>
> Add a test to ensure that we keep looking into binary files with -S
> as changing that would break
On Thu, 22 Nov 2018 at 07:39, Mgr Georg Black wrote:
> Hello everyone.I red git manual but I can't figure out how to propagate
> critical change from master branch to long live develop branch.
Have you considered "using git cherry-pick can be used to backport
changes one by one" [1]
> I red
Just a quick note:
I installed v2.20.0-rc0 with these options:
$ cat /etc/install-options.txt
Editor Option: VIM
Custom Editor Path:
Path Option: Cmd
SSH Option: OpenSSH
CURL Option: OpenSSL
CRLF Option: CRLFCommitAsIs
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use
On Wed, Nov 21, 2018 at 05:04:25PM -0800, Carlo Arenas wrote:
> the error that gets eventually to stderr in the caller comes from
> get_packet_data, who is trying to read 4 bytes and gets 0.
> when looking at the trace (obtained with ktrace)
Yes too early close of the input data is the thing
On Wednesday, November 21, 2018 6:06:13 PM MST Junio C Hamano wrote:
> "Stephen P. Smith" writes:
> > On Wednesday, November 21, 2018 2:00:16 AM MST Junio C Hamano wrote:
> >> [Stalled]
> >>
> >> * lt/date-human (2018-07-09) 1 commit
> >>
> >> - Add 'human' date format
> >>
> >> A new date
Thomas Braun writes:
> The -S option of log looks for differences that changes the
> number of occurrences of the specified string (i.e. addition/deletion)
> in a file.
s/-S /-S/ and
s/the specified string/the specified block of text/ would make it
more in line with how
Thomas Braun writes:
> The -G option of log looks for the differences whose patch text
> contains added/removed lines that match regex.
>
> The concept of differences only makes sense for text files, therefore
> we need to ignore binary files when searching with -G as well.
>
> Signed-off-by:
On Wed, Nov 21, 2018 at 06:38:20PM +0900, Junio C Hamano wrote:
> Denton Liu writes:
>
> > Changes since V3:
> > * Add patch to cleanup 'merge --squash c3 with c7' test in t7600
> > * Use test_i18ncmp instead of test_cmp to pass GETTEXT_POISON tests
>
> Queued. Thanks, both.
I just
"Stephen P. Smith" writes:
> On Wednesday, November 21, 2018 2:00:16 AM MST Junio C Hamano wrote:
>> [Stalled]
>>
>> * lt/date-human (2018-07-09) 1 commit
>> - Add 'human' date format
>>
>> A new date format "--date=human" that morphs its output depending
>> on how far the time is from the
On Wed, Nov 21, 2018 at 2:49 PM Max Kirillov wrote:
>
> On Wed, Nov 21, 2018 at 04:02:04AM -0800, Carlo Arenas wrote:
> > for some tracing, it would seem that it gets 0 when
> > trying to read 4 bytes from what I think is a pipe that connects to a
> > child that has been gone already for a while.
Jeff King writes:
> Yes, there are two ways to write this. With a conditional to initialize
> and return or to return the default, as we have here:
>
>> > >+ if (!git_config_get_bool("index.recordendofindexentries", ))
>> > >+ return val;
>> > >+ return 0;
>
> Or initialize the default
On Wednesday, November 21, 2018 2:00:16 AM MST Junio C Hamano wrote:
> [Stalled]
>
> * lt/date-human (2018-07-09) 1 commit
> - Add 'human' date format
>
> A new date format "--date=human" that morphs its output depending
> on how far the time is from the current time has been introduced.
>
On Wed, Nov 21, 2018 at 2:49 PM Max Kirillov wrote:
>
> Should I install bash for it to work? I cannot say I understand what the
> message is about.
yes, you need to install bash and use SHELL_PATH=/usr/pkg/bin/bash;
PERL_PATH=/usr/pkg/bin/perl for the perl script
Carlo
On Wed, Nov 21, 2018 at 04:02:04AM -0800, Carlo Arenas wrote:
> for some tracing, it would seem that it gets 0 when
> trying to read 4 bytes from what I think is a pipe that connects to a
> child that has been gone already for a while.
Could you clarify it? I'm afraid I don't understand.
Hi Junio,
On Wed, 21 Nov 2018, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
> > A quick fix for a recent topic. Not overly critical, but I would deem this
> > v2.20.0-rc1 material.
> >
> > Johannes Schindelin (1):
> > rebase: warn about the correct tree's OID
>
On 21.11.2018 14:37, Junio C Hamano wrote:
Jeff King writes:
On Wed, Nov 21, 2018 at 10:23:34AM +0100, Marc Strapetz wrote:
From our GUI client we are invoking git operations on a possibly large set
of files. ...
command line length, especially on Windows [1] and OSX [2]. To workaround
hose hangs). I still think it is the right thing to do, but I lack the
time to take care of it within the next weeks. Instead, I will try to run
even the Windows phase in --verbose-log mode so that the --junit-xml code
can pick up the verbose logs right away (read: no more re-running upon
test failures). Hopefully this won't cause a speed regression.
Ciao,
Dscho
On Wed, Nov 21, 2018 at 6:20 AM Jeff King wrote:
>
> On Tue, Nov 20, 2018 at 03:17:07PM -0800, Bryan Turner wrote:
>
> > I've run 2.20.0-rc0 through the test matrix for Bitbucket Server on
> > both Linux and Windows, and the only failures were related to this
> > change:
> >
> > * "git branch -l
> I don't have a strong opinion about whether this would go in the
> design doc. I suppose the doc could have an "implementation plan"
> section describing temporary stopping points on the way to the final
> result, but it's not necessary to include that.
As long as this is something I'm just
On Tue, Nov 20, 2018 at 02:21:51PM +0100, SZEDER Gábor wrote:
> On Tue, Nov 20, 2018 at 08:06:16AM -0500, Ben Peart wrote:
> > >diff --git a/read-cache.c b/read-cache.c
> > >index 4ca81286c0..1e9c772603 100644
> > >--- a/read-cache.c
> > >+++ b/read-cache.c
> > >@@ -2689,6 +2689,15 @@ void
On Mon, Oct 22, 2018 at 06:13:42PM -0700, Matthew DeVore wrote:
> diff --git a/builtin/prune.c b/builtin/prune.c
> index 41230f8215..11284d0bf3 100644
> --- a/builtin/prune.c
> +++ b/builtin/prune.c
> @@ -120,6 +120,7 @@ int cmd_prune(int argc, const char **argv, const char
> *prefix)
>
I think I've got it now; maybe I just needed to sleep on it. It's
happier if I use the whole URL for trunk in the -T parameter.
I'll see how the rest of it plays out, but the `git svn show-ignore
--id=origin/trunk` command is working now.
On Wed, Nov 21, 2018 at 10:45 AM Jamie Jackson wrote:
>
>
On 20/11/2018 18:05, Stefan Beller wrote:
On Fri, Nov 16, 2018 at 3:04 AM Phillip Wood wrote:
From: Phillip Wood
When using --color-moved-ws=allow-indentation-change allow lines with
the same indentation change to be grouped across blank lines. For now
this only works if the blank lines
By the way, my goal is to pull in trunk (only) at first, and possibly
pull in certain branches (later) on an as-needed basis. I'll need to
sync the Git repo with SVN for a while, until we permanently switch to
Git (and put SVN in read-only).
On Wed, Nov 21, 2018 at 10:38 AM Jamie Jackson wrote:
>
ICF2008571:eclipse-workspace jjackson$ git svn clone \
> -r 95115:HEAD https://mydomain.com/svn/HUD/onecpd \
> -T trunk \
> --no-metadata \
> -A ~/eclipse-workspace/scraps/git_migration/users.txt \
> hudx-git-migration
ICF2008571:eclipse-workspace jjackson$ cd hudx-git-migration/
On Wed, Nov 21, 2018 at 08:37:03AM -0500, Jamie Jackson wrote:
> I'm brand new to svn-git and I'm having a problem right out of the
> gate. I suspect I need a different ID, but I have no clue how to get
> it.
>
> Here's the failed attempt:
>
On Tue, Nov 20, 2018 at 03:17:07PM -0800, Bryan Turner wrote:
> I've run 2.20.0-rc0 through the test matrix for Bitbucket Server on
> both Linux and Windows, and the only failures were related to this
> change:
>
> * "git branch -l " used to be a way to ask a reflog to be
>created while
On Wed, Nov 21, 2018 at 03:05:04PM +0100, Nickolai Belakovski wrote:
> I think if we move to making this atom just store worktree path, that
> needs to be implemented as a hashmap of refname->wtpath, which would
> also solve this string_list issue, correct? Just making sure I'm not
> missing
OK, I see 3 votes for cyan and 4-5 people participating in the thread,
so I'll make it cyan in the next revision.
On Tue, Nov 13, 2018 at 3:49 PM Jeff King wrote:
>
> On Mon, Nov 12, 2018 at 06:07:18PM +, Rafael Ascensão wrote:
>
> > On Mon, Nov 12, 2018 at 07:14:23AM -0500, Jeff King wrote:
Hi Junio,
On Wed, 21 Nov 2018, Junio C Hamano wrote:
> Carlo Arenas writes:
>
> > Tested-by: Carlo Marcelo Arenas Belón
> >
> > the C version prepends: "fatal: " unlike the shell version for both
> > error messages
>
> In addition, "Invalid whitespace option" says 'bad', not
>
I think if we move to making this atom just store worktree path, that
needs to be implemented as a hashmap of refname->wtpath, which would
also solve this string_list issue, correct? Just making sure I'm not
missing something before I submit another patch.
On Tue, Nov 13, 2018 at 2:38 AM Junio C
On Wed, Nov 21, 2018 at 02:54:34PM +0100, Marc Gonzalez wrote:
> If I specify the branch to explore, git grep prints a colon instead of
> a slash in the path:
>
> $ git grep arm,coresight-tmc master:Documentation/devicetree
> master:Documentation/devicetree:bindings/arm/coresight.txt:
Jeff King writes:
> On Wed, Nov 21, 2018 at 10:23:34AM +0100, Marc Strapetz wrote:
>
>> From our GUI client we are invoking git operations on a possibly large set
>> of files. ...
>> command line length, especially on Windows [1] and OSX [2]. To workaround
>> this problem we are currently
On Wed, Nov 21, 2018 at 10:23:34AM +0100, Marc Strapetz wrote:
> From our GUI client we are invoking git operations on a possibly large set
> of files. This may result in pathspecs which are exceeding the maximum
> command line length, especially on Windows [1] and OSX [2]. To workaround
> this
Hi Stefan
On 20/11/2018 20:24, Stefan Xenos wrote:
>> If a merge has been cherry-picked we cannot update it as we don't record
>> which parent was used for the pick, however it is probably not a problem
>> in practice - I think it is unusual to amend merges.
>
> I've read and reread that
FWIW the issue goes away when more than 1 CPU is used in NetBSD 8,0
(32-bit) and for some tracing, it would seem that it gets 0 when
trying to read 4 bytes from what I think is a pipe that connects to a
child that has been gone already for a while.
Carlo
On 11/20/2018 12:04 AM, tbo...@web.de wrote:
From: Torsten Bögershausen
Currently the length of data which is stored in memory is stored
in "unsigned long" at many places in the code base.
This is OK when both "unsigned long" and size_t are 32 bits,
(and is OK when both are 64 bits).
On a 64
On 11/20/2018 8:26 PM, SZEDER Gábor wrote:
write_graph_chunk_data(f, GRAPH_OID_LEN, commits.list, commits.nr);
- write_graph_chunk_large_edges(f, commits.list, commits.nr);
+ if (num_large_edges)
+ write_graph_chunk_large_edges(f, commits.list, commits.nr);
On 11/20/2018 10:29 PM, Junio C Hamano wrote:
SZEDER Gábor writes:
I rename these variables to 'num_large_edges', because the commit
graph file format speaks about the 'Large Edge List' chunk.
However, I do find that the term 'extra' makes much more sense
Would it make sense to do the
s://public-inbox.org/git/e5148b8c-9a3a-5d2e-ac8c-3e536c0f2...@web.de/
that we should hold off the [89]/9 of this series due to the performance
regressions this introduces in some cases (while fixing other cases).
I hadn't had time to follow up on that, and figured it could wait until
post-2.20 for a re-roll.
Denton Liu writes:
> Changes since V3:
> * Add patch to cleanup 'merge --squash c3 with c7' test in t7600
> * Use test_i18ncmp instead of test_cmp to pass GETTEXT_POISON tests
Queued. Thanks, both.
On Wed, Nov 21 2018, Jonathan Nieder wrote:
> Junio C Hamano wrote:
>
>> This series has a strong smell of pushing back by the
>> toolsmiths who refuse to promptly upgrade to help their users, and
>> that is why I do not feel entirely happy with this series.
>
> Last reply, I
Junio C Hamano writes:
> I do not know if it makes sense to have 3 and 5 separate; I suspect
> a single patch that does "clarify the warning, and allow those who
> have no choice in which version of Git to choose squelch it" would
> suffice.
I actually do not mind two patches for these, but I
Junio C Hamano writes:
> As the deployed versions of Git will keep sending the wrong message,
> I do not mind applying 1/5 and 2/5, given especially that Ben seems
> to be OK with the plan. I however do not think 3 thru 5 is ready
> yet with this round---there were some discussions on phrasing
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> I don't *think* you intend to say "sure, you got user reports, but
>> (those users are wrong | those users are not real | you are not
>> interpreting those users correctly)", but that is what I am hearing.
>
> What I have been saying is "we are
Jonathan Nieder writes:
> I don't *think* you intend to say "sure, you got user reports, but
> (those users are wrong | those users are not real | you are not
> interpreting those users correctly)", but that is what I am hearing.
What I have been saying is "we are sending a wrong message to
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> Now, a meta point. Throughout this discussion, I have been hoping for
>> some acknowledgement of the problem --- e.g. an "I am sympathetic to
>> what you are trying to do, but ". I wasn't able to find that, and
>> that is part of what
Jeff King writes:
> But in (b), we use the number of stored objects, _not_ the allocated
> size of the objects array. So we can run into a situation like this:
>
> 1. packlist_alloc() needs to store the Nth object, so it grows the
> objects array to M, where M > N.
>
> 2.
"Johannes Schindelin via GitGitGadget"
writes:
> A quick fix for a recent topic. Not overly critical, but I would deem this
> v2.20.0-rc1 material.
>
> Johannes Schindelin (1):
> rebase: warn about the correct tree's OID
>
Yup, it is kind of embarrasing that nobody caught it, but at the
same
Carlo Arenas writes:
> Tested-by: Carlo Marcelo Arenas Belón
>
> the C version prepends: "fatal: " unlike the shell version for both
> error messages
In addition, "Invalid whitespace option" says 'bad', not
'--whitespace=bad', in the builtin version.
I think the following would address both
Jonathan Nieder writes:
> Now, a meta point. Throughout this discussion, I have been hoping for
> some acknowledgement of the problem --- e.g. an "I am sympathetic to
> what you are trying to do, but ". I wasn't able to find that, and
> that is part of what contributed to the feeling of not
SZEDER Gábor writes:
> I rename these variables to 'num_large_edges', because the commit
> graph file format speaks about the 'Large Edge List' chunk.
>
> However, I do find that the term 'extra' makes much more sense and
> fits the concept better (i.e. extra commit graph edges resulting from
>
Stefan Xenos wrote:
> Jonathan Nieder wrote:
>> putting it in the commit message is a way to
>> experiment with the workflow without changing the object format
>
> As long as we're talking about a temporary state of affairs for users
> that have opted in, and we're explicit about the fact that
Junio C Hamano wrote:
> This series has a strong smell of pushing back by the
> toolsmiths who refuse to promptly upgrade to help their users, and
> that is why I do not feel entirely happy with this series.
Last reply, I promise. :)
This sentence might have the key to the
onathan Nieder wrote:
> Junio C Hamano wrote:
>> I am still puzzled by the insistence of 3/5 and this step that wants
>> to kill the coalmine canary. But I am even more puzzled by the
>> first two steps that want to disable the two optional extensions.
[...]
> I acknowledge your puzzlement. I'm
Hi,
Junio C Hamano wrote:
> I am still puzzled by the insistence of 3/5 and this step that wants
> to kill the coalmine canary. But I am even more puzzled by the
> first two steps that want to disable the two optional extensions.
>
> What's so different this time with the new optional
Оля Тележная writes:
>> I am OK if we avoid PRIdMAX and use PRIuMAX instead with a cast to
>> the corresponding size in this codepath, as long as we properly
>> handle negative oi.disk_size field, which may be telling some
>> "unusual" condition to us.
>
> Maybe we want to change the type (from
Ben Peart writes:
>> This message should say something like "Index uses the mandatory %s
>> extension" to clarify and distinguish it from the below. We don't
>> understand the upper-case one either, but the important distinction is
>> that one is mandatory, and the other can be dropped. The two
Jonathan Nieder writes:
>> +Sven Strickroth
>
> Is the above line needed? It's not clear to me from the commit message
> what it does.
Stare at it once again and you'll see ;-) FWIW I needed to do that
myself before you had the same issue.
Sven is trying to hide real-name name and have a
601 - 700 of 100366 matches
Mail list logo
