When OE_IN_PACK_BITS was added, we didn't have many bits left to spare
so the max number of packs that pack-objects could handle was limited
to 256. Now we have more spare bits, let's increase it to 4096 to be
on the safe side. If you have more than this many packs, you may need
to reconsider if
Signed-off-by: Nguyễn Thái Ngọc Duy
---
pack-objects.h | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/pack-objects.h b/pack-objects.h
index f339f0411a..52087b32e5 100644
--- a/pack-objects.h
+++ b/pack-objects.h
@@ -33,12 +33,10 @@ struct
The array of object_entry in pack-objects can take a lot of memory
when pack-objects is run in "pack everything" mode. On linux-2.6.git,
this array alone takes roughly 800MB.
This series reorders some fields and reduces field size... to keep
this struct smaller. Its size goes from 136 bytes to 96
On Wed, Feb 28, 2018 at 06:22:33PM +, Eric Wong wrote:
> Duy Nguyen wrote:
> > which saves 12 bytes (or another 74 MB). 222 MB total is plenty of
> > space to keep some file cache from being evicted.
>
> Nice! I can definitely benefit from lower memory usage when
>
On 1 March 2018 at 08:36, Jeff King wrote:
> On Wed, Feb 28, 2018 at 05:51:14PM +0100, demerphq wrote:
>
>> I would look into putting it into a module and then using the PERL5OPT
>> environment var to have it loaded automagically in any of your perl
>> scripts.
>>
>> For instance
Instead of using 8 bytes (on 64 bit arch) to store a pointer to a
pack. Use an index isntead since the number of packs should be
relatively small.
This limits the number of packs we can handle to 256 (still
unreasonably high for a repo to work well). If you have more than 256
packs, you'll need
We do a linear search for in_pack index in create_object_entry(). This
function is called for every available object in the worst case (and
on linux-2.6.git, that's about 6.5M). Try to avoid that by saving the
index in packed_git. Since we should not have zillions of packs, this
extra space should
Notice that packing_data::nr_objects is uint32_t, we could only handle
maximum 4G objects and can address all of them with an uint32_t. If we
use a pointer here, we waste 4 bytes on 64 bit architecture.
Convert these delta pointers to indexes. Since we need to handle NULL
pointers as well, the
This does not give us any saving due to padding. But we will be able
to save once we cut 4 bytes out of this struct in a subsequent patch.
Because of struct packing from now on we can only handle max depth
4095 (or even lower when new booleans are added in this struct). This
should be ok since
This field is only need for pack-bitmap, which is an optional
feature. Move it to a separate array that is only allocated when
pack-bitmap is used (it's not freed in the same way that objects[] is
not). This saves us 8 bytes in struct object_entry.
Signed-off-by: Nguyễn Thái Ngọc Duy
This saves 8 bytes in sizeof(struct object_entry). On a large
repository like linux-2.6.git (6.5M objects), this saves us 52MB
memory.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/pack-objects.c | 14 --
cache.h| 2 ++
object.h |
Signed-off-by: Nguyễn Thái Ngọc Duy
---
pack-objects.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/pack-objects.h b/pack-objects.h
index 03f1191659..720a8e8756 100644
--- a/pack-objects.h
+++ b/pack-objects.h
@@ -28,6 +28,7 @@ struct object_entry {
unsigned
Object header in a pack is packed really tight (see
pack-format.txt). Even with 8 bytes length, we need 9-10 bytes most,
plus a hash (20 bytes). Which means this field only needs to store a
number as big as 32 (5 bits).
This is trickier to pack tight though since a new hash algorithm is
coming,
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/pack-objects.c | 3 +++
pack-objects.h | 33 -
2 files changed, 23 insertions(+), 13 deletions(-)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index fd217cb51f..a4dbb40824
pack-objects could be a big memory hog especially on large repos,
everybody knows that. The suggestion to stick a .keep file on the
largest pack to avoid this problem is also known for a long time.
Let's do the suggestion automatically instead of waiting for people to
come to Git mailing list and
The series [1] I just sent helps reduce pack-objects memory footprint
a bit. But even then it's still a huge memory hog. So this patch makes
a special treatment for gc --auto: avoid it completely.
The trick here is not new (pinning the largest pack with a .keep
file). It's just never done
On Thu, Mar 01 2018, Nguyễn Thái Ngọc Duy jotted:
> The array of object_entry in pack-objects can take a lot of memory
> when pack-objects is run in "pack everything" mode. On linux-2.6.git,
> this array alone takes roughly 800MB.
>
> This series reorders some fields and reduces field size... to
In git-gui, we can hit CTRL/CMD+ENTER to create a commit. However,
using the numpad ENTER does not invoke the same command.
I propose that both numpad ENTER and "regular" ENTER should invoke the
same command.
On Thu, Mar 01, 2018 at 04:10:48PM +0700, Nguyễn Thái Ngọc Duy wrote:
> Instead of using 8 bytes (on 64 bit arch) to store a pointer to a
> pack. Use an index isntead since the number of packs should be
> relatively small.
>
> This limits the number of packs we can handle to 256 (still
>
On 3/1/2018 2:42 AM, Jeff King wrote:
On Wed, Feb 28, 2018 at 01:27:03PM -0800, Junio C Hamano wrote:
Somehow this topic has been hanging without getting further
attention for too long. It's time to wrap it up and moving it
forward. How about this?
-- >8 --
From: Junio C Hamano
---
git-gui/git-gui.sh | 1 +
1 file changed, 1 insertion(+)
diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
index 91c00e648..6de74ce63 100755
--- a/git-gui/git-gui.sh
+++ b/git-gui/git-gui.sh
@@ -3867,6 +3867,7 @@ bind . <$M1B-Key-equal> {show_more_context;break}
bind .
On March 1, 2018 2:36 AM, Jeff King wrote:
> On Wed, Feb 28, 2018 at 05:51:14PM +0100, demerphq wrote:
>
> > I would look into putting it into a module and then using the PERL5OPT
> > environment var to have it loaded automagically in any of your perl
> > scripts.
> >
> > For instance if you put
2018-02-28 16:25 GMT+03:00 Jeff King :
> On Sun, Feb 25, 2018 at 09:28:25PM +0300, Оля Тележная wrote:
>
>> I am trying to remove cat-file formatting part and reuse same
>> functionality from ref-filter.
>> I have a problem that cat-file sometimes needs to continue running
>> even
From: Phillip Wood
When a hunk is skipped by add -i the offsets of subsequent hunks are
not adjusted to account for any missing insertions due to the skipped
hunk. Most of the time this does not matter as apply uses the context
lines to apply the subsequent hunks in
From: Phillip Wood
I've fixed the second patch to match what was in pu and added some
extra code to patch 4 to handle zero sha1 hashes where the length
varies.
Cover letter to v1:
While working on a patch series to stage selected lines from a hunk
without having to
From: Phillip Wood
This code is duplicated in a couple of places so make it into a
function as we're going to add some more callers shortly.
Signed-off-by: Phillip Wood
---
git-add--interactive.perl | 21 +++--
1 file
From: Phillip Wood
Recount the number of preimage and postimage lines in a hunk after it
has been edited so any change in the number of insertions or deletions
can be used to adjust the offsets of subsequent hunks. If an edited
hunk is subsequently split then the
From: Phillip Wood
When a file has no trailing new line at the end diff records this by
appending "\ No newline at end of file" below the last line of the
file. This line should not be counted in the hunk header. Fix the
splitting and coalescing code to count files
From: Phillip Wood
Use a filter when comparing diffs to fix the value of non-zero hashes
in diff index lines so we're not hard coding sha1 hash values in the
expected output. This makes it easier to change the expected output if
a test is edited as we don't need to
From: Phillip Wood
Indent here documents in line with the current style for tests.
While at it, quote the end marker of here-docs that do not use
variable interpolation.
Signed-off-by: Phillip Wood
Signed-off-by: Junio C Hamano
From: Phillip Wood
Now that add -p counts patches properly it should be possible to turn
off the '--recount' option when invoking 'git apply'
Signed-off-by: Phillip Wood
---
Notes:
I can't think of a reason why this shouldn't be OK
From: Phillip Wood
Simplify things slightly by using the above helpers.
Signed-off-by: Phillip Wood
---
Notes:
changes since v2
- fixed use of test_set_editor to match what was in pu
t/t3701-add-interactive.sh | 33
Hi Junio
On 28/02/18 15:37, Junio C Hamano wrote:
> Phillip Wood writes:
>
>> Is there an easy way for contributors to compare the branch they post to
>> what ends up it pu?
>
> Distributed work is pretty much symmetric, so it can be done the
> same way as one would
This adds xfuncname and word_regex patterns for golang, a quite
popular programming language. It also includes test cases for the
xfuncname regex (t4018) and updated documentation.
The xfuncname regex finds functions, structs and interfaces. Although
the Go language prohibits the opening brace
On Thu, Mar 01 2018, Nguyễn Thái Ngọc Duy jotted:
> pack. Use an index isntead since the number of packs should be
s/isntead/instead/
> This limits the number of packs we can handle to 256 (still
> unreasonably high for a repo to work well). If you have more than 256
> packs, you'll need an
From: Phillip Wood
Since commit 8cbd431082 ("git-add--interactive: replace hunk
recounting with apply --recount", 2008-7-2) if a hunk is skipped then
we rely on the context lines to apply subsequent hunks in the right
place. While this works most of the time it is
On 1 March 2018 at 16:08, Jeff King wrote:
> On Thu, Mar 01, 2018 at 09:28:31AM -0500, Randall S. Becker wrote:
>
>> > It's not clear to me though if we just want to tweak the programs run in
>> > the
>> > test scripts in order to get test_must_fail to stop complaining, or if we
On Thu, Mar 01, 2018 at 02:17:09PM +0300, Оля Тележная wrote:
> >> I tried to replace all die("...") with `return error("...")` and
> >> finally exit(), but actual problem is that we print "error:..."
> >> instead of "fatal:...", and it looks funny.
> >
> > If you do that, then
Phillip Wood writes:
> Thanks for the tips, tbdiff looks useful (I just need to learn to read
> diffs of diffs!). I also find rebasing them on a common ancestor useful
> but its a bit tedious.
Yes, comparing two versions of a series is somewhat unusual and
needs
On Thu, Mar 01, 2018 at 09:28:31AM -0500, Randall S. Becker wrote:
> > It's not clear to me though if we just want to tweak the programs run in the
> > test scripts in order to get test_must_fail to stop complaining, or if we
> > consider the unusual exit codes from our perl-based Git programs to
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
Junio C Hamano writes:
> Brandon Williams writes:
>
>> One of the design goals of protocol-v2 is to improve the semantics of
>> flush packets. Currently in protocol-v1, flush packets are used both to
>> indicate a break in a list of packet lines as well as
On 1 March 2018 at 20:24, Junio C Hamano wrote:
> Jeff King writes:
>
>> IMHO the result is easier to follow. Except for one case:
>>
>>> [...]
>>
>> where I think the logic just ends up repeating itself.
>
> Yup, this one I also had a bit of trouble with.
Brandon Williams writes:
> +enum packet_read_status packet_reader_read(struct packet_reader *reader)
> +{
> + if (reader->line_peeked) {
> + reader->line_peeked = 0;
> + return reader->status;
> + }
> +
> + reader->status =
Brandon Williams writes:
> I've tried to keep building on the same base that I started with when
> sending out a new version of series, mostly because I thought it was
> easier to see what was different between rounds.
Yes. It indeed is easier to see the evolution if the
On 03/01, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Brandon Williams writes:
> >
> >> One of the design goals of protocol-v2 is to improve the semantics of
> >> flush packets. Currently in protocol-v1, flush packets are used both to
> >>
Brandon Williams writes:
> Documentation/technical/protocol-v2.txt | 171
Unlike other things in Documentation/technical/, this is not listed
on TECH_DOCS list in Documentation/Makefile. Shouldn't it be?
On 03/01, Junio C Hamano wrote:
> Brandon Williams writes:
>
> > Lots of changes since v3 (well more than between v2 and v3). Thanks for
> > all of the reviews on the last round, the series is getting more
> > polished.
> >
> > * Eliminated the "# service" line from the
Jeff King writes:
> IMHO the result is easier to follow. Except for one case:
>
>> -if (active_cache_changed || force_write) {
>> -if (newfd < 0) {
>> -if (refresh_args.flags & REFRESH_QUIET)
>> -exit(128);
>> -
Phillip Wood writes:
> From: Phillip Wood
>
> Recount the number of preimage and postimage lines in a hunk after it
> has been edited so any change in the number of insertions or deletions
> can be used to adjust the offsets of subsequent
Brandon Williams writes:
> Factor out the logic for processing shallow, deepen, deepen_since, and
> deepen_not lines into their own functions to simplify the
> 'receive_needs()' function in addition to making it easier to reuse some
> of this logic when implementing
Brandon Williams writes:
> Remove code duplication and use the existing 'get_refs_via_connect()'
> function to retrieve a remote's heads in 'fetch_refs_via_pack()' and
> 'git_transport_push()'.
>
> Signed-off-by: Brandon Williams
> ---
> transport.c | 18
Brandon Williams writes:
> One of the design goals of protocol-v2 is to improve the semantics of
> flush packets. Currently in protocol-v1, flush packets are used both to
> indicate a break in a list of packet lines as well as an indication that
> one side has finished
Andrei Rybak writes:
> On 01.03.2018 0:54, Junio C Hamano wrote:
>> Andrei Rybak writes:
>>
>>> Is this part of guidelines obsolete, or am I not understanding this
>>> correctly?
>>
>> I am merely being nice (but only on "time-permitting" basis).
>
>
Junio C Hamano writes:
> Leah Neukirchen writes:
>
>> NO_COLOR (http://no-color.org/) is a comprehensive approach to disable
>> colors by default for all tools:
>
> The list of software that supports that "convention" is, eh,
> respectable. Is it really a
We (Git devs at Microsoft) have had several people start contributing to
Git over the past few years (I'm the most-recent addition). As we
on-boarded to Git development on our Windows machines, we collected our
setup steps on an internal wiki page.
Now, we'd like to make that document
On Thu, Mar 1, 2018 at 9:39 AM, Birger Skogeng Pedersen
wrote:
> ---
Please sign-off on your patch. See Documentation/SubmittingPatches.
Also, it would be helpful to write at least a short commit message
justifying the change. The reason you gave in your lead-in email[1]
On 01.03.2018 0:54, Junio C Hamano wrote:
> Andrei Rybak writes:
>
>> Is this part of guidelines obsolete, or am I not understanding this
>> correctly?
>
> I am merely being nice (but only on "time-permitting" basis).
>
Does that mean that the integration of a series is
On Wed, Feb 28, 2018 at 7:44 AM, Дилян Палаузов
wrote:
> A (branch master) and
> B (branch g) which is a worktree of the first.
>
> /git/B g>$ git fetch
> [...]
> From https://...
>13e4c55a0..02655d5fb g -> origin/g
>c37a3ca25..bc7888511 master ->
Hi,
Stefan Beller wrote:
> $ git hash-object --stdin -w -t commit < tree c70b4a33a0089f15eb3b38092832388d75293e86
> parent 105d5b91138ced892765a84e771a061ede8d63b8
> author Stefan Beller 1519859216 -0800
> committer Stefan Beller 1519859216 -0800
> tree
Phillip Wood writes:
> From: Phillip Wood
>
> Now that add -p counts patches properly it should be possible to turn
> off the '--recount' option when invoking 'git apply'
Sounds good ;-)
Nguyễn Thái Ngọc Duy writes:
> This does not give us any saving due to padding. But we will be able
> to save once we cut 4 bytes out of this struct in a subsequent patch.
>
> Because of struct packing from now on we can only handle max depth
> 4095 (or even lower when new
Stefan Beller writes:
> $ git hash-object --stdin -w -t commit < tree c70b4a33a0089f15eb3b38092832388d75293e86
> parent 105d5b91138ced892765a84e771a061ede8d63b8
> author Stefan Beller 1519859216 -0800
> committer Stefan Beller
Leah Neukirchen writes:
> You are right in calling this out an emerging new thing, but the
> second list of that page proves that it will be useful to settle on a
> common configuration, and my hope is by getting a few popular projects
> on board, others will soon follow. It
Phillip Wood writes:
> @@ -887,8 +892,8 @@ sub merge_hunk {
> $o_cnt = $n_cnt = 0;
> for ($i = 1; $i < @{$prev->{TEXT}}; $i++) {
> my $line = $prev->{TEXT}[$i];
> - if ($line =~ /^\+/) {
> - $n_cnt++;
> +
Nguyễn Thái Ngọc Duy writes:
> Notice that packing_data::nr_objects is uint32_t, we could only handle
> maximum 4G objects and can address all of them with an uint32_t. If we
> use a pointer here, we waste 4 bytes on 64 bit architecture.
>
> Convert these delta pointers to
Hello,
/git/A/.git/worktrees/b/ is missing - that is the point.
/git/B/,git wasn't modified since the worktree was created, cat:
gitdir: /git/A/.git/worktrees/b
Regards
Дилян
On 03/01/18 19:09, Eric Sunshine wrote:
On Wed, Feb 28, 2018 at 7:44 AM, Дилян Палаузов
On Thu, Mar 1, 2018 at 2:24 PM, Дилян Палаузов
wrote:
> /git/A/.git/worktrees/b/ is missing - that is the point.
> /git/B/,git wasn't modified since the worktree was created, cat:
> gitdir: /git/A/.git/worktrees/b
I'll assume that the lowercase 'b' was a typo in your
Nguyễn Thái Ngọc Duy writes:
> Instead of using 8 bytes (on 64 bit arch) to store a pointer to a
> pack. Use an index isntead since the number of packs should be
> relatively small.
>
> This limits the number of packs we can handle to 256 (still
> unreasonably high for a repo
Brandon Williams writes:
> Lots of changes since v3 (well more than between v2 and v3). Thanks for
> all of the reviews on the last round, the series is getting more
> polished.
>
> * Eliminated the "# service" line from the response from an HTTP
>server. This means
Jacob Keller writes:
> How does this let you defer a conflict? A future commit which modified
> blobs in that tree wouldn't know what version of the trees/blobs to
> actually use? Clearly future commits could record their own trees, but
> how would they generate the
Nguyễn Thái Ngọc Duy writes:
> pack-objects could be a big memory hog especially on large repos,
> everybody knows that. The suggestion to stick a .keep file on the
> largest pack to avoid this problem is also known for a long time.
Yup, but not that it is not "largest"
On Thu, Mar 1, 2018 at 6:19 AM, Alban Gruin wrote:
> This adds xfuncname and word_regex patterns for golang, a quite
> popular programming language. It also includes test cases for the
> xfuncname regex (t4018) and updated documentation.
>
> The xfuncname regex finds
On Fri, Mar 2, 2018 at 3:14 AM, Eric Sunshine wrote:
> As far as I know, there isn't any code in Git which would
> automatically remove the .git/worktrees/B directory, so it's not clear
> how that happened.
"git worktree prune" does, which is called by "git gc" and that
Commit fcfba37337 ('ref-filter: make "--contains " less chatty if
is invalid', 2018-02-23), removed the last use of the callback
function parse_opt_commits(). Remove this function declaration and
definition, since it is now dead code.
Signed-off-by: Ramsay Jones
Brandon Williams writes:
> On 03/01, Junio C Hamano wrote:
> ...
>> Hmph, strictly speaking, the "delim" does not have to be a part of
>> how packetized stream is defined. As long as we stop abusing flush
>> as "This is merely an end of one segment of what I say." and make it
On Fri, Mar 2, 2018 at 1:14 AM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> pack-objects could be a big memory hog especially on large repos,
>> everybody knows that. The suggestion to stick a .keep file on the
>> largest pack to avoid this
Ramsay Jones wrote:
> Commit fcfba37337 ('ref-filter: make "--contains " less chatty if
> is invalid', 2018-02-23), removed the last use of the callback
> function parse_opt_commits(). Remove this function declaration and
> definition, since it is now dead code.
>
> Signed-off-by: Ramsay Jones
On Thu, Mar 1, 2018 at 9:49 PM, Jeff King wrote:
> On Thu, Mar 01, 2018 at 04:10:48PM +0700, Nguyễn Thái Ngọc Duy wrote:
>
>> Instead of using 8 bytes (on 64 bit arch) to store a pointer to a
>> pack. Use an index isntead since the number of packs should be
>> relatively small.
>>
Hi Sergey,
On 01/03/2018 06:39, Sergey Organov wrote:
>
> > > (3) ---X1---o---o---o---o---o---X2
> > >|\ |\
> > >| A1---A2---A3---U1 | A1'--A2'--A3'--U1'
> > >| \ |
> > >| M |
> > >|
First, background. I encountered a bug on Debian Stretch, using this
git version:
$ git --version
git version 2.11.0
The bug is that in the midst of running
git -c interactive.diffFilter="git diff --word-diff --color" add --patch
and after having answered "y" to some patches and "n" to
On Thu, Mar 1, 2018 at 8:33 PM, Ævar Arnfjörð Bjarmason
wrote:
>
> On Thu, Mar 01 2018, Nguyễn Thái Ngọc Duy jotted:
>
>> The array of object_entry in pack-objects can take a lot of memory
>> when pack-objects is run in "pack everything" mode. On linux-2.6.git,
>> this array
Tonight's build had a sparse warning and an additional ./static-check.pl
symbol appear on the 'next' branch. As you know, I like to catch these
on the 'pu' branch before they graduate to 'next', but it seems that I
missed these! :( (The 'pu' branch is quite noisy with regard to sparse
and
Hi,
Ramsay Jones wrote:
> Commit fcfba37337 ('ref-filter: make "--contains " less chatty if
> is invalid', 2018-02-23) added the add_str_to_commit_list()
> function, which causes sparse to issue a "... not declared. Should it
> be static?" warning for that symbol.
Thanks for catching it!
> In
Commit fcfba37337 ('ref-filter: make "--contains " less chatty if
is invalid', 2018-02-23) added the add_str_to_commit_list()
function, which causes sparse to issue a "... not declared. Should it
be static?" warning for that symbol.
In order to suppress the warning, mark that function as
hihttp://bit.ly/2oxaeuW William Broady
Hi Igor,
Igor Djordjevic writes:
> Hi Sergey,
>
> On 01/03/2018 06:39, Sergey Organov wrote:
[...]
>>
>> Yeah, I now see it myself. I'm sorry for being lazy and not inspecting
>> this more carefully in the first place.
>
> No problem, that`s why we`re discussing
Hi,
Derrick Stolee wrote:
> Now, we'd like to make that document publicly available. These steps are
> focused on a Windows user, so we propose putting them in the
> git-for-windows/git repo under CONTRIBUTING.md. I have a pull request open
> for feedback [1]. I'll read comments on that PR or in
Hi,
Sam Kuper wrote:
> First, background. I encountered a bug on Debian Stretch, using this
> git version:
>
> $ git --version
> git version 2.11.0
>
> The bug is that in the midst of running
>
> git -c interactive.diffFilter="git diff --word-diff --color" add --patch
>
> and after having
When the NO_COLOR environment variable is set to any value, default to
disabling color, i.e. resolve 'auto' to false.
NO_COLOR (http://no-color.org/) is a comprehensive approach to disable
colors by default for all tools:
> All command-line software which outputs text with ANSI color added
>
Leah Neukirchen writes:
> NO_COLOR (http://no-color.org/) is a comprehensive approach to disable
> colors by default for all tools:
The list of software that supports that "convention" is, eh,
respectable. Is it really a "convention" yet, or yet another thing
the user needs to
I just wanted to follow up -- what do you think?
On Thu, Feb 22, 2018 at 9:21 PM, Josh Tepper wrote:
> My use case is that when combined with --graph, the ordering is
> necessary to render a reasonable looking commit graph; by placing the
> commits at the end, each boundary
93 matches
Mail list logo