Hi,
Josh Steadmon wrote:
> Subject: archive: allow archive over HTTP(S) with proto v2
It's interesting how little this has to touch the client.
> Signed-off-by: Josh Steadmon
> ---
> builtin/archive.c | 8 +++-
> http-backend.c | 10 +-
> transport-helper.c | 5 +++--
> 3
Hi,
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
> support will be added in a
Hi,
Josh Steadmon wrote:
> This series adds a new protocol v2 command for archiving, and allows
> this command to work over HTTP(S). This was previously discussed in [1].
> I've CCed everyone who participated in that discussion.
Yay! Getting ready to read it now.
For the future, "git
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
Teach list-objects the "tree:0" filter which allows for filtering
out all tree and blob objects (unless other objects are explicitly
specified by the user). The purpose of this patch is to allow smaller
partial clones.
The name of this filter - tree:0 - does not explicitly specify that
it also
This will make utility functions easier to create, as done by the next
patch.
Signed-off-by: Matthew DeVore
---
list-objects.c | 158 +++--
1 file changed, 74 insertions(+), 84 deletions(-)
diff --git a/list-objects.c b/list-objects.c
index
If parsing fails when revs->ignore_missing_links and
revs->exclude_promisor_objects are both false, we print the OID anyway
in the die("bad tree object...") call, so any message printed by
parse_tree_gently() is superfluous.
Signed-off-by: Matthew DeVore
---
list-objects.c | 4 +---
1 file
Currently, list-objects.c incorrectly treats all root trees of commits
as USER_GIVEN. Also, it would be easier to mark objects that are
non-user-given instead of user-given, since the places in the code
where we access an object through a reference are more obvious than
the places where we access
Previously, we assumed only blob objects could be missing. This patch
makes rev-list handle missing trees like missing blobs. The --missing=*
and --exclude-promisor-objects flags now work for trees as they already
do for blobs. This is demonstrated in t6112.
Signed-off-by: Matthew DeVore
---
This will be used in a follow-up patch to reduce indentation needed when
invoking the logic conditionally. i.e. rather than:
if (foo) {
while (...) {
/* this is very indented */
}
}
we will have:
if (foo)
process_tree_contents(...);
Signed-off-by:
In some cases in this file, BUG makes more sense than die. In such
cases, a we get there from a coding error rather than a user error.
'return' has been removed following some instances of BUG since BUG does
not return.
Signed-off-by: Matthew DeVore
---
list-objects-filter.c | 11 ---
Things seem to have settled down in terms of responses, so here is a re-roll,
some of the changes being Junio's suggestions:
- show a more helpful error if a positive integer is given after "tree:"
- added a test for an issue that this patchset inadvertently fixes:
git rev-list would filter
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 Wed, Sep 12, 2018 at 6:11 AM Phillip Wood wrote:
> 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.
>
>
Ben Peart writes:
> diff --git a/t/t1700-split-index.sh b/t/t1700-split-index.sh
> index 39133bcbc8..f613dd72e3 100755
> --- a/t/t1700-split-index.sh
> +++ b/t/t1700-split-index.sh
> @@ -7,6 +7,7 @@ test_description='split index mode tests'
> # We need total control of index splitting here
>
Currently the 'compute_assignment()' function may read memory out
of bounds, even if used correctly. Namely this happens when we only
have one column. In that case we try to calculate the initial
minimum cost using '!j1' as column in the reduction transfer code.
That in turn causes us to try and
On 09/12, Johannes Schindelin wrote:
> Hi Thomas,
>
> [quickly, as I will go back to a proper vacation after this]
Sorry about interrupting your vacation, enjoy wherever you are! :)
> On Wed, 12 Sep 2018, Thomas Gummerer wrote:
>
> > diff --git a/linear-assignment.c b/linear-assignment.c
> >
Thomas Gummerer writes:
> Thanks, I do think this is a good idea. I do however share Ævar's
> concern in https://public-inbox.org/git/87h8itkz2h@evledraar.gmail.com/.
> I have TEST_GIT_INDEX_VERSION=4 set in my config.mak since quite a
> long time, and had I missed this thread, I would all
Junio C Hamano writes:
> Have you run "make test" with this change?
>
> I expect at least 5505.10 to fail without adjustment.
For now, I'll queue this on top, and if this turns out to be
sufficient, I will squash it in.
t/t5505-remote.sh | 4 ++--
1 file changed, 2 insertions(+), 2
On 09/13, Ben Peart wrote:
>
>
> On 9/12/2018 6:31 PM, Thomas Gummerer wrote:
> > 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
Shulhan writes:
> 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 shows the
> empty string without quote,
>
> fatal: No such remote: \n
>
Ben Peart writes:
> Rename GIT_FORCE_PRELOAD_TEST to GIT_TEST_PRELOAD for consistency with the
> other GIT_TEST_ special setups and properly document its use.
>
> Signed-off-by: Ben Peart
> ---
>
Among the two unrelated changes that are not mentioned in the
proposed log message, the change to
Derrick Stolee writes:
>> +if (!from_one || from_one->type != OBJ_COMMIT) {
>> +/* no way to tell if this is reachable by
>> + * looking at the ancestry chain alone, so
>> + * leave a note to ourselves not to worry about
>>
Ævar Arnfjörð Bjarmason writes:
> On Wed, Sep 12 2018, Ben Peart wrote:
>
>> -GIT_TEST_OE_DELTA_SIZE= exercises the uncomon pack-objects code
>> +GIT_TEST_OE_DELTA_SIZE= exercises the uncommon pack-objects code
>> path where deltas larger than this limit require extra memory
>> allocation for
Jonathan Tan writes:
>> Instead of explaining why the new convention is better to justify
>> (2), the above three lines handwave by saying "more flexible"
>> twice. We should do better.
>>
>> fetch-object: unify fetch_object[s] functions
>>
>> There are fetch_object() and
Elijah Newren writes:
> This patch cleanly applies to both 2.19.0 and pu. There are some related
> code cleanups that I'd like to make, but doing that cleanup conflicts with
> the various rewrite-rebase-in-C topics sitting in pu; since those are
> fairly lengthy, I really don't want to cause
On Wed, Sep 12, 2018 at 11:36 AM Junio C Hamano wrote:
>
> 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
On Thu, Sep 13 2018, brian m. carlson wrote:
> - $RWT for-each-reflog | cut -c 42- | sort >actual &&
> + $RWT for-each-reflog | cut -d" " -f 2- | sort >actual &&
Aside from hash size issues, this just makes the tests easier to
read. Thanks!
On Thu, Sep 13 2018, Derrick Stolee via GitGitGadget wrote:
> + progress = start_progress(_("Verifying object offsets"),
> m->num_objects);
I think in the spirit of my "commit-graph {write,verify}: add progress
output" it would be better to say:
"Verifying multi-pack-index object
On Thu, Sep 13 2018, Ben Peart wrote:
> diff --git a/config.c b/config.c
> index 3461993f0a..3555c63f28 100644
> --- a/config.c
> +++ b/config.c
> @@ -2278,7 +2278,7 @@ int git_config_get_max_percent_split_change(void)
> int git_config_get_fsmonitor(void)
> {
> if
On Wed, Sep 12 2018, Ben Peart wrote:
> -GIT_TEST_OE_DELTA_SIZE= exercises the uncomon pack-objects code
> +GIT_TEST_OE_DELTA_SIZE= exercises the uncommon pack-objects code
> path where deltas larger than this limit require extra memory
> allocation for bookkeeping.
If re-rolled maybe better
On Wed, Sep 12 2018, Stefan Beller wrote:
> On Tue, Sep 11, 2018 at 10:36 PM Josh Steadmon wrote:
>> +*/
>> + status = packet_reader_read();
>> + }
>> + if (status != PACKET_READ_DELIM)
>> + die(_("upload-archive: expected delim
Rename TEST_GIT_INDEX_VERSION to GIT_TEST_INDEX_VERSION for consistency with
the other GIT_TEST_ special setups and properly document its use.
Signed-off-by: Ben Peart
---
Notes:
Base Ref: v2.19.0
Web-Diff: https://github.com/benpeart/git/commit/e26ccb9004
Checkout: git fetch
On 9/13/2018 1:40 PM, Junio C Hamano wrote:
"Derrick Stolee via GitGitGadget" writes:
+ then
+ line_num=$(($line_num + 1))
+ fi
+ fi
+ done
I have a feeling that a single Perl script instead of a
> Instead of explaining why the new convention is better to justify
> (2), the above three lines handwave by saying "more flexible"
> twice. We should do better.
>
> fetch-object: unify fetch_object[s] functions
>
> There are fetch_object() and fetch_objects() helpers in
>
Ben Peart writes:
> Rename GIT_FSMONITOR_TEST to GIT_TEST_FSMONITOR for consistency with the
> other GIT_TEST_ special setups and properly document its use.
Makes sense.
Thanks for such an attention to detail.
>
> Signed-off-by: Ben Peart
> ---
>
> Notes:
> Base Ref: v2.19.0
>
From: Derrick Stolee
The multi-pack-index builtin writes multi-pack-index files, and
uses a 'write' verb to do so. Add a 'verify' verb that checks this
file matches the contents of the pack-indexes it replaces.
The current implementation is a no-op, but will be extended in
small increments in
From: Derrick Stolee
When verifying a multi-pack-index, the only action that takes
significant time is checking the object offsets. For example,
to verify a multi-pack-index containing 6.2 million objects in
the Linux kernel repository takes 1.3 seconds on my machine.
99% of that time is spent
From: Derrick Stolee
The final check we make while loading a multi-pack-index is that
the packfile names are in lexicographical order. Make this error
be a die() instead.
In order to test this condition, we need multiple packfiles.
Earlier in t5319-multi-pack-index.sh, we tested the interaction
From: Derrick Stolee
The 'git multi-pack-index verify' command must verify the object
offsets stored in the multi-pack-index are correct. There are two
ways the offset chunk can be incorrect: the pack-int-id and the
object offset.
Replace the BUG() statement with a die() statement, now that we
From: Derrick Stolee
When loading a 64-bit offset, we intend to check that off_t can store
the resulting offset. However, the condition accidentally checks the
32-bit offset to see if it is smaller than a 64-bit value. Fix it,
and this will be covered by a test in the 'git multi-pack-index
From: Derrick Stolee
Signed-off-by: Derrick Stolee
---
midx.c | 16
t/t5319-multi-pack-index.sh | 5 +
2 files changed, 21 insertions(+)
diff --git a/midx.c b/midx.c
index e655a15aed..a02b19efc1 100644
--- a/midx.c
+++ b/midx.c
@@ -926,13 +926,29 @@
From: Derrick Stolee
When core.multiPackIndex is true, we may have a multi-pack-index
in our object directory. Add calls to 'git multi-pack-index verify'
at the end of 'git fsck' if so.
Signed-off-by: Derrick Stolee
---
builtin/fsck.c | 18 ++
From: Derrick Stolee
Signed-off-by: Derrick Stolee
---
midx.c | 11 +++
t/t5319-multi-pack-index.sh | 8
2 files changed, 19 insertions(+)
diff --git a/midx.c b/midx.c
index dfd26b4d74..06d5cfc826 100644
--- a/midx.c
+++ b/midx.c
@@ -959,5 +959,16 @@ int
From: Derrick Stolee
Signed-off-by: Derrick Stolee
---
midx.c | 3 +++
t/t5319-multi-pack-index.sh | 13 +
2 files changed, 16 insertions(+)
diff --git a/midx.c b/midx.c
index ec78254bb6..8b054b39ab 100644
--- a/midx.c
+++ b/midx.c
@@ -100,6 +100,9 @@ struct
From: Derrick Stolee
When verifying if a multi-pack-index file is valid, we want the
command to fail to signal an invalid file. Previously, we wrote
an error to stderr and continued as if we had no multi-pack-index.
Now, die() instead of error().
Add tests that check corrupted headers in a few
From: Derrick Stolee
Signed-off-by: Derrick Stolee
---
midx.c | 9 +
t/t5319-multi-pack-index.sh | 8
2 files changed, 17 insertions(+)
diff --git a/midx.c b/midx.c
index a02b19efc1..dfd26b4d74 100644
--- a/midx.c
+++ b/midx.c
@@ -950,5 +950,14 @@ int
The multi-pack-index file provides faster lookups in repos with many
packfiles by duplicating the information from multiple pack-indexes into a
single file. This series allows us to verify a multi-pack-index using 'git
multi-pack-index verify' and 'git fsck' (when core.multiPackIndex is true).
Rename GIT_FORCE_PRELOAD_TEST to GIT_TEST_PRELOAD for consistency with the
other GIT_TEST_ special setups and properly document its use.
Signed-off-by: Ben Peart
---
Notes:
Base Ref: v2.19.0
Web-Diff: https://github.com/benpeart/git/commit/dcd201b920
Checkout: git fetch
On September 13, 2018 1:52 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > "Randall S. Becker" writes:
> >
> >> The scenario is slightly different.
> >> 1. Person A gives me a new binary file-1 with fingerprint A1. This
> >> goes into git unchanged.
> >> 2. Person B gives me binary
On Thu, Sep 13, 2018 at 10:56 AM Derrick Stolee via GitGitGadget
wrote:
> 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
Junio C Hamano writes:
> "Randall S. Becker" writes:
>
>> The scenario is slightly different.
>> 1. Person A gives me a new binary file-1 with fingerprint A1. This goes into
>> git unchanged.
>> 2. Person B gives me binary file-2 with fingerprint B2. This does not go
>> into git yet.
>> 3. We
Rename GIT_FSMONITOR_TEST to GIT_TEST_FSMONITOR for consistency with the
other GIT_TEST_ special setups and properly document its use.
Signed-off-by: Ben Peart
---
Notes:
Base Ref: v2.19.0
Web-Diff: https://github.com/benpeart/git/commit/311484a684
Checkout: git fetch
"Derrick Stolee via GitGitGadget" writes:
> 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
On 9/13/2018 1:17 AM, brian m. carlson wrote:
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
Josh Steadmon writes:
> 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 b/builtin/archive.c
> index
On 9/13/2018 12:10 PM, 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 commits. During a fetch
Josh Steadmon writes:
> +static int do_v2_command_and_cap(int out)
> +{
> + packet_write_fmt(out, "command=archive\n");
> + /* Capability list would go here, if we had any. */
> + packet_delim(out);
> +}
> +
> static int run_remote_archiver(int argc, const char **argv,
>
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 September 13, 2018 11:03 AM, Junio C Hamano wrote:
> "Randall S. Becker" writes:
>
> > The scenario is slightly different.
> > 1. Person A gives me a new binary file-1 with fingerprint A1. This
> > goes into git unchanged.
> > 2. Person B gives me binary file-2 with fingerprint B2. This does
Junio C Hamano writes:
>> -if (packet_read_line(fd[0], NULL))
>> +status = packet_reader_read();
>> +if (status != PACKET_READ_FLUSH)
>> die(_("git archive: expected a flush"));
>
> This makes me wonder what happens if we got an EOF instead. We fail
> to notice protocol
"Randall S. Becker" writes:
> The scenario is slightly different.
> 1. Person A gives me a new binary file-1 with fingerprint A1. This goes into
> git unchanged.
> 2. Person B gives me binary file-2 with fingerprint B2. This does not go
> into git yet.
> 3. We attempt a git diff between the
Derrick Stolee writes:
> On 9/12/2018 6:54 PM, Junio C Hamano wrote:
>> Junio C Hamano writes:
>>
>>> "Derrick Stolee via GitGitGadget" writes:
>>>
contrib/coverage-diff.sh | 70
1 file changed, 70 insertions(+)
create mode 100755
Josh Steadmon writes:
> Using packet_reader will simplify version detection and capability
> handling, which will make implementation of protocol v2 support in
> git-archive easier.
Is this meant as a change in implementation without any change in
behaviour?
> Signed-off-by: Josh Steadmon
>
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
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
On 9/12/2018 6:31 PM, Thomas Gummerer wrote:
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.
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 shows the
empty string without quote,
fatal: No such remote: \n
To make these error messages
On 9/12/2018 6:54 PM, Junio C Hamano wrote:
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
On September 12, 2018 7:00 PM, Junio C Hamano wrote:
> "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
On Tue, Sep 11 2018, Michal Novotny wrote:
> I need to emulate git tag --merged with very old git 1.8.3.1. Is that
> somehow possible?
> I am looking for a bash function that would take what git 1.8.3.1
> offers and return only the tags accessible from the current branch
Jeff answer the
Hi Jochen
On 03/09/2018 20:01, Jochen Sprickerhof wrote:
> Hi Phillip,
>
> * Phillip Wood [2018-08-30 14:47]:
>> When $newhunk is created it is marked as dirty to prevent
>> coalesce_overlapping_hunks() from coalescing it. This patch does not
>> change that. What is happening is that by calling
On Wed, Sep 12, 2018 at 3:01 PM Thomas Gummerer wrote:
> Subject: [PATCH] linear-assignment: fix potential out of bounds memory access
>
> Currently the 'compute_assignment()' function can may read memory out
"can may"?
> of bounds, even if used correctly. Namely this happens when we only
>
> Apologies, forgot the crucial details post that log:
This turned out to be an error unrelated to git or git-credential-libsecret.
Apologies for the noise (and the badly threaded reply earlier).
Paul
On Tue, Sep 11, 2018 at 9:05 PM Jeff King wrote:
>
> On Tue, Sep 11, 2018 at 12:43:15PM +0200, Michal Novotny wrote:
>
> > I need to emulate git tag --merged with very old git 1.8.3.1. Is that
> > somehow possible?
> > I am looking for a bash function that would take what git 1.8.3.1
> > offers
76 matches
Mail list logo
