On 6/11/2019 5:06 PM, Jonathan Tan wrote:
> This series is on jt/partial-clone-missing-ref-delta-base.
>
> Patch 1 is a cleanup, and patch 2 improves test code coverage. Thanks to
> Stolee for the code coverage report.
>
> I have checked this by running `make coverage` then `make cover_db_html`
>
I occasionally rebase my submodules. I realize the danger (historical submodule
pointers could point to commits that get garbage-collected away) so I always
create and push a tag before the rebase, to make sure the old commits will
never get purged. I believe this is safe, based on some experime
On Tue, Jun 11, 2019 at 02:48:51PM -0700, Junio C Hamano wrote:
> Matthew DeVore writes:
>
> >> It is brittle because callers are bound to forget doing "if
> >> (!x->buf.buf) lazy_init(&x->buf)" at some point, and blindly use an
> >> uninitialized x->buf. Making sure x->buf is always initialized
On Tue, Jun 11, 2019 at 01:48:14PM -0700, Junio C Hamano wrote:
> SZEDER Gábor writes:
>
> > Make sure that the previously displayed "Rebasing (N/M)" line is
> > cleared by using the term_clear_line() helper function added in the
> > previous patch.
> >
> > A couple of other rebase commands print
On 2019-06-11 at 19:52:18, Elmar Pruesse wrote:
> Hi!
>
> The total compiled size of libexec/git-core is currently somewhere
> around 30 MB. This is largely due to a number of binaries linking
> statically against libgit.a. For some folks, every byte counts. I
> meddled with the Makefile briefly t
On 2019-06-11 at 23:20:31, Eric Sunshine wrote:
> On Tue, Jun 11, 2019 at 7:03 PM Jonathan Tan wrote:
> > > test_expect_success 'alternate objects are correctly blamed' '
> > > test_when_finished "rm -rf alt.git .git/objects/info/alternates" &&
> > > + path=$(test_oid numeric) &&
> > >
On 2019-06-11 at 23:02:55, Jonathan Tan wrote:
> > @@ -84,7 +86,7 @@ test_expect_success 'branch pointing to non-commit' '
> > test_expect_success 'HEAD link pointing at a funny object' '
> > test_when_finished "mv .git/SAVED_HEAD .git/HEAD" &&
> > mv .git/HEAD .git/SAVED_HEAD &&
> > - e
trace_schema_validator can be used to verify that trace2 event output
conforms to the expectations set by the API documentation and codified
in event_schema.json (or strict_schema.json). This allows us to build a
regression test to verify that trace2 output does not change
unexpectedly.
Signed-off
Define a JSON schema[1] that can be used to validate trace2 event
objects. This can be used to add regression tests to verify that the
event output format does not change unexpectedly.
Two versions of the schema are provided:
* event_schema.json is more permissive. It verifies that all expected
Correct the api-trace2 documentation, which lists "signal" as an
expected field for the signal event type, but which actually outputs
"signo" as the field name.
Signed-off-by: Josh Steadmon
---
Documentation/technical/api-trace2.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --g
This is a proof of concept series that formalizes the structure of trace2 event
output using JSON-Schema [1].
It provides a validator (written in Go) that verifies the events in a given
trace2 event output file match the schema. I am happy to rewrite this validator
in some other language, provided
On Tue, Jun 11, 2019 at 7:03 PM Jonathan Tan wrote:
> > test_expect_success 'alternate objects are correctly blamed' '
> > test_when_finished "rm -rf alt.git .git/objects/info/alternates" &&
> > + path=$(test_oid numeric) &&
> > + path=$(test_oid_to_path "$path") &&
>
> Double assig
> @@ -84,7 +86,7 @@ test_expect_success 'branch pointing to non-commit' '
> test_expect_success 'HEAD link pointing at a funny object' '
> test_when_finished "mv .git/SAVED_HEAD .git/HEAD" &&
> mv .git/HEAD .git/SAVED_HEAD &&
> - echo >.git/
Matthew DeVore writes:
>> It is brittle because callers are bound to forget doing "if
>> (!x->buf.buf) lazy_init(&x->buf)" at some point, and blindly use an
>> uninitialized x->buf. Making sure x->buf is always initialized
>
> A corallary proposition would be to make this particular strbuf a "st
On Tue, Jun 11, 2019 at 11:44:27AM -0700, Matthew DeVore wrote:
> A corallary proposition would be to make this particular strbuf a "struct
> strbuf *" rather than an inline strbuf. It should then be rather clear to
> users
> that it may be null. Then whoever allocates the memory can also do the
>
Rohit Ashiwal writes:
> -static int create_seq_dir(void)
> +static int create_seq_dir(struct repository *r)
> {
> - if (file_exists(git_path_seq_dir())) {
> - error(_("a cherry-pick or revert is already in progress"));
> - advise(_("try \"git cherry-pick (--continue |
On Tue, Jun 11, 2019 at 01:36:16PM -0700, Junio C Hamano wrote:
> SZEDER Gábor writes:
>
> > -Rebasing (1/4)QRebasing (2/4)QRebasing (3/4)QRebasing (4/4)QSuccessfully
> > rebased and updated refs/heads/missing-commit.
> > +Rebasing (1/4)QRebasing (2/4)QRebasing (3/4)QRebasing (4/4)QQ
If we want to check whether an object is missing, the correct flag to
pass to rev-list is --ignore-missing; --exclude-promisor-objects will
exclude any object that came from the promisor remote, whether it is
present or missing. Use the correct flag.
Signed-off-by: Jonathan Tan
---
t/t5616-parti
This series is on jt/partial-clone-missing-ref-delta-base.
Patch 1 is a cleanup, and patch 2 improves test code coverage. Thanks to
Stolee for the code coverage report.
I have checked this by running `make coverage` then `make cover_db_html`
on both "next" and this series, and comparing the outpu
When fetching into a partial clone, Git first prefetches missing
REF_DELTA bases from the promisor remote. (This feature was introduced
in [1].) But as can be seen in a recent test coverage report [2], the
case in which a REF_DELTA base is already present is not covered by
tests.
Extend the tests
SZEDER Gábor writes:
> Make sure that the previously displayed "Rebasing (N/M)" line is
> cleared by using the term_clear_line() helper function added in the
> previous patch.
>
> A couple of other rebase commands print similar messages, e.g.
> "Stopped at ... " for the 'edit' or 'break'
> comman
On Monday, 10 June 2019 21:15:58 CEST Junio C Hamano wrote:
> Jean-Noël AVILA writes:
>
> > I can provide an archive comprising the precompiled manpages so that
packagers
> > don't need to mess up with po4a.
>
> That's an interesting thing to hear---if this effort eventually
> relieves me from
SZEDER Gábor writes:
> -Rebasing (1/4)QRebasing (2/4)QRebasing (3/4)QRebasing (4/4)QSuccessfully
> rebased and updated refs/heads/missing-commit.
> +Rebasing (1/4)QRebasing (2/4)QRebasing (3/4)QRebasing (4/4)QQ
> QSu
On 6/11/2019 11:04 AM, Christian Hesse wrote:
Dear Jeff, dear Junio,
for cgit we use the static git library built into the executable. This used
to work well, but breaks with latest release v2.22.0: Our code unsets HOME
and XDG_CONFIG_HOME to mitigate loading arbitrary configuration.
We have
Matthew DeVore writes:
> - if (s->version)
> + if (s->version) {
> cmp = versioncmp(va->s, vb->s);
> - else if (cmp_type == FIELD_STR)
> - cmp = cmp_fn(va->s, vb->s);
> - else {
Ah, this must be the patch noise Jonathan was (half) complaining
about. It
Hi!
The total compiled size of libexec/git-core is currently somewhere
around 30 MB. This is largely due to a number of binaries linking
statically against libgit.a. For some folks, every byte counts. I
meddled with the Makefile briefly to make it build and use a libgit.so
instead, which dropp
Christian Hesse writes:
> With the new trace2 code in place at least tracing configuration is loaded
> before cmd_main() kicks in. This happens in trace2_initialize_fl() ->
> tr2_sysenv_load() -> read_very_early_config().
I think that is as designed.
> The offending commit is
> bce9db6d ("trace
Jonathan Nieder writes:
> Git seems to be inconsistent about this. Documentation/CodingGuidelines
> says
>
> - When there are multiple arms to a conditional and some of them
> require braces, enclose even a single line block in braces for
> consistency. E.g.:
>
> so y
Derrick Stolee writes:
> I think the more correct thing to say is that `--split` implies `--append`:
> As we write a new tip graph, we do not discard any commits from the lower
> layers, even if we merge them together.
> ...
> There is nothing that stops them both from being specified, so this
>
--
Hello dear, with the grace of God I have to find strength and courage
to write you today before is too lateI know we have not yet meet or
know each other but with time and the grace of God we will get to know
yourself better.I have something very important and confidential I
will like to discus
Hi Espen,
On Tue, 11 Jun 2019, Espen Antonsen wrote:
> Seeing an error after upgrading to git v2.22.0.
>
> git status shows “error: could not parse ‘*a commit message from 2012*’”
>
> Downgrading to v.2.21.0 does not yield this message for git status.
>
> I can only replicate this in a private re
"Derrick Stolee via GitGitGadget" writes:
> From: Derrick Stolee
>
> The 'git multi-pack-index expire' subcommand looks at the existing
> mult-pack-index, counts the number of objects referenced in each
s/mult/&i/
> pack-file, deletes the pack-fils with no referenced objects, and
s/fils/files
On Tue, Jun 11, 2019 at 10:33:18AM -0700, Junio C Hamano wrote:
> Matthew DeVore writes:
>
> >> convention, and it may even be a useful one (i.e. it allows you to
> >> calloc() a structure with an embedded strbuf in it and the "if
> >> .buf==NULL, call strbuf_init() lazily" can become an establis
Before this patch, "git branch" would put "(HEAD detached...)" and "(no
branch, rebasing...)" lines before all the other branches *in most
cases* and only because of the fact that "(" is a low codepoint. This
would not hold in the Chinese locale, which uses a full-width "(" symbol
(codepoint FF08).
This version improves upon the previous:
- fixes a bug where reverse-sorting didn't work with (HEAD detached) lines, and
adds a test
- makes implementation code a little DRYer
- uses test_when_finished where applicable
- makes zh_CN locale detection look more like the is_IS locale detection
Matthew DeVore writes:
>> convention, and it may even be a useful one (i.e. it allows you to
>> calloc() a structure with an embedded strbuf in it and the "if
>> .buf==NULL, call strbuf_init() lazily" can become an established
>> pattern), but at the same time it feels a bit brittle.
>
> Is it
On Mon, Jun 10, 2019 at 05:41:06PM -0700, Jonathan Nieder wrote:
> Git seems to be inconsistent about this. Documentation/CodingGuidelines
> says
>
> - When there are multiple arms to a conditional and some of them
> require braces, enclose even a single line block in braces for
Thank Peff. Unfortunately I am living with this issue, no one able to find out
what is causing this significant delay. Re-initiating this thread if someone
can help on this.
Thanks & Regards,
Ibrahim Vanak
-Original Message-
From: Jeff King [mailto:p...@peff.net]
Sent: Thursday, May 30
Dear Jeff, dear Junio,
for cgit we use the static git library built into the executable. This used
to work well, but breaks with latest release v2.22.0: Our code unsets HOME
and XDG_CONFIG_HOME to mitigate loading arbitrary configuration.
We have tests that use strace to check for access to direct
This is a reworked/extended version of the single patch "rebase: fix
garbled progress display with '-x'" at:
https://public-inbox.org/git/20190430142556.20921-1-szeder@gmail.com/T/#u
Changes:
- Add a helper function to clear the whole line on the terminal,
using an ANSI escape sequen
There are a couple of places where we want to clear the last line on
the terminal, e.g. when a progress bar line is overwritten by a
shorter line, then the end of that progress line would remain visible,
unless we cover it up.
In 'progress.c' we did this by always appending a fixed number of
space
The test 'rebase -i respects rebase.missingCommitsCheck = warn' checks
the output of 'git rebase', including progress lines: it prepares the
expected output from a here-doc using LFs at the end of progress
lines, and converts the command's actual output by replacing the
progress lines' CRs with LFs
When running a command with the 'exec' instruction during an
interactive rebase session, or for a range of commits using 'git
rebase -x', the output can be a bit garbled when the name of the
command is short enough:
$ git rebase -x true HEAD~5
Executing: true
Executing: true
Executing: tru
To make sure that the previously displayed progress line is completely
covered up when the new line is shorter, commit 545dc345eb (progress:
break too long progress bar lines, 2019-04-12) added a bunch of
calculations to figure out how many characters it needs to overwrite
with spaces.
Use the jus
Seeing an error after upgrading to git v2.22.0.
git status shows “error: could not parse ‘*a commit message from 2012*’”
Downgrading to v.2.21.0 does not yield this message for git status.
I can only replicate this in a private repo I have so far. Unable to share the
repo but can debug if you n
On 6/7/2019 5:57 PM, Junio C Hamano wrote:
> "Derrick Stolee via GitGitGadget" writes:
>
>> -N_("git commit-graph write [--object-dir ] [--append]
>> [--reachable|--stdin-packs|--stdin-commits]"),
>> +N_("git commit-graph write [--object-dir ] [--append|--split]
>> [--reachable|--stdin-
On Thu, May 02, 2019 at 01:16:40AM +0200, SZEDER Gábor wrote:
> On Tue, Apr 30, 2019 at 06:25:35PM -0400, Johannes Schindelin wrote:
> > > Make sure that the previously displayed "Rebasing (N/M)" line is
> > > completely covered up by printing a terminal width worth of space
> > > characters.
> >
Not all people can afford stable network connection...
I'm now suffered from connection lost and have to restart the clone/push fully.
It's OK when dealing with a project of several MB size, but when I try
to clone a 2GB sized repo I never succeed.
So I wonder, if there should be some way to resume
On Tue, Jun 11, 2019 at 10:23:22AM +0200, Christian Couder wrote:
> I decided against hardcoding values as I think it might help
> transitionning from SHA1 to SHA256.
Ok, that makes sense.
On Tue, Jun 11, 2019 at 10:23:24AM +0200, Christian Couder wrote:
> diff --git a/t/t0016-oidmap.sh b/t/t0016-oidmap.sh
> new file mode 100755
> index 00..cbd2cb71d6
> --- /dev/null
> +++ b/t/t0016-oidmap.sh
> @@ -0,0 +1,100 @@
> +#!/bin/sh
> +
> +test_description='test oidmap'
> +. ./test-l
From: Christian Couder
Get rid of the static hash() function in oidmap.c which is redundant
with sha1hash(). Use sha1hash() directly instead.
Let's be more consistent and not use several hash functions doing
nearly exactly the same thing.
Signed-off-by: Christian Couder
---
oidmap.c | 13 +++-
Unlike hashmap that has t/helper/test-hashmap.c and t/t0011-hashmap.sh
oidmap has no specific test. The goal of this small patch series is to
change that and also improve oidmap a bit while at it.
Changes compared to V1 are the following:
- use printf("%x\n", ntohl(sha1hash(oid.hash))) to print
From: Christian Couder
Add actual tests for operations using `struct oidmap` from oidmap.{c,h}.
Helped-by: SZEDER Gábor
Signed-off-by: Christian Couder
---
t/t0016-oidmap.sh | 100 ++
1 file changed, 100 insertions(+)
create mode 100755 t/t0016-oid
This new helper is very similar to "test-hashmap.c" and will help
test how `struct oidmap` from oidmap.{c,h} can be used.
Helped-by: SZEDER Gábor
Signed-off-by: Christian Couder
---
Makefile | 1 +
t/helper/test-oidmap.c | 134 +
t/helper/
git am or rebase have a --skip flag to skip the current commit if the
user wishes to do so. During a cherry-pick or revert a user could
likewise skip a commit, but needs to use 'git reset' (or in the case
of conflicts 'git reset --merge'), followed by 'git (cherry-pick |
revert) --continue' to skip
The previous commit introduced a --skip flag for cherry-pick and
revert. Update the advice messages, to tell users about this less
cumbersome way of skipping commits. Also add tests to ensure
everything is working fine.
Signed-off-by: Rohit Ashiwal
---
changes since last revision:
- selective
In the case of merge conflicts, while performing a revert, we are
currently advised to use `git cherry-pick --`
of which --continue is incompatible for continuing the revert.
Introduce a separate advice message for `git revert`. Also change
the signature of `create_seq_dir` to handle which advice t
Adding a `--skip` option to make skipping commits easier for the user
and to make the commands more consistent. This will serve as a small
step to the bigger goal which improving consistency of sequencer commands.
Rohit Ashiwal (3):
sequencer: add advice for revert
cherry-pick/revert: add --sk
58 matches
Mail list logo
