On Fri, Jul 05, 2019 at 01:14:13AM -0400, Jeff King wrote:
> On Thu, Jul 04, 2019 at 10:13:20PM +0900, Mike Hommey wrote:
>
> > > "public-inbox-index" (reading from git, writing to Xapian+SQLite)
> > > on a dev machine got slow because core count exceeded what SATA
> > > could handle and had to ca
On Fri, Jul 05, 2019 at 01:09:55AM -0400, Jeff King wrote:
> On Thu, Jul 04, 2019 at 07:05:30PM +0900, Mike Hommey wrote:
> > Finally, with 1 thread, the picture changes greatly. The overall process
> > takes 2.5h:
> > - 50 seconds enumerating and counting objects.
> > - ~2.5h compressing objects.
On Thu, Jul 04, 2019 at 10:13:20PM +0900, Mike Hommey wrote:
> > "public-inbox-index" (reading from git, writing to Xapian+SQLite)
> > on a dev machine got slow because core count exceeded what SATA
> > could handle and had to cap the default Xapian shard count to 3
> > by default for v2 inboxes.
On Thu, Jul 04, 2019 at 07:05:30PM +0900, Mike Hommey wrote:
> With 36 threads, the overall process takes 45 minutes:
> - 50 seconds enumerating and counting objects.
> - ~22 minutes compressing objects
> - ~22 minutes writing objects
I noticed the long writing phase when I repacked as well. The
On Thu, Jul 04, 2019 at 07:05:30PM +0900, Mike Hommey wrote:
> My guess is all those stalls are happening when processing the files I
> already had problems with in the past[3], except there are more of them
> now (thankfully, they were removed, so there won't be more, but that
> doesn't make the e
Hello!
Thanks for you answer.
The original content of the file:
--- START ---
LINE 1
LINE 2
LINE 3
--- END —
Branch “change-a” modifies it to become:
--- START ---
LINE 1
LINE 2
LINE 3
LINE 4
LINE 5
LINE 6
LINE 7
LINE 8
LINE 9
--- END —
While branch “change-b”
On Thu, Jul 04, 2019 at 07:05:30PM +0900, Mike Hommey wrote:
> Hi,
>
> I was looking at the disk size of the gecko repository on github[1],
> which started at 4.7GB, and `git gc --aggressive`'d it, which made that
> into 2.0G. But to achieve that required quite some resources.
>
> My first attemp
On Wed, Jul 3, 2019 at 12:51 AM Junio C Hamano wrote:
>
> Duy Nguyen writes:
>
> > I agree, this is not "canceling". I think this series causes conflicts
> > with pw/clean-sequencer-state-upon-final-commit and the warning is
> > accidentally enabled (partly my fault since I named the argument
> >
On Fri, Jul 5, 2019 at 3:01 AM SZEDER Gábor wrote:
>
> On Mon, Jun 24, 2019 at 08:02:21PM +0700, Nguyễn Thái Ngọc Duy wrote:
> > diff --git a/t/t3011-ls-files-json.sh b/t/t3011-ls-files-json.sh
> > index 082fe8e966..dbb572ce9d 100755
> > --- a/t/t3011-ls-files-json.sh
> > +++ b/t/t3011-ls-files-js
On Wed, Jul 03 2019, Karsten Blees via GitGitGadget wrote:
> From: Karsten Blees
>
> On native Windows, Git exclusively uses UTF-8 for console output (both
> with MinTTY and native Win32 Console). Gettext uses `setlocale()` to
> determine the output encoding for translated text, however, MSVCRT
Duy Nguyen writes:
> On Mon, Jul 1, 2019 at 10:32 PM Derrick Stolee via GitGitGadget
> wrote:
>> @@ -601,3 +602,22 @@ core.abbrev::
>> in your repository, which hopefully is enough for
>> abbreviated object names to stay unique for some time.
>> The minimum length is 4.
>>
A quick fix for a patch that is already in next.
Johannes Schindelin (1):
mingw: fix possible buffer overrun when calling `GetUserNameW()`
compat/mingw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
base-commit: 94238859b9809afc806919cb7022a45cdc8e6748
Published-As:
https://github.
From: Johannes Schindelin
In 39a98e9b68b8 (mingw: get pw_name in UTF-8 format, 2019-06-27), this
developer missed the fact that the `GetUserNameW()` function takes the
number of characters as `len` parameter, not the number of bytes.
Reported-by: Beat Bolli
Signed-off-by: Johannes Schindelin
-
Hi Dscho
On 04.07.19 23:52, Johannes Schindelin wrote:
> Hi Beat,
>
> On Thu, 4 Jul 2019, Beat Bolli wrote:
>
>> On 27.06.19 11:37, Johannes Schindelin via GitGitGadget wrote:
>>> From: Johannes Schindelin
>>>
>>> Previously, we would have obtained the user name encoded in whatever the
>>> curr
Hi Beat,
On Thu, 4 Jul 2019, Beat Bolli wrote:
> On 27.06.19 11:37, Johannes Schindelin via GitGitGadget wrote:
> > From: Johannes Schindelin
> >
> > Previously, we would have obtained the user name encoded in whatever the
> > current code page is.
> >
> > Note: the "user name" here does not den
Hi Matheus,
On Thu, 4 Jul 2019, Matheus Tavares Bernardino wrote:
> On Thu, Jul 4, 2019 at 7:02 AM Johannes Schindelin
> wrote:
> >
> > On Wed, 3 Jul 2019, Junio C Hamano wrote:
> >
> > > * mt/dir-iterator-updates (2019-06-25) 10 commits
> [...]
> > > Is this ready for 'next'?
> >
> > No. It st
We’d like to contract your services for a period of 12 months. Please advise if
you are open to new opportunities.
Regards,
SAKI NISHIYO
On 27.06.19 11:37, Johannes Schindelin via GitGitGadget wrote:
> From: Johannes Schindelin
>
> Previously, we would have obtained the user name encoded in whatever the
> current code page is.
>
> Note: the "user name" here does not denote the full name but instead the
> short logon name.
>
> Si
On Mon, Jun 24, 2019 at 08:02:21PM +0700, Nguyễn Thái Ngọc Duy wrote:
> diff --git a/t/t3011-ls-files-json.sh b/t/t3011-ls-files-json.sh
> index 082fe8e966..dbb572ce9d 100755
> --- a/t/t3011-ls-files-json.sh
> +++ b/t/t3011-ls-files-json.sh
> @@ -44,4 +44,18 @@ test_expect_success 'ls-files --json,
Add me as a friend on YouTube!
https://youtu.be/addme/XKCI7csVyvjM28bUorQkowm-XUNqwQ
gabriel...@gmail.com
Check out this playlist on YouTube:
http://www.youtube.com/watch?v=LTseTg48568&list=RDLTseTg48568
gabriel...@gmail.com
Hi, Dscho
On Thu, Jul 4, 2019 at 7:02 AM Johannes Schindelin
wrote:
>
> Hi Junio,
>
> On Wed, 3 Jul 2019, Junio C Hamano wrote:
>
> > * mt/dir-iterator-updates (2019-06-25) 10 commits
[...]
> > Is this ready for 'next'?
>
> No. It still breaks many dozens of test cases on Windows (if not more)
>
On Thu, Jul 04, 2019 at 12:04:11PM +, Eric Wong wrote:
> Mike Hommey wrote:
> > I'm puzzled by the fact writing objects is so much faster with 1 thread.
>
> I/O contention in the multi-threaded cases?
>
> "public-inbox-index" (reading from git, writing to Xapian+SQLite)
> on a dev machine go
Mike Hommey wrote:
> I'm puzzled by the fact writing objects is so much faster with 1 thread.
I/O contention in the multi-threaded cases?
"public-inbox-index" (reading from git, writing to Xapian+SQLite)
on a dev machine got slow because core count exceeded what SATA
could handle and had to cap
Hi Dscho,
On Thu, Jul 04, 2019 at 12:38:44PM +0200, Johannes Schindelin wrote:
> On Thu, 4 Jul 2019, Heiko Voigt wrote:
[...]
> > Signed-off-by: Heiko Voigt
>
> Good description.
Thanks. I am actually surprised that for almost 5 years nobody noticed
this. It seems either nobody is using --not t
Oops, I missed Junio's message [1] while looking through my backlog.
Sorry for the noise.
Philip
On 04/07/2019 11:40, Philip Oakley wrote:
If all the issues are cleared then I believe it is a case of providing
a clean reroll (maybe identical to previous..) to Junio and the list
to confirm that
On 27/06/2019 18:10, Dr. Adam Nielsen wrote:
On 25.06.19 13:31, Philip Oakley wrote:
only one minor point...
>>> + - For example, a pattern `doc/frotz/` matches `doc/frotz`
directory,
>>> + but not `a/doc/frotz` directory; however `frotz/` matches `frotz`
>
> her I misread this as: "but
Hi Heiko,
On Thu, 4 Jul 2019, Heiko Voigt wrote:
> In commit 4d5e1b1319 ("gitk: Show detached HEAD if --all is specified",
> 2014-09-09) the intention was to have detached HEAD shown when the --all
> argument is given.
>
> This was solved by appending HEAD to the revs list. By doing that the
> be
Hi,
I was looking at the disk size of the gecko repository on github[1],
which started at 4.7GB, and `git gc --aggressive`'d it, which made that
into 2.0G. But to achieve that required quite some resources.
My first attempt failed with OOM, on an AWS instance with 16 cores and
32GB RAM. I then we
Hi Junio,
On Wed, 3 Jul 2019, Junio C Hamano wrote:
> * mt/dir-iterator-updates (2019-06-25) 10 commits
> - clone: replace strcmp by fspathcmp
> - clone: use dir-iterator to avoid explicit dir traversal
> - clone: extract function from copy_or_link_directory
> - clone: copy hidden paths at lo
On 03/07/2019 23:28, Junio C Hamano wrote:
> 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 hol
On 02/07/2019 18:23, Junio C Hamano wrote:
> Phillip Wood writes:
>
>>> As long as sed implementation used here does not do anything funny
>>> to CR, I think the approach to strip everything before the last CR
>>> on the line is sensible. As I am not familiar with how Windows port
>>> of sed wan
From: Phillip Wood
Some of the tests check the output of rebase is what we expect. These
were added after a regression that added unwanted stash output when
using --autostash. They are useful as they prevent unintended changes to
the output of the various rebase commands. However they also includ
Remove ugliness in the tests that check the output of git rebase
I've updated this to avoid repeated calls to printf as suggested by Junio
Based-On: sg/rebase-progress
Phillip Wood (1):
t3420: remove progress lines before comparing output
t/t3420-rebase-autostash.sh | 19 +++
Hi Junio,
On Wed, 3 Jul 2019, Junio C Hamano wrote:
> * ab/no-kwset (2019-07-01) 10 commits
> - grep: use PCRE v2 for optimized fixed-string search
> - grep: remove the kwset optimization
> - grep: drop support for \0 in --fixed-strings
> - grep: make the behavior for NUL-byte in patterns sa
Hi Junio,
On Wed, 3 Jul 2019, Junio C Hamano wrote:
> * nd/index-dump-in-json (2019-06-26) 11 commits
> - SQUASH???
> - t3008: use the new SINGLE_CPU prereq
> - read-cache.c: dump "IEOT" extension as json
> - read-cache.c: dump "EOIE" extension as json
> - resolve-undo.c: dump "REUC" extensi
Hi Junio,
On Wed, 3 Jul 2019, Junio C Hamano wrote:
> * kb/windows-force-utf8 (2019-06-27) 1 commit
> - gettext: always use UTF-8 on native Windows
>
> Windows update.
>
> On hold.
> cf.
I submitted v2 in
https://public-inbox.org/git/pull.217.v2.git.gitgitgad...@gmail.com which
should addre
The environment variable HOME is a well-known concept on Unix/Linux, but not
so much on Windows. In fact, there are competing concepts, and they fulfill
separate roles.
Let's try to map the closest that we can find to HOME so that Git is happy.
Git for Windows carries this patch since 2015, so I
From: Karsten Blees
HOME initialization was historically duplicated in many different places,
including /etc/profile, launch scripts such as git-bash.vbs and gitk.cmd,
and (although slightly broken) in the git-wrapper.
Even unrelated projects such as GitExtensions and TortoiseGit need to
impleme
On Windows, it is not possible to overwrite a file as long as any process
holds a read handle to it. Even keeping regions memory-mapped prevents that.
When git difftool calls git diff, it might be the user's intention to write
the file(s) via the diff tool, so let's make sure that they are not
mem
From: Johannes Schindelin
When running an external diff from, say, a diff tool, it is safe to
assume that we want to write the files in question. On Windows, that
means that there cannot be any other process holding an open handle to
said files.
So let's make sure that `git diff` itself is not h
From: Johannes Schindelin
A `+` is not a valid part of a filename with Windows file systems (it is
reserved because the `+` operator meant file concatenation back in the
DOS days).
When building in Git for Windows' SDK, the `make.exe` that interprets
our `Makefile` is an MSYS2 program, which use
The + is not allowed on NTFS filesystems. Even if the MSYS2 make/bash we use
to build Git for Windows can work around it, it is not necessary.
Johannes Schindelin (1):
Avoid illegal filenames when building Documentation on NTFS
Documentation/Makefile | 88 +-
Hi Emily,
On Wed, 3 Jul 2019, Emily Shaffer wrote:
> On Wed, Jul 03, 2019 at 09:41:46PM +0200, Johannes Schindelin wrote:
>
> > On Wed, 3 Jul 2019, Emily Shaffer wrote:
> >
> > > > > + up="$HTTPD_URL"/smart/atomic-branches.git &&
> > > > > + test_commit atomic1 &&
> > > > > + test_com
In commit 4d5e1b1319 ("gitk: Show detached HEAD if --all is specified",
2014-09-09) the intention was to have detached HEAD shown when the --all
argument is given.
This was solved by appending HEAD to the revs list. By doing that the
behavior using the --not argument is now broken, since that inve
Hello,
Is your email account good enough for a private discussion? I want to
discuss a business transaction with you.
Mr. Wilbert.
.
Hola,
¿Su cuenta de correo electrónico es lo suficientemente buena para una discusi
46 matches
Mail list logo
