On Mon, Oct 08, 2018 at 03:59:36PM -0700, Stefan Beller wrote:
> On Mon, Oct 8, 2018 at 2:57 PM brian m. carlson
> wrote:
> >
> > Replace uses of GIT_SHA1_RAWSZ with references to the_hash_algo to avoid
> > dependence on a particular hash length.
>
> Unlike the previous patches, this is dealing
On Mon, Oct 08, 2018 at 03:44:36PM -0700, Stefan Beller wrote:
> > - /* This knows the pack format -- the 20-byte trailer
> > + /* This knows the pack format -- the hash trailer
> > * follows immediately after the last object data.
>
> While at it, fix the comment style?
Jeff King writes:
> +static void strbuf_add_varint(struct strbuf *out, uintmax_t val)
> +{
> + size_t len;
> + strbuf_grow(out, 16); /* enough for any varint */
> + len = encode_varint(val, (unsigned char *)out->buf + out->len);
> + strbuf_setlen(out, out->len + len);
> +}
> +
>
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.
We haven't seen much complaints
Christian Hesse writes:
> From: Christian Hesse
>
> We have targets 'install-man' and 'install-html', let's add build
> targets as well.
> ...
> +man: $(GIT_SUBTREE_DOC)
> +
> +html: $(GIT_SUBTREE_HTML)
> +
As 'contrib' material without real maintenance, I do not care too
deeply, but
Forwarding to Jonathan, as I think this is an interesting supporting
vote for the topic that we were stuck on.
Eric Wong writes:
> Martin Langhoff wrote:
>> Hi folks,
>>
>> Long time no see! Importing a 3GB (~25K revs, tons of files) SVN repo
>> I hit the gc error:
>>
>> warning: There are
Josh Steadmon writes:
> +FUZZ_OBJS += fuzz-pack-headers.o
> +
> +FUZZ_PROGRAMS += $(patsubst %.o,%,$(FUZZ_OBJS))
> +
> ...
> +### Fuzz testing
> +#
> +.PHONY: fuzz-clean fuzz-objs fuzz-compile
I take it that you anticipate the fuzz programs in the future all
be named fuzz-$(blah), whose source
Josh Steadmon writes:
> ### Fuzz testing
> #
> -.PHONY: fuzz-clean fuzz-objs fuzz-compile
> +.PHONY: fuzz-clean fuzz-objs fuzz-compile fuzz-all
> ...
> FUZZ_CFLAGS = $(CFLAGS) -fsanitize-coverage=trace-pc-guard -fsanitize=address
> ...
> +
> +fuzz-all: $(FUZZ_PROGRAMS)
I guess I read your
Daniels Umanovskis writes:
> +--current::
> + Print the name of the current branch. In detached HEAD state,
> + or if otherwise impossible to resolve the branch name, print
> + "HEAD".
Where does "if otherwise impossible to resolve" come from? In the
code in [PATCH 1/2], we see
On Tue, Oct 9, 2018 at 3:25 PM brian m. carlson
wrote:
>
> On Mon, Oct 08, 2018 at 03:59:36PM -0700, Stefan Beller wrote:
> > On Mon, Oct 8, 2018 at 2:57 PM brian m. carlson
> > wrote:
> > >
> > > Replace uses of GIT_SHA1_RAWSZ with references to the_hash_algo to avoid
> > > dependence on a
Martin Langhoff wrote:
> Hi folks,
>
> Long time no see! Importing a 3GB (~25K revs, tons of files) SVN repo
> I hit the gc error:
>
> warning: There are too many unreachable loose objects; run 'git prune'
> to remove them.
> gc --auto: command returned error: 255
GC can be annoying when that
Hello.
Git svn bug on merging svn branches:
Svn repository (branches tag trunk).
1. Add a some file by svn tools.
2. Create a new branch by svn tools (e.g. br1) .
3. Create a new branch by svn tools on branch br1 (e.g. br2).
4. Add some changes to file f1 in branch br1. Commit by svn tools.
5.
> It claimed that grep would still need some explicit handling, but that is
> not the call to repo_read_gitmodules (applying this patch on top of
> ff6f1f564c4 still keep the test suite happy, specifically
> t7814-grep-recurse-submodules, which contains a test
> "grep history with moved
Release item->value.
Initialize item->value->s dynamically and then release its resources.
Release some local variables.
Signed-off-by: Olga Telezhnaia
---
ref-filter.c | 95 +---
1 file changed, 53 insertions(+), 42 deletions(-)
diff --git
Release memory from used_atom variable.
Signed-off-by: Olga Telezhnaia
---
ref-filter.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/ref-filter.c b/ref-filter.c
index e1bcb4ca8a197..1b71d08a43a84 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -1996,6 +1996,9 @@ void
Use ref_array_clear() to release memory instead of UNLEAK macros.
Signed-off-by: Olga Telezhnaia
---
builtin/ls-remote.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/ls-remote.c b/builtin/ls-remote.c
index 1a25df7ee15b4..6a0cdec30d2d7 100644
---
Hi,
Just a ping for opinions. I can provide a patch if the changes make sense.
On 12/05/18 15:14, Andrej Shadura wrote:
> Hello everyone,
>
> I’ve been using Gitk with the following colour settings for a year or
> so, and I found it much more convenient to use that the current default,
> so I’d
Reduce memory leaks in ref-filter.c.
We still have leaks, but at least not so much.
I use command valgrind --leak-check=full -v ./git for-each-ref to check results.
Before:
==24727== LEAK SUMMARY:
==24727==definitely lost: 69,424 bytes in 724 blocks
==24727==indirectly lost: 29,643 bytes
On Mon, 8 Oct 2018, Jacob Keller wrote:
> On Mon, Oct 8, 2018 at 8:22 PM Jeff King wrote:
> >
> > On Tue, Oct 09, 2018 at 08:09:32AM +0900, Junio C Hamano wrote:
> >
> > > Julia Lawall writes:
> > >
> > > >> Doing the same for -S is much harder at the machinery level, as it
> > > >> performs
USLUGI REPETITORA 1-7 klass.
Nizkie ceni
3:00:06 PM
Jonathan Tan writes:
> Because cache_tree_update() is used from multiple places, this new
> behavior is guarded by a new flag WRITE_TREE_SKIP_WORKTREE_MISSING_OK.
The name of the new flag is mouthful, but we know we do not need to
materialize these blobs (exactly because the skip-worktree bit
"Derrick Stolee via GitGitGadget" writes:
> From: Derrick Stolee
>
> When closing a multi-pack-index, we intend to close each pack-file
> and free the struct packed_git that represents it. However, this
> line was previously freeing the array of pointers, not the
> pointer itself. This leads to
Jonathan Tan writes:
> @@ -1635,6 +1635,7 @@ int unpack_trees(unsigned len, struct tree_desc *t,
> struct unpack_trees_options
> o->result.cache_tree = cache_tree();
> if (!cache_tree_fully_valid(o->result.cache_tree))
>
v2: Added patches 2 and 3, made "git cmd --help" unconditionally (no
config option, no delay) redirect to the aliased command's help,
preserve pre-existing behaviour of the spelling "git help cmd".
v3: Add some additional comments in patch 1 and avoid triggering leak
checker reports. Use better
As discussed in the thread for v1 of this patch [1] [2], this changes the
rules for "git foo --help" when foo is an alias.
(1) When invoked as "git help foo", we continue to print the "foo is
aliased to bar" message and nothing else.
(2) If foo is an alias for a shell command, print "foo is
Most git commands respond to -h anywhere in the command line, or at
least as a first and lone argument, by printing the usage
information. For aliases, we can provide a little more information that
might be useful in interpreting/understanding the following output by
prepending a line telling that
This documents the existing behaviour of "git help cmd" when cmd is an
alias, as well as providing a hint to use the "git cmd --help" form to
be taken directly to the man page for the aliased command.
Signed-off-by: Rasmus Villemoes
---
Documentation/git-help.txt | 4
1 file changed, 4
"Derrick Stolee via GitGitGadget" writes:
> diff --git a/builtin/repack.c b/builtin/repack.c
> index c6a7943d5c..7925bb976e 100644
> --- a/builtin/repack.c
> +++ b/builtin/repack.c
> @@ -432,6 +432,10 @@ int cmd_repack(int argc, const char **argv, const char
> *prefix)
>
>
Hi Stefan
Thanks for all your comments on this, they've been really helpful.
On 25/09/2018 02:07, Stefan Beller wrote:
> On Mon, Sep 24, 2018 at 3:06 AM Phillip Wood
> wrote:
>>
>> From: Phillip Wood
>>
>> This adds another mode for highlighting lines that have moved with an
>> indentation
Derrick Stolee writes:
> On 10/8/2018 1:05 PM, Ananya Krishna Maram wrote:
>> Hi All,
> Hello, Ananya! Welcome.
>
>> I was searching through #leftovers and found this.
>> https://public-inbox.org/git/cabpp-bgvvxcbzx44er6to-pusfen_6gnyj1u5cuon9deaa4...@mail.gmail.com/
>>
>> This patch address the
I have install the latest git version from the PPA:
$ git --version
git version 2.19.1
$ lsb_release -rd
Description: Ubuntu 16.04.5 LTS
Release: 16.04
However, trying to autocomplete git difftool --cached gives:
$ env -i bash --rcfile /etc/profile
$ . /usr/share/bash-completion/completions/git
$
On 10/9/2018 5:10 AM, Junio C Hamano wrote:
"Derrick Stolee via GitGitGadget" writes:
diff --git a/builtin/repack.c b/builtin/repack.c
index c6a7943d5c..7925bb976e 100644
--- a/builtin/repack.c
+++ b/builtin/repack.c
@@ -432,6 +432,10 @@ int cmd_repack(int argc, const char **argv, const char
On 10/8/2018 5:48 PM, Jonathan Tan wrote:
Whenever a sparse checkout occurs, the existence of all blobs in the
index is verified, whether or not they are included or excluded by the
.git/info/sparse-checkout specification. This degrades performance,
significantly in the case of a partial
On 10/9/2018 5:30 AM, Junio C Hamano wrote:
Jonathan Tan writes:
@@ -1635,6 +1635,7 @@ int unpack_trees(unsigned len, struct tree_desc *t,
struct unpack_trees_options
o->result.cache_tree = cache_tree();
if
On Mon, Oct 08, 2018 at 11:09:18PM -0400, Jeff King wrote:
> On Mon, Oct 08, 2018 at 11:09:20AM -0700, Taylor Blau wrote:
>
> > Attached is (what I anticipate to be) the final re-roll of my series to
> > introduce 'core.alternateRefsCommand' and 'core.alternateRefsPrefixes'
> > in order to limit
(Changing title to reflect the new topic.)
On 10/8/2018 11:08 PM, Jeff King wrote:
On Mon, Oct 08, 2018 at 02:29:47PM -0400, Derrick Stolee wrote:
There are two questions that I was hoping to answer by looking at
your code:
1. How do you store your Bloom filter? Is it connected to the
You said you received my message but i never got yours.
Please get back to me its very urgent.
AbdWabbo Maddah
On Tue, 9 Oct 2018, Ævar Arnfjörð Bjarmason wrote:
>
> On Tue, Oct 09 2018, Junio C Hamano wrote:
>
> > Jeff King writes:
> >
> >> I think that is the best we could do for "-S", though, which is
> >> inherently about counting hits.
> >>
> >> For "-G", we are literally grepping the diff. It
On Monday, October 8, 2018 10:51:09 PM MST Junio C Hamano wrote:
> The scripts themselves having the same name that is no more specific
> tha just "commit" does not bother _me_ personally too much. If I
> were doing it, unless you are an obsessive type that wants to see
> spanking cleanness
On Tue, Oct 09 2018, Junio C Hamano wrote:
> Jeff King writes:
>
>> I think that is the best we could do for "-S", though, which is
>> inherently about counting hits.
>>
>> For "-G", we are literally grepping the diff. It does not seem
>> unreasonable to add the ability to grep only "-" or "+"
Hi,friend,
This is Daniel Murray and i am from Sinara Group Co.Ltd Group Co.,LTD in Russia.
We are glad to know about your company from the web and we are interested in
your products.
Could you kindly send us your Latest catalog and price list for our trial order.
Best Regards,
Daniel Murray
On Mon, Oct 8, 2018 at 6:03 PM Junio C Hamano wrote:
>
> Stefan Beller writes:
>
> > On Sun, Oct 7, 2018 at 1:07 PM Junio C Hamano wrote:
> >>
> >> Junio C Hamano writes:
> >
> >> > ...
> >> > by general public and I do not have to explain the choice to the
> >> > general public ;-)
> >>
> >>
Gooday To You,
Please i need your kind Assistance. I will be very glad if you can
assist me to receive this sum of ( $22. Million US dollars.) into your
bank account for the benefit of our both families, reply me if you are
ready to receive this fund.
Gooday To You,
Please i need your kind Assistance. I will be very glad if you can
assist me to receive this sum of ( $22. Million US dollars.) into your
bank account for the benefit of our both families, reply me if you are
ready to receive this fund.
Gooday To You,
Please i need your kind Assistance. I will be very glad if you can
assist me to receive this sum of ( $22. Million US dollars.) into your
bank account for the benefit of our both families, reply me if you are
ready to receive this fund.
Gooday To You,
Please i need your kind Assistance. I will be very glad if you can
assist me to receive this sum of ( $22. Million US dollars.) into your
bank account for the benefit of our both families, reply me if you are
ready to receive this fund.
On Tue, Oct 09, 2018 at 03:34:17PM -0700, Stefan Beller wrote:
> On Tue, Oct 9, 2018 at 3:25 PM brian m. carlson
> wrote:
> > This code is mostly here on an interim basis to let us compile with a
> > fully SHA-256 (no SHA-1) Git. Once that piece is done, we can move on
> > to a stage 4 Git,
On Mon, Oct 08, 2018 at 07:01:27PM -0400, Eric Sunshine wrote:
> On Mon, Oct 8, 2018 at 6:27 PM Stefan Beller wrote:
> > On Mon, Oct 8, 2018 at 2:57 PM brian m. carlson
> > wrote:
> > > - if (line.len != 40)
> > > - die("repack: Expecting 40 character sha1
Noam Postavsky writes:
> For octopus merges where the first parent edge immediately merges into
> the next column to the left:
>
> | *-.
> | |\ \
> |/ / /
>
> then the number of columns should be one less than the usual case:
>
> | *-.
> | |\ \
> | | | *
I had a bit hard time parsing the above,
Hi folks,
Long time no see! Importing a 3GB (~25K revs, tons of files) SVN repo
I hit the gc error:
warning: There are too many unreachable loose objects; run 'git prune'
to remove them.
gc --auto: command returned error: 255
I don't seem to be the only one --
The rules are basically:
- each bitmap is a series of counts of runs of 0/1
- each count is one of our standard varints
- each bitmap must have at least one initial count of
zeroes (which may itself be a zero-length count, if the
first bit is set)
- a zero-length count anywhere else
This teaches "gen" mode (formerly the only mode) to include
the list of paths, and to prefix each bitmap with its
matching oid.
The "dump" mode can then read that back in and generate the
list of changed paths. This should be almost identical to:
git rev-list --all |
git diff-tree --stdin
Stefan Beller writes:
>> Oh, I think I misled you by saying "more important".
>> ...
> I do challenge the decision to take a hardcoded value, though, ...
I do not find any reason why you need to say "though" here. If you
understood the message you are responding to that use of hardcoded
value
Jonathan Tan writes:
> After feedback, I restricted this to partial clone. Once restricted, I
> agree with Ben that this can be done for all users of
> cache_tree_update(), not just unpack-trees, so I have removed the
> ability to control the behavior using a flag.
Makes sense. Great.
> I
Signed-off-by: Jeff King
---
Makefile| 1 +
t/helper/test-tree-bitmap.c | 167
2 files changed, 168 insertions(+)
create mode 100644 t/helper/test-tree-bitmap.c
diff --git a/Makefile b/Makefile
index 13e1c52478..f6e823f2d6 100644
---
On Tue, Oct 09, 2018 at 05:14:50PM -0400, Jeff King wrote:
> Hmph. It really sounds like we could do better with a custom RLE
> solution. But that makes me feel like I'm missing something, because
> surely I can't invent something better than the state of the art in a
> simple thought experiment,
For octopus merges where the first parent edge immediately merges into
the next column to the left:
| *-.
| |\ \
|/ / /
then the number of columns should be one less than the usual case:
| *-.
| |\ \
| | | *
Also refactor the code to iterate over columns rather than dashes,
building from an
> This whole version looks good to me. "git am" is supposed to understand
> attachments, but it seems to want to apply our whole conversation as the
> commit message.
>
> You may want to repost one more time with this subject in the email
> subject line to fix that and to get the maintainer's
Jeff King writes:
> The one difference is the sort order: git's diff output is
> in tree-sort order, so a subtree "foo" sorts like "foo/",
> which is after "foo.bar". Whereas the bitmap path list has a
> true byte sort, which puts "foo.bar" after "foo".
If we truly cared, it is easy enough to
On Mon, Oct 8, 2018 at 6:07 PM Junio C Hamano wrote:
>
> Ævar Arnfjörð Bjarmason writes:
>
> > Depending on how we're counting there's at least two.
>
> I thought you were asking "why the special sentinel is not 0{40}?"
> You counted the number of reasons why 0{40} is used to stand in for
> a
On Tue, Oct 9, 2018 at 7:33 AM Ντέντος Σταύρος wrote:
>
> I have install the latest git version from the PPA:
> $ git --version
> git version 2.19.1
> $ lsb_release -rd
> Description: Ubuntu 16.04.5 LTS
> Release: 16.04
>
> However, trying to autocomplete git difftool --cached gives:
> $ env -i
I often find myself needing the current branch name, for which currently
there's git rev-parse --abrev-ref HEAD. I would expect `git branch` to have an
option to output the branch name instead.
This is my first patch to Git, so process-related comments (patch formatting,
et cetera) are quite
On Tue, Oct 09 2018, Derrick Stolee wrote:
> The filter needs to store every path that would be considered "not
> TREESAME". It can't store wildcards, so you would need to evaluate the
> wildcard and test all of those paths individually (not a good idea).
If full paths are stored, yes, But
In f9ee2fcdfa (grep: recurse in-process using 'struct repository',
2017-08-02), we introduced a call to repo_read_gitmodules in builtin/grep
to simplify the submodule handling.
After ff6f1f564c4 (submodule-config: lazy-load a repository's .gitmodules
file, 2017-08-03) this is no longer necessary,
In a partial clone, whenever a sparse checkout occurs, the existence of
all blobs in the index is verified, whether they are included or
excluded by the .git/info/sparse-checkout specification. This
significantly degrades performance because a lazy fetch occurs whenever
the existence of a missing
On 10/9/2018 2:46 PM, Jeff King wrote:
On Tue, Oct 09, 2018 at 09:48:20AM -0400, Derrick Stolee wrote:
[I snipped all of the parts about bloom filters that seemed entirely
reasonable to me ;) ]
Imagine we have that list. Is a bloom filter still the best data
structure for each commit? At
On Tue, Oct 9, 2018 at 7:11 AM Derrick Stolee wrote:
>
> CC Stefan: Is there a plan to make get_object_directory() take a
> repository parameter?
Not an immediate plan. Regarding the large refactorings I am mostly
waiting for nd/the-index to stabilize (which may be stable enough by
now) before
When called with --current, git branch will print the current
branch name and terminate. It will print HEAD in detached-head state.
Rationale: finding out the current branch is useful interactively,
but especially in scripting. git branch --list prints many branches,
and prepends the current one
Signed-off-by: Daniels Umanovskis
---
Documentation/git-branch.txt | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index bf5316ffa..a7167df74 100644
--- a/Documentation/git-branch.txt
+++
On Tue, Oct 09, 2018 at 09:48:20AM -0400, Derrick Stolee wrote:
> [I snipped all of the parts about bloom filters that seemed entirely
> reasonable to me ;) ]
> > Imagine we have that list. Is a bloom filter still the best data
> > structure for each commit? At the point that we have the
Thanks for the feedback!
On 10/9/18 9:54 PM, Stefan Beller wrote:
> How does it play with worktrees? (I would expect it to just work as expected:
> each worktree would print its current branch, but a test might help?)
I'll see about writing a test for that. I've never used git-worktree so
this
USLUGI REPETITORA 1-7 klass.
Nizkie ceni
11:53:13 PM
Daniels Umanovskis writes:
> I often find myself needing the current branch name, for which
> currently there's git rev-parse --abrev-ref HEAD. I would expect
> `git branch` to have an option to output the branch name instead.
[jc: wrapped an overlong line]
If "git branch" had many operations
When $GIT_USE_POC_BLOOM_FILTER is set to a non-empty value, the
revision walk will use the Bloom filter to speed up a path-limited
revision walk.
Load the Bloom filter in prepare_revision_walk(); probably not the
best place for it, but it should suffice for experiementing with 'git
rev-list'.
It will output something like this:
$ GIT_TRACE_BLOOM_FILTER=2 GIT_USE_POC_BLOOM_FILTER=y git rev-list --count
--full-history HEAD -- t/valgrind/valgrind.sh
886
17:24:42.915053 revision.c:484 bloom filter total queries: 66095
definitely not: 64953 maybe: 1142 false positives: 256
---
Makefile | 1 +
bloom-filter.c | 103 +
bloom-filter.h | 39 +++
3 files changed, 143 insertions(+)
create mode 100644 bloom-filter.c
create mode 100644 bloom-filter.h
diff --git a/Makefile b/Makefile
index
You can create a Bloom filter containing changed paths for each commit
in the history by running:
$ GIT_USE_POC_BLOOM_FILTER=$((8*1024*1024*8)) git commit-graph write
where the value of $GIT_USE_POC_BLOOM_FILTER must specify the number
of bits used in the Bloom filter's bitmap.
Writing the
To keep the ball rolling, here is my proof of concept in a somewhat
cleaned-up form, with still plenty of rough edges.
You can play around with it like this:
$ GIT_USE_POC_BLOOM_FILTER=$((8*1024*1024*8)) git commit-graph write
Computing commit graph generation numbers: 100% (52801/52801),
On 10/9/2018 3:34 PM, SZEDER Gábor wrote:
To keep the ball rolling, here is my proof of concept in a somewhat
cleaned-up form, with still plenty of rough edges.
You can play around with it like this:
$ GIT_USE_POC_BLOOM_FILTER=$((8*1024*1024*8)) git commit-graph write
Computing commit
Welcome to the git mailing list!
On Tue, Oct 9, 2018 at 11:31 AM Daniels Umanovskis
wrote:
>
> When called with --current, git branch will print the current
> branch name and terminate. It will print HEAD in detached-head state.
How does it play with worktrees? (I would expect it to just work
On Tue, Oct 09, 2018 at 09:34:43PM +0200, SZEDER Gábor wrote:
> Creating the Bloom filter is slw. Running it on git.git takes
> about 23s on my hardware, while
>
> git log --format='%H%n%P' --name-only --all >/dev/null
>
> gathers all the information necessary for that in about 5.3s.
> As I said above I've more or less come to the view that the correctness
> of pythonic indentation is orthogonal to move detection as it affects
> all additions, not just those that correspond to moved lines.
Makes sense.
> > What is your use case, what kind of content do you process that
> >
On Tue, Oct 09, 2018 at 03:03:08PM -0400, Derrick Stolee wrote:
> > I wonder if Roaring does better here.
>
> In these sparse cases, usually Roaring will organize the data as "array
> chunks" which are simply lists of the values. The thing that makes this
> still compressible is that we store
On Mon, Oct 08, 2018 at 11:08:03PM -0400, Jeff King wrote:
> I'd have done it as one fixed-size filter per commit. Then you should be
> able to hash the path keys once, and apply the result as a bitwise query
> to each individual commit (I'm assuming that it's constant-time to
> access the filter
On Tue, Oct 09, 2018 at 05:06:20PM -0400, Jeff King wrote:
> On Tue, Oct 09, 2018 at 09:34:43PM +0200, SZEDER Gábor wrote:
>
> > Creating the Bloom filter is slw. Running it on git.git takes
> > about 23s on my hardware, while
> >
> > git log --format='%H%n%P' --name-only --all >/dev/null
85 matches
Mail list logo
