Instead of hard-coding a 40-based constant, split the output of
for-each-ref and for-each-reflog by field.
Signed-off-by: brian m. carlson
---
t/t1407-worktree-ref-store.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t1407-worktree-ref-store.sh
Instead of hard-coding a 40-based constant, split the output of
for-each-ref and for-each-reflog by field.
Signed-off-by: brian m. carlson
---
t/t1406-submodule-ref-store.sh | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/t/t1406-submodule-ref-store.sh
Switch a hard-coded all-zeros object ID to use a variable instead.
Signed-off-by: brian m. carlson
---
t/t1400-update-ref.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh
index 7c8df20955..6072650686 100755
---
Compute the size of the tree and commit objects we're creating by
checking for the size of an object ID and computing the resulting sizes
accordingly.
Signed-off-by: brian m. carlson
---
t/t1006-cat-file.sh | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git
Add several test functions to make working with various hash-related
values easier.
Add test_oid_init, which loads common hash-related constants and
placeholder object IDs from the newly added files in t/oid-info.
Provide values for these constants for both SHA-1 and SHA-256.
Add test_oid_cache,
Compute test values of the appropriate size instead of hard-coding
40-character values. Rename the echo20 function to echoid, since the
values may be of varying sizes.
Signed-off-by: brian m. carlson
---
t/t0064-sha1-array.sh | 49 ---
1 file changed, 27
If the hash we're using is 32 bytes in size, attempting to insert a
20-byte object name won't work. Since these are synthesized objects
that are almost all zeros, look them up in a translation table.
Signed-off-by: brian m. carlson
---
t/t-basic.sh | 13 +++--
1 file changed, 7
From: Derrick Stolee
Signed-off-by: Derrick Stolee
Signed-off-by: brian m. carlson
---
t/t5318-commit-graph.sh | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/t/t5318-commit-graph.sh b/t/t5318-commit-graph.sh
index 0c500f7ca2..75fe09521f 100755
---
Test t tests the "basics of the basics" and as such, checks that we
have various fixed hard-coded object IDs. The tests relying on these
assertions have been marked with the SHA1 prerequisite, as they will
obviously not function in their current form with SHA-256.
Use the test_oid helper to
This is the next in the series of improvements to make tests
hash-independent.
A range-diff is below.
Changes from v4:
* Add local statements to the &&-chain.
* Fix a typo in the local statement.
* Add a helpful comment about why test_detect_hash is hard-coded to
SHA-1.
Changes from v3:
*
Adjust the test so that it computes variables for object IDs instead of
using hard-coded hashes.
Signed-off-by: brian m. carlson
---
t/t0002-gitfile.sh | 27 +++
1 file changed, 15 insertions(+), 12 deletions(-)
diff --git a/t/t0002-gitfile.sh b/t/t0002-gitfile.sh
index
We transform various object IDs into all-zero object IDs for comparison.
Adjust the length as well so that this works for all hash algorithms.
While it would be slightly more efficient to use a sed y/// expression
instead of both the tr and sed, retain the tr in both cases for
parallelism and
Instead of hard-coding a 40-based constant, split the output of
for-each-ref and for-each-reflog by field.
Signed-off-by: brian m. carlson
---
t/t1405-main-ref-store.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t1405-main-ref-store.sh b/t/t1405-main-ref-store.sh
On Tue, Sep 11, 2018 at 09:42:35AM +0200, Sergei Haller wrote:
> PS: while I was trying to send the mail to this mailing list, there is
> some update from the stack overflow side:
>
> * I am using sslBackend schannel
> * the private key of my client certificate can be provided by using
> the
Compliment of the day to you Dear Friend.
Dear Friend.
I am Mrs. Amina Kadi. am sending this brief letter to solicit your
partnership to transfer $5.5 million US Dollars. I shall send you
more information and procedures when I receive positive response from
you.
Mrs. Amina Kadi
Hi Thomas,
[quickly, as I will go back to a proper vacation after this]
On Wed, 12 Sep 2018, Thomas Gummerer wrote:
> diff --git a/linear-assignment.c b/linear-assignment.c
> index 9b3e56e283..7700b80eeb 100644
> --- a/linear-assignment.c
> +++ b/linear-assignment.c
> @@ -51,8 +51,8 @@ void
Dear Git users,
It is my pleasure to announce that Git for Windows 2.19.0 is available from:
https://gitforwindows.org/
Changes since Git for Windows v2.18.0 (June 22nd 2018)
New Features
* Comes with Git v2.19.0.
* There are now fast, built-in versions of git stash and git
"Randall S. Becker" writes:
>> author is important to our process. My objective is to keep the original file
>> 100% exact as supplied and then ignore any changes to the metadata that I
>> don't care about (like Creator) if the remainder of the file is the same.
That will *not* work. If person
Junio C Hamano writes:
> "Derrick Stolee via GitGitGadget" writes:
>
>> contrib/coverage-diff.sh | 70
>> 1 file changed, 70 insertions(+)
>> create mode 100755 contrib/coverage-diff.sh
>
> I fully appreciate the motivation. But it is a bit sad that
On 09/12, Junio C Hamano wrote:
> Thomas Gummerer writes:
> > --- >8 ---
> >
> > Subject: [PATCH] linear-assignment: fix potential out of bounds memory
> > access
> >
> > Currently the 'compute_assignment()' function can may read memory out
> > of bounds, even if used correctly. Namely this
On Tue, Sep 11, 2018 at 10:36 PM Josh Steadmon wrote:
>
> Signed-off-by: Josh Steadmon
> ---
> builtin/archive.c | 8 +++-
> http-backend.c | 10 +-
> transport-helper.c | 5 +++--
> 3 files changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/builtin/archive.c
On 09/12, Ben Peart wrote:
> Teach get_index_format_default() to support running the test suite
> with specific index versions. In particular, this enables the test suite
> to be run using index version 4 which is not the default so gets less testing.
I found this commit message slightly
On Tue, Sep 11, 2018 at 10:36 PM Josh Steadmon wrote:
>
> This adds a new archive command for protocol v2. The command expects
> arguments in the form "argument X" which are passed unmodified to
> git-upload-archive--writer.
>
> This command works over the file://, Git, and SSH transports. HTTP
>
On September 12, 2018 4:54 PM, I wrote:
> On September 12, 2018 4:48 PM, Johannes Sixt wrote:
> > Am 12.09.18 um 21:16 schrieb Randall S. Becker:
> > > I feel really bad asking this, and I should know the answer, and yet.
> > >
> > > I have a binary file that needs to go into a repo intact
"Derrick Stolee via GitGitGadget" writes:
> contrib/coverage-diff.sh | 70
> 1 file changed, 70 insertions(+)
> create mode 100755 contrib/coverage-diff.sh
I fully appreciate the motivation. But it is a bit sad that this
begins with "#!/bin/bash" but
On Tue, Sep 11, 2018 at 10:35 PM Josh Steadmon wrote:
>
> Using packet_reader will simplify version detection and capability
> handling, which will make implementation of protocol v2 support in
> git-archive easier.
>
> Signed-off-by: Josh Steadmon
Reviewed-by: Stefan Beller
Jonathan Tan writes:
> fetch-object.h currently provides two functions (fetch_object() and
> fetch_objects()) that could be replaced by a single, more flexible
> function. Replace those two functions with the more flexible function.
The latter half of the first sentence and the second sentence
On Wed, Sep 12, 2018 at 02:23:42PM -0700, Junio C Hamano wrote:
> > diff --git a/commit-reach.c b/commit-reach.c
> > index 86715c103c..6de72c6e03 100644
> > --- a/commit-reach.c
> > +++ b/commit-reach.c
> > @@ -544,20 +544,31 @@ int can_all_from_reach_with_flag(struct object_array
> > *from,
> >
Shulhan writes:
> Rationale: consistent error format
You can and should drop this line.
> When adding new remote name with empty string, git will print the
> following error message,
>
> fatal: '' is not a valid remote name\n
>
> But when removing remote name with empty string as input, git
Teach get_index_format_default() to support running the test suite
with specific index versions. In particular, this enables the test suite
to be run using index version 4 which is not the default so gets less testing.
Signed-off-by: Ben Peart
---
Notes:
Base Ref: v2.19.0
Web-Diff:
"Derrick Stolee via GitGitGadget" writes:
> diff --git a/commit-reach.c b/commit-reach.c
> index 86715c103c..6de72c6e03 100644
> --- a/commit-reach.c
> +++ b/commit-reach.c
> @@ -544,20 +544,31 @@ int can_all_from_reach_with_flag(struct object_array
> *from,
> {
> struct commit **list =
In commit b00bf1c9a8dd ("git-rebase: make --allow-empty-message the
default", 2018-06-27), several arguments were given for transplanting
empty commits without halting and asking the user for confirmation on
each commit. These arguments were incomplete because the logic clearly
assumed the only
> -Original Message-
> From: git-ow...@vger.kernel.org On Behalf
> Of Johannes Sixt
> Sent: September 12, 2018 4:48 PM
> To: Randall S. Becker
> Cc: git@vger.kernel.org
> Subject: Re: [Question] Signature calculation ignoring parts of binary files
>
> Am 12.09.18 um 21:16 schrieb
Am 12.09.18 um 21:16 schrieb Randall S. Becker:
I feel really bad asking this, and I should know the answer, and yet.
I have a binary file that needs to go into a repo intact (unchanged). I also
have a program that interprets the contents, like a textconv, that can
output the relevant portions
Thomas Gummerer writes:
>> > I'm looking into why that fails. Also adding Dscho to Cc here as the
>> > author of this code.
>>
>> The diff below seems to fix it. Not submitting this as a proper
>> patch [...]
>
> I found the time to actually have a look at the paper, so here's a
> proper
"Derrick Stolee via GitGitGadget" writes:
> There have been a few bugs in recent patches what would have been caught if
> the test suite covered those blocks (including a few of mine). I want to
> work towards a "sensible" amount of coverage on new topics. In my opinion,
> this means that any
William Chargin writes:
> While the `test_dir_is_empty` function appears correct in most normal
> use cases, it can improperly pass if a directory contains a filename
> with a newline, and can improperly fail if an empty directory looks like
> an argument to `ls`. This patch changes the
On Wed, Sep 12, 2018 at 07:22:56AM -0700, Derrick Stolee via GitGitGadget wrote:
> From: Derrick Stolee
>
> The can_all_from_reach_with_flag() algorithm was refactored in 4fbcca4e
> "commit-reach: make can_all_from_reach... linear" but incorrectly
> assumed that all objects provided were
On 9/12/2018 12:45 PM, Derrick Stolee via GitGitGadget wrote:
We have coverage targets in our Makefile for using gcov to display line
coverage based on our test suite. The way I like to do it is to run:
make coverage-test
make coverage-report
Very nice, I was unaware of the coverage test
From: Torsten Bögershausen
git_check_attr() returns always 0.
Remove all the error handling code of the callers, which is never executed.
Change git_check_attr() to be a void function.
Signed-off-by: Torsten Bögershausen
---
archive.c | 3 ++-
attr.c | 8
Stefan Beller writes:
> For Gerrit users that use submodules the invocation of fetch without a
> branch is their main use case.
That's way under explains this commit. It is totally unclear how
that statement of fact relates to the problem this patch is trying
to address; it does not even make
I feel really bad asking this, and I should know the answer, and yet.
I have a binary file that needs to go into a repo intact (unchanged). I also
have a program that interprets the contents, like a textconv, that can
output the relevant portions of the file in whatever format I like - used
for
On 9/12/2018 12:45 PM, Derrick Stolee via GitGitGadget wrote:
For example, I ran this against the 'jch' branch (d3c0046)
versus 'next' (dd90340)
As another example, I ran this against the 'pu' branch (4c416a53) versus
'jch' (d3c0046) and got the following output, submitted here without
On Wed, Sep 12, 2018 at 11:18 AM Junio C Hamano wrote:
>
> Stefan Beller writes:
>
> > We can string_list_insert() to maintain sorted-ness of the
> > list as we find new items, or we can string_list_append() to
> > build an unsorted list and sort it at the end just once.
> >
> > To pick which
Stefan Beller writes:
> Retry fetching a submodule if the object id that the superproject points
> to, cannot be found.
By object name? By attempting to fetch all refs? Or by doing
something else? Fetching by the exact object name is the most
efficient approach, but the server side may not
On 09/11, Thomas Gummerer wrote:
> On 09/11, Thomas Gummerer wrote:
> > I think you're on the right track here. I can not test this on Mac
> > OS, but on Linux, the following fails when running the test under
> > valgrind:
> >
> > diff --git a/t/t3206-range-diff.sh b/t/t3206-range-diff.sh
>
While the `test_dir_is_empty` function appears correct in most normal
use cases, it can improperly pass if a directory contains a filename
with a newline, and can improperly fail if an empty directory looks like
an argument to `ls`. This patch changes the implementation to check that
the output of
Stefan Beller writes:
> This patch started as a refactoring to make 'get_next_submodule' more
> readable, but upon doing so, I realized that git-fetch actually doesn't
> need to be run in the worktree. So let's run it in the git dir instead.
It may be clear to the author but not clear to the
While the `test_dir_is_empty` function appears correct in most normal
use cases, it can improperly pass if a directory contains a filename
with a newline, and can improperly fail if an empty directory looks like
an argument to `ls`. This patch changes the implementation to check that
the output of
Stefan Beller writes:
> We can string_list_insert() to maintain sorted-ness of the
> list as we find new items, or we can string_list_append() to
> build an unsorted list and sort it at the end just once.
>
> To pick which one is more appropriate, we notice the fact
> that we discover new items
Stefan Beller writes:
> The submodule subsystem is really bad at staying within 80 characters.
> Fix it while we are here.
Makes sense. Thanks.
>
> Signed-off-by: Stefan Beller
> ---
> submodule.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/submodule.c
Stefan Beller writes:
> Helped-by: Junio C Hamano
> Signed-off-by: Stefan Beller
> ---
> sha1-array.c | 18 ++
> sha1-array.h | 5 +
> 2 files changed, 23 insertions(+)
>
> diff --git a/sha1-array.c b/sha1-array.c
> index 265941fbf40..76323935dd7 100644
> ---
Stefan Beller writes:
> Add a few functions to allow a string-list to be used as a stack:
>
> - string_list_last() lets a caller peek the string_list_item at the
>end of the string list. The caller needs to be aware that it is
>borrowing a pointer, which can become invalid if/when the
On Tue, Sep 11 2018, 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
Hello -
This is not a git bug or issue. It's just something I stumbled across
and didn't see any google results for. I thought others would benefit
from being aware of it.
I saw a makefile which included of "git describe --tags --dirty" to
define version information for a binary's --version
We have coverage targets in our Makefile for using gcov to display line
coverage based on our test suite. The way I like to do it is to run:
make coverage-test
make coverage-report
This leaves the repo in a state where every X.c file that was covered has an
X.c.gcov file containing the coverage
From: Derrick Stolee
We have coverage targets in our Makefile for using gcov to display line
coverage based on our test suite. The way I like to do it is to run:
make coverage-test
make coverage-report
This leaves the repo in a state where every X.c file that was covered has
an
The End of Index Entry (EOIE) is used to locate the end of the variable
length index entries and the beginning of the extensions. Code can take
advantage of this to quickly locate the index extensions without having
to parse through all of the index entries.
Because it must be able to be loaded
Shulhan writes:
> Rationale: consistent error format
>
> When adding new remote name with empty string, git will print the
> following error message,
>
> fatal: '' is not a valid remote name\n
>
> But when removing remote name with empty string as input, git did not
> print the empty string
From: Nguyễn Thái Ngọc Duy
Index format v4 requires some more computation to assemble a path
based on a previous one. The current code is not very efficient
because
- it doubles memory copy, we assemble the final path in a temporary
first before putting it back to a cache_entry
-
This patch does a clean up pass to minimize the casting required to work
with the memory mapped index (mmap).
It also makes the decoding of network byte order more consistent by using
get_be32() where possible.
Signed-off-by: Ben Peart
---
read-cache.c | 49
This patch helps address the CPU cost of loading the index by creating
multiple threads to divide the work of loading and converting the cache
entries across all available CPU cores.
It accomplishes this by having the primary thread loop across the index file
tracking the offset and (for V4
This patch helps address the CPU cost of loading the index by loading
the cache extensions on a worker thread in parallel with loading the cache
entries.
In some cases, loading the extensions takes longer than loading the
cache entries so this patch utilizes the new EOIE to start the thread to
This version of the patch merges in Duy's work to speed up index v4 decoding.
I had to massage it a bit to get it to work with the multi-threading but it is
still largely his code. I also responded to Junio's feedback on initializing
copy_len to avoid compiler warnings.
I also added a minor
Jeff King writes:
> I really wonder if this topic is worth pursuing further without finding
> a real-world case that actually fails with the v2.19 code. I.e., is
> there actually a server that doesn't set CONTENT_LENGTH and really can't
> handle read-to-eof? It's plausible to me, but it's also
A coworker discovered a bug when having a partial clone against a server
that supports ref-in-want - the lazy fetches no longer work, because the
client attempts to fetch with "want-ref ", which is not permitted
by the protocol.
The first patch deduplicates some code, so that the bugfix need only
fetch_objects() currently does not set exact_oid in struct ref when
invoking transport_fetch_refs(). If the server supports ref-in-want,
fetch_pack() uses this field to determine whether a wanted ref should be
requested as a "want-ref" line or a "want" line; without the setting of
exact_oid, the
fetch-object.h currently provides two functions (fetch_object() and
fetch_objects()) that could be replaced by a single, more flexible
function. Replace those two functions with the more flexible function.
Signed-off-by: Jonathan Tan
---
fetch-object.c | 16 +---
fetch-object.h | 8
Rationale: consistent error format
When adding new remote name with empty string, git will print the
following error message,
fatal: '' is not a valid remote name\n
But when removing remote name with empty string as input, git did not
print the empty string with quote,
fatal: No such
Rationale: consistent error format
When adding new remote name with empty string, git will print the
following error message,
fatal: '' is not a valid remote name\n
But when removing remote name with empty string as input, git did not
print the empty string with quote,
fatal: No such
On 9/11/2018 7:26 PM, Ben Peart wrote:
This version of the patch merges in Duy's work to speed up index v4 decoding.
I had to massage it a bit to get it to work with the multi-threading but its
still largely his code. It helps a little (3%-4%) when the cache entry thread(s)
take the longest
From: Derrick Stolee
The commit 40ce4160 "format-patch: allow --range-diff to apply to
a lone-patch" added the ability to see a range-diff as commentary
after the commit message of a single patch series (i.e. [PATCH]
instead of [PATCH X/N]). However, this functionality was not
covered by a test
In es/format-patch-rangediff, we added a '--range-diff' option to
git-format-patch to automatically add a range-diff. We also added an option
to write the diff as commentary to a single patch submission. However, this
check was not tested.
I discovered this test gap by running 'make coverage-test
From: Derrick Stolee
The can_all_from_reach_with_flag() algorithm was refactored in 4fbcca4e
"commit-reach: make can_all_from_reach... linear" but incorrectly
assumed that all objects provided were commits. During a fetch
negotiation, ok_to_give_up() in upload-pack.c may provide unpeeled tags
to
As Peff reported [1], the refactored can_all_from_reach_with_flags() method
does not properly peel tags. Since the helper method can_all_from_reach()
and code in t/helper/test-reach.c all peel tags before getting to this
method, it is not super-simple to create a test that demonstrates this.
I
On 9/11/2018 5:34 PM, Eric Sunshine wrote:
On Tue, Sep 11, 2018 at 4:26 PM Derrick Stolee via GitGitGadget
wrote:
The commit 40ce4160 "format-patch: allow --range-diff to apply to
a lone-patch" added the ability to see a range-diff as commentary
after the commit message of a single patch
The following:
git add -u :\(glob,attr:-someAttr\):src/**
Produces an error that, according to the source code, should never be visible
to the user. This attribute/pathspec *should* be supported according to the
documentation provided by git:
fatal: BUG:builtin/add.c:498: unsupported magic 40
On 9/12/2018 12:29 AM, Jeff King wrote:
On Wed, Sep 12, 2018 at 12:14:25AM -0400, Jeff King wrote:
+ ALLOC_ARRAY(list, from->nr);
for (i = 0; i < from->nr; i++) {
- struct object *from_one = from->objects[i].item;
+ list[i] = (struct commit
Apologies, forgot the crucial details post that log:
$ git --version
git version 2.19.0
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 18.04.1 LTS
Release:18.04
Codename: bionic
Hi,
For some reason today, after an apt update, my combination of GNOME
keyring and git-credential-libsecret stopped working. Stopped working
in so far as I am no longer prompted by GNOME keyring to unlock my
keyring, instead I get prompted for the password that git is looking
for.
Trace output
On Wed, Sep 12, 2018 at 6:11 AM Phillip Wood wrote:
> Use the new function to read the author script, updating
> read_env_script() and read_author_ident(). This means we now have a
> single code path that reads the author script and uses sq_dequote() to
> dequote it. This fixes potential problems
On Wednesday, September 12, 2018 12:13:23 AM MST Junio C Hamano wrote:
> Stephen & Linda Smith writes:
> > On Tuesday, September 11, 2018 3:20:19 PM MST Junio C Hamano wrote:
> >> * jc/wt-status-state-cleanup (2018-09-07) 1 commit
> >>
> >> - WIP: roll wt_status_state into wt_status and
From: Phillip Wood
Add read_author_script() to sequencer.c based on the implementation in
builtin/am.c and update read_am_author_script() to use
read_author_script(). The sequencer code that reads the author script
will be updated in the next commit.
Signed-off-by: Phillip Wood
---
From: Phillip Wood
Rename read_author_script() in preparation for adding a shared
read_author_script() function to libgit.
Signed-off-by: Phillip Wood
---
builtin/am.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/am.c b/builtin/am.c
index
From: Phillip Wood
Use the new function to read the author script, updating
read_env_script() and read_author_ident(). This means we now have a
single code path that reads the author script and uses sq_dequote() to
dequote it. This fixes potential problems with user edited scripts
as
From: Phillip Wood
This is a follow up to pw/rebase-i-author-script-fix, it reduces code
duplication and improves rebase's parsing of the author script. After
this I'll do another series to share the code to write the author
script.
Phillip Wood (3):
am: rename read_author_script()
add
Stephen & Linda Smith writes:
> On Tuesday, September 11, 2018 3:20:19 PM MST Junio C Hamano wrote:
>>
>> * jc/wt-status-state-cleanup (2018-09-07) 1 commit
>> - WIP: roll wt_status_state into wt_status and populate in the collect
>> phase (this branch uses ss/wt-status-committable.)
>>
>> *
Jeff King wrote:
> On Tue, Sep 11, 2018 at 11:15:13AM -0700, Junio C Hamano wrote:
>> I do not think we would mind terribly if we do not support
>> combinations like gzipped-and-then-chunked from day one. An in-code
>> NEEDSWORK comment that refers to the production in RFC 2616 Page 143
>> may
Hi,
On Tue, Sep 11, 2018 at 7:42 PM SZEDER Gábor wrote:
> Lately I noticed that occasionally I ended up with an empty commit
> message after an interactive rebase...those empty commit messages are the
> consequence of a regression in v2.19.0, which bisects down to this
> patch.
>
> To reproduce
89 matches
Mail list logo
