On Tue, Mar 26 2019, Jeff King wrote:
> On Tue, Mar 26, 2019 at 08:22:23AM +0900, Mike Hommey wrote:
>
>> Recently, I've noticed that whenever the auto-gc message shows up about
>> being spawned in the background, it still takes a while for git to
>> return to the shell.
>>
>> I've finally looke
On 19-03-25 12:39, SZEDER Gábor wrote:
| On Mon, Mar 25, 2019 at 12:08:47PM +0100, Ævar Arnfjörð Bjarmason wrote:
| >
| > On Mon, Mar 25 2019, SZEDER Gábor wrote:
| >
| > > When a git process runs in the background, it doesn't display
| > > progress, only the final "done" line [1]. T
On Tue, Mar 26 2019, Duy Nguyen wrote:
> On Tue, Mar 26, 2019 at 5:48 AM Ævar Arnfjörð Bjarmason
> wrote:
>>
>>
>> On Mon, Mar 25 2019, Eric Sunshine wrote:
>>
>> > On Mon, Mar 25, 2019 at 4:23 PM Ævar Arnfjörð Bjarmason
>> > wrote:
>> >> diff --git a/Documentation/config/core.txt b/Documentat
On Mon, Mar 25, 2019 at 11:38:39AM +0100, SZEDER Gábor wrote:
> This patch series fixes two progress display issues:
>
> - When showing throughput, and the both the total and the throughput
> change units in the same update, than the previously shown
> progress bar is not cleaned up pro
On Mon, Mar 25, 2019 at 11:38:42AM +0100, SZEDER Gábor wrote:
> The following patches in this series want to handle the progress bar's
> title and changing parts (i.e. the counter and the optional percentage
> and throughput combined) differently.
>
> To prepare for those changes assemble the cha
On Mon, Mar 25, 2019 at 11:38:41AM +0100, SZEDER Gábor wrote:
> diff --git a/progress.c b/progress.c
> index 02a20e7d58..b57c0dae16 100644
> --- a/progress.c
> +++ b/progress.c
> @@ -86,28 +86,30 @@ static void display(struct progress *progress, uint64_t
> n, const char *done)
> ret
On Mon, Mar 25, 2019 at 01:43:23PM -0700, Jonathan Tan wrote:
> In protocol v0, when sending "shallow" lines, the server distinguishes
> between lines caused by the remote repo being shallow and lines caused
> by client-specified depth settings. Unless "--update-shallow" is
> specified, there is a
On Mon, Mar 25, 2019 at 01:43:22PM -0700, Jonathan Tan wrote:
> In fetch_pack(), be clearer that there is no shallow information before
> the fetch when v2 is used - memset the struct shallow_info to 0 instead
> of calling prepare_shallow_info().
>
> This patch is in preparation for a future patc
On Tue, Mar 26, 2019 at 5:48 AM Ævar Arnfjörð Bjarmason
wrote:
>
>
> On Mon, Mar 25 2019, Eric Sunshine wrote:
>
> > On Mon, Mar 25, 2019 at 4:23 PM Ævar Arnfjörð Bjarmason
> > wrote:
> >> diff --git a/Documentation/config/core.txt b/Documentation/config/core.txt
> >> @@ -1,3 +1,15 @@
> >> +core.
On Mon, Mar 25, 2019 at 4:37 PM Jeff King wrote:
>
> On Mon, Mar 25, 2019 at 11:21:19PM +, Michael Platings wrote:
>
> > > I work on a project that needs a major reformatting, and one thing
> > > delaying me was the lack of an ability to ignore commits during blame.
> >
> > I think we understa
On Mon, Mar 25, 2019 at 08:19:25PM +0100, Ævar Arnfjörð Bjarmason wrote:
> > $ git tag -a mytag
> > error: refusing to make a recursive tag
> > hint: The object 'mytag' referred to by your new tag is already a tag.
> > hint:
> > hint: If you meant to create a tag of a tag, use:
> > hin
On Mon, Mar 25, 2019 at 11:43:52AM -0700, Bryan Turner wrote:
> > I don't think I've ever seen a tag-to-a-tag in the wild, but I wouldn't
> > be surprised if somebody has found a use for it. For example, because
> > tags can be signed, I can make a signature of your signature, showing a
> > crypto
On Mon, Mar 25, 2019 at 11:21:19PM +, Michael Platings wrote:
> > I work on a project that needs a major reformatting, and one thing
> > delaying me was the lack of an ability to ignore commits during blame.
>
> I think we understand each other well then - I'm working on a plan to
> change th
On Tue, Mar 26, 2019 at 08:22:23AM +0900, Mike Hommey wrote:
> Recently, I've noticed that whenever the auto-gc message shows up about
> being spawned in the background, it still takes a while for git to
> return to the shell.
>
> I've finally looked at what it was stuck on, and it's
> `git refl
Hi,
Recently, I've noticed that whenever the auto-gc message shows up about
being spawned in the background, it still takes a while for git to
return to the shell.
I've finally looked at what it was stuck on, and it's
`git reflog expire --all` taking more than 30s. I guess the question is
whethe
Hi Barret,
> I work on a project that needs a major reformatting, and one thing
> delaying me was the lack of an ability to ignore commits during blame.
I think we understand each other well then - I'm working on a plan to
change the variable naming rule in LLVM, and naturally other
developers ar
On Mon, Mar 25 2019, Eric Sunshine wrote:
> On Mon, Mar 25, 2019 at 4:23 PM Ævar Arnfjörð Bjarmason
> wrote:
>> diff --git a/Documentation/config/core.txt b/Documentation/config/core.txt
>> @@ -1,3 +1,15 @@
>> +core.abbreviatedOptions::
>> + Defaults to `true` which allows options to be a
On Mon, Mar 25, 2019 at 10:28:21PM +0100, Johannes Schindelin wrote:
> Hi,
>
> I like the rest of the patch series, but this patch, I am not so sure
> about...
>
> On Sun, 24 Mar 2019, SZEDER Gábor wrote:
>
> > When our '.travis.yml' was split into several 'ci/*' scripts [1], the
> > installatio
From: Johannes Schindelin
On Windows, for example, executables (must) have the extension `.exe`.
Our `check-docs` target was not prepared for that.
Signed-off-by: Johannes Schindelin
---
Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index
I stumbled across this when investigating one of Duy's bugs in the CI
builds.
Changes since v1:
* We no longer add an extra space in front of the $(patsubst ...) in the
second loop, but fix the underlying bug that prevented check-docs' part
from working where it discovered documented comma
From: Johannes Schindelin
When we want to see what commands are listed in `command-list.txt` but
not installed, we currently include lines that refer to guides, e.g.
`gitattributes` or `gitcli`.
Let's not include those lines, as they are not referring to commands.
Signed-off-by: Johannes Schind
From: Johannes Schindelin
Since 7ded055401 (build: do not install git-remote-testgit, 2013-06-07),
we do not install it. Therefore it makes no sense to document it,
either.
Signed-off-by: Johannes Schindelin
---
Documentation/git-remote-testgit.txt | 30
Documentat
From: Johannes Schindelin
As part of the `check-docs` target, we verify that commands that are
documented are actually in the current list of commands to be built.
However, this logic broke in 5fafce0b78 (check-docs: get documented
command list from Makefile, 2012-08-08), when we tried to make t
From: Johannes Schindelin
It is currently in section 1, but that section is intended for
"Executable programs or shell commands".
A more appropriate place is section 7: "Miscellaneous (including macro
packages and conventions), e.g. man(7), groff(7)".
This issue should have been detected earlie
Hi Duy,
On Sun, 24 Mar 2019, Nguyễn Thái Ngọc Duy wrote:
> diff --git a/t/t1305-config-include.sh b/t/t1305-config-include.sh
> index 635918505d..4d6e70c11d 100755
> --- a/t/t1305-config-include.sh
> +++ b/t/t1305-config-include.sh
> @@ -229,6 +229,19 @@ test_expect_success 'conditional include,
Hi,
I like the rest of the patch series, but this patch, I am not so sure
about...
On Sun, 24 Mar 2019, SZEDER Gábor wrote:
> When our '.travis.yml' was split into several 'ci/*' scripts [1], the
> installation of the 'asciidoctor' gem somehow ended up in
> 'ci/test-documentation.sh'.
>
> Instal
On Mon, Mar 25, 2019 at 4:23 PM Ævar Arnfjörð Bjarmason
wrote:
> diff --git a/Documentation/config/core.txt b/Documentation/config/core.txt
> @@ -1,3 +1,15 @@
> +core.abbreviatedOptions::
> + Defaults to `true` which allows options to be abbreviated as
> + long as they aren't ambiguous
пн, 25 мар. 2019 г. в 22:27, Kapil Jain :
>
> Hi,
>
> Below are some two queries concerning
> https://git.github.io/SoC-2019-Ideas/#unify-ref-filter-formats-with-other---pretty-formats
>
> Q1)
>
> In pretty.h & pretty.c:
> void get_commit_format(const char *arg, struct rev_info *);
> This function
Hi Junio,
On Sun, 24 Mar 2019, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > Sharp eyes, and a *very* good point. The double space is actually required
> > for this patch to work as intended. I added the following explanation to
> > the commit message:
> >
> > Note that `$(ALL_CO
This is built on master+jt/test-protocol-version, but should apply
cleanly to master.
After [1] and this patch set, there is only one more small thing to fix
or mark GIT_TEST_PROTOCOL_VERSION=0 at master+jt/test-protocol-version.
This is very similar to [2], which was neither reviewed nor merged,
In protocol v0, when sending "shallow" lines, the server distinguishes
between lines caused by the remote repo being shallow and lines caused
by client-specified depth settings. Unless "--update-shallow" is
specified, there is a difference in behavior: refs that reach the former
"shallow" lines, bu
In fetch_pack(), be clearer that there is no shallow information before
the fetch when v2 is used - memset the struct shallow_info to 0 instead
of calling prepare_shallow_info().
This patch is in preparation for a future patch in which a v2 fetch
might call prepare_shallow_info() after shallow inf
On Mon, Mar 25 2019, Denton Liu wrote:
> Hi Johannes,
>
> Thanks for catching this. Perhaps I should've been more diligent and ran
> the entire test suite before submitting but I was running low on
> batteries only ran the rebase-related tests.
>
> On Mon, Mar 25, 2019 at 11:14:23AM -0700, Johan
Change the option parsing machinery so that e.g. "clone --recurs ..."
doesn't error out because "clone" understands both "--recursive" and
"--recurse-submodules" to mean the same thing.
Initially "clone" just understood --recursive until the
--recurses-submodules alias was added in ccdd3da652 ("cl
Add a new core.abbreviatedOptions which corresponds to the newly added
GIT_TEST_DISALLOW_ABBREVIATED_OPTIONS test mode. This allows
e.g. script authors to enact the same sort of paranoia about option
abbreviation as our own test suite now uses by default.
I'm renaming GIT_TEST_DISALLOW_ABBREVIATED
This is based on Johannes's just-submitted
https://public-inbox.org/git/pull.167.git.gitgitgad...@gmail.com/
Some of this in my 1/2 could obviously be shortened if the
"GIT_TEST_ABBREVIATED_OPTIONS" name was used by default, but I'll
leave it up to discussion whether it's worth it to go for the ro
On Mon, Mar 25 2019, Johannes Schindelin via GitGitGadget wrote:
> +# Disallow the use of abbreviated options in the test suite by default
> +test -n "$GIT_TEST_DISALLOW_ABBREVIATED_OPTIONS" || {
> + GIT_TEST_DISALLOW_ABBREVIATED_OPTIONS=true
> + export GIT_TEST_DISALLOW_ABBREVIATED_OPTI
> Of On March 25, 2019 15:22, Fabio Aiuto wrote:
> Il giorno sab, 23/03/2019 alle 15.34 -0400, Randall S. Becker ha
> scritto:
> > On March 23, 2019 9:00, Fabio Aiuto wrote:
> > > To: Randall S. Becker ; git@vger.kernel.org
> > > Subject: Re: Semantic errors
> > >
> > > Il giorno ven, 22/03/2019 al
Il giorno lun, 25/03/2019 alle 15.35 -0400, Randall S. Becker ha
scritto:
> > Of On March 25, 2019 15:22, Fabio Aiuto wrote:
> > Il giorno sab, 23/03/2019 alle 15.34 -0400, Randall S. Becker ha
> > scritto:
> > > On March 23, 2019 9:00, Fabio Aiuto wrote:
> > > > To: Randall S. Becker ; git@vger.ke
Hi Johannes,
On Mon, Mar 25, 2019 at 07:50:38PM +0100, Johannes Schindelin wrote:
> Hi Denton,
>
> On Sat, 23 Mar 2019, Denton Liu wrote:
>
> > [...]
> >
> > This allows us to rewrite the above as
> >
> > git rebase -i --keep-base master
> >
> > and
> >
> > git rebase -x ./test.sh --keep
Hi,
Below are some two queries concerning
https://git.github.io/SoC-2019-Ideas/#unify-ref-filter-formats-with-other---pretty-formats
Q1)
In pretty.h & pretty.c:
void get_commit_format(const char *arg, struct rev_info *);
This function Parses given arguments from "arg", checks it for
correctness
Il giorno sab, 23/03/2019 alle 15.34 -0400, Randall S. Becker ha
scritto:
> On March 23, 2019 9:00, Fabio Aiuto wrote:
> > To: Randall S. Becker ; git@vger.kernel.org
> > Subject: Re: Semantic errors
> >
> > Il giorno ven, 22/03/2019 alle 18.43 -0400, Randall S. Becker ha
> > scritto:
> > > >
On Mon, Mar 25 2019, Jeff King wrote:
> On Mon, Mar 25, 2019 at 08:50:14AM -0500, Robert Dailey wrote:
>
>> On Thu, Mar 21, 2019 at 2:29 PM Jeff King wrote:
>> > Tags can point to any object, including another tag. It looks like
>> > somebody made an annotated tag of an annotated tag (probably
Hi,
Jeff King wrote:
> On Sun, Mar 24, 2019 at 12:21:31PM -0400, Todd Zullinger wrote:
>> I'm curious why manpage builds work for you and not for me.
>
> I think it's because I'm an idiot. I must have only been using 2.0.0
> when I was looking at the XML output manually (for the refmiscinfo
> lin
Hi Denton,
On Sat, 23 Mar 2019, Denton Liu wrote:
> [...]
>
> This allows us to rewrite the above as
>
> git rebase -i --keep-base master
>
> and
>
> git rebase -x ./test.sh --keep-base master
>
> respectively.
Just a quick note: this breaks t5407 because that test uses `git rebase
-
On Mon, Mar 25, 2019 at 7:49 AM Jeff King wrote:
>
> On Mon, Mar 25, 2019 at 08:50:14AM -0500, Robert Dailey wrote:
>
> > On Thu, Mar 21, 2019 at 2:29 PM Jeff King wrote:
> > > Tags can point to any object, including another tag. It looks like
> > > somebody made an annotated tag of an annotated
Hi Johannes,
Thanks for catching this. Perhaps I should've been more diligent and ran
the entire test suite before submitting but I was running low on
batteries only ran the rebase-related tests.
On Mon, Mar 25, 2019 at 11:14:23AM -0700, Johannes Schindelin via GitGitGadget
wrote:
> From: Johann
We do not want to have tests that need to be changed by completely unrelated
patch series, just because abbreviations that used to be unique are being
made non-unique by said patch series.
I stumbled over this while investigating the test failures in
dl/rebase-i-keep-base
[https://dev.azure.com/gi
From: Johannes Schindelin
We really want to spell out the option in the full form, to avoid any
ambiguity that might be introduced by future patches.
Signed-off-by: Johannes Schindelin
---
t/t5516-fetch-push.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t5516-fet
From: Johannes Schindelin
This test wants to run `git rebase` with the `--keep-empty` option, but
it really only spelled out `--keep` and trusted Git's option parsing to
determine that this was a unique abbreviation of the real option.
However, Denton Liu contributed a patch series in
https://pu
From: Johannes Schindelin
To avoid future ambiguities, we really want to use full option names in
the test suite. `t7525-status-rename.sh` used an abbreviated form of the
`--find-renames` option, though, so let's change that.
Signed-off-by: Johannes Schindelin
---
t/t7525-status-rename.sh | 8
From: Johannes Schindelin
In quite a few test cases, we were sloppy and used the abbreviation
`--force`, but we really should be precise in what we want to test.
Signed-off-by: Johannes Schindelin
---
t/t3415-rebase-autosquash.sh | 2 +-
t/t3430-rebase-merges.sh | 4 ++--
2 files changed,
From: Johannes Schindelin
This script used abbreviated options, which is unnecessarily fragile.
Signed-off-by: Johannes Schindelin
---
t/t7810-grep.sh | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/t/t7810-grep.sh b/t/t7810-grep.sh
index 43aa4161cf..2e1bb6
From: Johannes Schindelin
It was probably just an oversight: the `--recurse-submodules` option
puts the term "submodules" in the plural form, not the singular one.
To avoid future problems in case that another option is introduced that
starts with the prefix `--recurse-submodule`, let's just fix
From: Johannes Schindelin
To use the singular form of a word, when the option wants the plural
form (and quietly expands it because it thinks it was abbreviated), is
an easy mistake to make, and t5317 contains almost two dozen of them.
However, using abbreviated options in tests is a bit fragile
From: Johannes Schindelin
Git's command-line parsers support uniquely abbreviated options, e.g.
`git init --ba` would automatically expand `--ba` to `--bare`.
This is a very convenient feature in every day life for Git users, in
particular when tab completion is not available.
However, it is no
23.03.2019, 04:44, "Luke Diamand" :
> On Fri, 22 Mar 2019 at 19:54, Mazo, Andrey wrote:
>> Our Perforce server experienced some kind of database corruption a few
>> years ago.
>> While the file data and revision history are mostly intact,
>> some metadata for several changesets got lost.
>
> I
From: "Mazo, Andrey"
23.03.2019, 05:16, "Luke Diamand" :
> On Thu, 21 Mar 2019 at 22:32, Mazo, Andrey wrote:
>> git-p4 knows how to handle case insensitivity in file paths
>> if core.ignorecase is set.
>> However, when determining a branch for a file,
>> it still does a case-sensitive prefi
On 3/22/2019 1:37 AM, Junio C Hamano wrote:
"Jeff Hostetler via GitGitGadget" writes:
Teach "multi-pack-index verify" to handle cases where the number of
packfiles exceeds the open file handle limit.
The first commit fixes a problem that prevented the LRU-style
close_one_pack() mechanism f
On 25/03/2019 12:02, Ævar Arnfjörð Bjarmason wrote:
>
> On Sat, Mar 23 2019, Ramsay Jones wrote:
>
>> Signed-off-by: Ramsay Jones
>> ---
>>
>> Hi Ævar,
>>
>> If you need to re-roll your 'ab/commit-graph-fixes' branch, could you
>> please squash this into the relevant patch (commit aeb244adbc
On 3/23/2019 4:44 PM, Ævar Arnfjörð Bjarmason wrote:
On Thu, Mar 21 2019, Josh Steadmon wrote:
When the value of a trace2 environment variable is an absolute path
referring to an existing directory, write output to files (one per
process) underneath the given directory. Files will be named
On Fri, Mar 22, 2019 at 2:32 AM Nguyễn Thái Ngọc Duy wrote:
>
> When --merge is specified, we may need to do a real merge (instead of
> three-way tree unpacking), the steps are best seen in git-checkout.sh
> version before it's removed:
>
> # Match the index to the working tree, and do a three
Hi -
On 3/25/19 5:32 AM, Michael Platings wrote:
(resending in plain text mode, sorry for the noise)
Thanks Junio, that's super helpful!
A month or two ago I contacted the author of git-hyper-blame, Matt
Giuca, asking whether anyone had looked into adding the feature to git
blame. I didn't rec
On Mon, Mar 25, 2019 at 2:53 AM Duy Nguyen wrote:
>
> (Including Stefan, in case he's still interested in git and planned
> something for the "submodule" restore part I mention below)
>
> On Fri, Mar 08, 2019 at 10:01:25AM -0800, Elijah Newren wrote:
> > Thanks for working on this; overall looks r
Thanks Johannes, and Jeff for your responses
> you probably meant the worktree, not the repository, I assume
You introduced me to a new feature :) I didn't know about this
"worktree" feature. Thanks.
> Trace2 will let you see all of the git commands,
> the alias expansions, and any shell commands
On Mon, Mar 25, 2019 at 7:56 AM Johannes Schindelin
wrote:
>
> Hi C.J.
>
> On Fri, 22 Mar 2019, C.J. Jameson wrote:
>
> > Confirming Sergey's summary: at this point, I think my only residual
> > opinion is that requiring `-m 1` or `--mainline 1` is a little cryptic
> > for someone who's just cherr
Hi Eric,
On Sat, 23 Mar 2019, Eric Sunshine wrote:
> On Sat, Mar 23, 2019 at 3:54 AM Ævar Arnfjörð Bjarmason
> wrote:
> > On Sat, Mar 23 2019, Keith Smiley wrote:
> > > In the case there are no files to stash, but the user asked to stash, we
> > > should exit 1 since the stashing failed.
> > > -
On Mon, Mar 25, 2019 at 9:49 AM Jeff King wrote:
> I think "just commits" is too restrictive. linux.git contains a tag of a
> tree, for example (we also have tags pointing to blobs in git.git, but
> they are not annotated).
>
> However, I could see an argument for the git-tag porcelain to notice a
On Sun, Mar 24, 2019 at 12:21:31PM -0400, Todd Zullinger wrote:
> > I ran into that, too. Using ASCIIDOC_DOCBOOK=docbook5 worked. The output
> > looked OK to me, but I only eyeballed it briefly. It's possible there
> > are subtle problems.
>
> Interesting. I did that last night as well, but it o
Hi C.J.
On Fri, 22 Mar 2019, C.J. Jameson wrote:
> Confirming Sergey's summary: at this point, I think my only residual
> opinion is that requiring `-m 1` or `--mainline 1` is a little cryptic
> for someone who's just cherry-picking a single commit, which happens
> to be a merge commit.
Two poin
On Mon, Mar 25, 2019 at 10:37:24AM -0400, Jeffrey Walton wrote:
> I used 'make -j 4 NO_GETTEXT=Yes' and I think that fixed the command
> line components. Or at least I did not see the error where I was
> previously seeing it.
>
> I am seeing a similar issue now for the GUI components (assuming
>
On Mon, Mar 25, 2019 at 08:50:14AM -0500, Robert Dailey wrote:
> On Thu, Mar 21, 2019 at 2:29 PM Jeff King wrote:
> > Tags can point to any object, including another tag. It looks like
> > somebody made an annotated tag of an annotated tag (probably by
> > mistake, given that they have the same t
Hi Mike,
On Fri, 22 Mar 2019, Mike Hommey wrote:
> On Fri, Mar 22, 2019 at 02:39:43PM +0100, Johannes Schindelin wrote:
> > Hi Peff & Mike,
> >
> > On Fri, 22 Mar 2019, Jeff King wrote:
> >
> > > On Wed, Mar 20, 2019 at 07:19:41PM +0900, Mike Hommey wrote:
> > >
> > > > I thought of a few options
On Mon, Mar 25, 2019 at 3:14 AM Johannes Sixt wrote:
>
> Am 25.03.19 um 07:40 schrieb Jeffrey Walton:
> > I'm working on a low-resource dev-board. It is missing a lot of
> > utilities to save space. I'm building Git 2.20 from sources. Make is
> > failing due to '/bin/sh: 1: msgfmt: not found'. I d
On Thu, Mar 21, 2019 at 2:29 PM Jeff King wrote:
> Tags can point to any object, including another tag. It looks like
> somebody made an annotated tag of an annotated tag (probably by
> mistake, given that they have the same tag-name).
>
> Try this:
>
> git init
> git commit -m commit --allow-
Change the error emitted when a commit-graph file is corrupt so that
we actually mention the commit-graph, e.g. change errors like:
error: improper chunk offset 00385e0c
To:
error: commit-graph improper chunk offset 00385e0c
As discussed in the commits leading up to this
Use the recently split-up components of the corrupt_graph_and_verify()
function to assert that we error on graphs that are too small. The
error was added in 2a2e32bdc5 ("commit-graph: implement git
commit-graph read", 2018-04-10), but there was no test for it.
Signed-off-by: Ævar Arnfjörð Bjarmaso
Split up the corrupt_graph_and_verify() function added in
d9b9f8a6fd ("commit-graph: verify catches corrupt signature",
2018-06-27) into its logical components of setting up the test itself,
doing the corruption in a particular way with "dd", and then finally
testing that stderr is what we expect.
When the commit-graph is written we end up calling
parse_commit(). This will in turn invoke code that'll consult the
existing commit-graph about the commit, if the graph is corrupted we
die.
We thus get into a state where a failing "commit-graph verify" can't
be followed-up with a "commit-graph wr
An earlier change implemented load_commit_graph_one_fd_st() in a way
that was bug-compatible with earlier code in terms of the "graph file
%s is too small" error message printing out the path to the
commit-graph (".git/objects/info/commit-graph").
But change that, because:
* A function that take
Change "commit-graph verify" to error on open() failures other than
ENOENT. As noted in the third paragraph of 283e68c72f ("commit-graph:
add 'verify' subcommand", 2018-06-27) and the test it added it's
intentional that "commit-graph verify" doesn't error out when the file
doesn't exist.
But let's
When core.commitGraph=true is set, various common commands now consult
the commit graph. Because the commit-graph code is very trusting of
its input data, it's possibly to construct a graph that'll cause an
immediate segfault on e.g. "status" (and e.g. "log", "blame", ...). In
some other cases wher
Make the commit-graph loading code work as a library that returns an
error code instead of calling exit(1) when the commit-graph is
corrupt. This means that e.g. "status" will now report commit-graph
corruption as an "error: [...]" at the top of its output, but then
proceed to work normally.
This
This v3 fixes issues raised by Ramsay in
https://public-inbox.org/git/1908832c-8dd0-377e-917b-acb33b002...@ramsayjones.plus.com/
While I was at it I changed a die("Whatevs") to
die("whatevs"). I.e. start with lower-case as discussed in other
places on-list recently.
The range-diff looks scarier t
On Sat, Mar 23 2019, Ramsay Jones wrote:
> Signed-off-by: Ramsay Jones
> ---
>
> Hi Ævar,
>
> If you need to re-roll your 'ab/commit-graph-fixes' branch, could you
> please squash this into the relevant patch (commit aeb244adbc
> ("commit-graph: don't early exit(1) on e.g. \"git status\"", 2019
On Mon, Mar 25, 2019 at 12:08:47PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
> On Mon, Mar 25 2019, SZEDER Gábor wrote:
>
> > When a git process runs in the background, it doesn't display
> > progress, only the final "done" line [1]. The condition to check that
> > are a bit too deep in the displa
On Mon, Mar 25 2019, SZEDER Gábor wrote:
> When a git process runs in the background, it doesn't display
> progress, only the final "done" line [1]. The condition to check that
> are a bit too deep in the display() function, and thus it calculates
> the progress percentage even when no progress
On Mon, Mar 25, 2019 at 06:02:13PM +0700, Duy Nguyen wrote:
> > @@ -225,6 +241,8 @@ static struct progress *start_progress_delay(const char
> > *title, uint64_t total,
> > progress->throughput = NULL;
> > progress->start_ns = getnanotime();
> > strbuf_init(&progress->counte
On Mon, Mar 25, 2019 at 5:41 PM SZEDER Gábor wrote:
>
> Some of the recently added progress indicators have quite long titles,
> which might be even longer when translated to some languages, and when
> they are shown while operating on bigger repositories, then the
> progress bar grows longer than
The following patches in this series want to handle the progress bar's
title and changing parts (i.e. the counter and the optional percentage
and throughput combined) differently.
To prepare for those changes assemble the changing parts in a separate
strbuf before printing.
Signed-off-by: SZEDER
Some of the recently added progress indicators have quite long titles,
which might be even longer when translated to some languages, and when
they are shown while operating on bigger repositories, then the
progress bar grows longer than the default 80 column terminal width.
When the progress bar e
When a git process runs in the background, it doesn't display
progress, only the final "done" line [1]. The condition to check that
are a bit too deep in the display() function, and thus it calculates
the progress percentage even when no progress will be displayed
anyway.
Restructure the display(
When the progress bar includes throughput, its length can shorten as
the unit of display changes from KiB to MiB. To cover up remnants of
the previous progress bar when such a change of units happens we
always print three spaces at the end of the progress bar.
Alas, covering only three characters
Ever since the progress infrastructure was introduced in 96a02f8f6d
(common progress display support, 2007-04-18), display_progress() has
returned an int, telling callers whether it updated the progress bar
or not. However, this is:
- useless, because over the last dozen years there has never b
This patch series fixes two progress display issues:
- When showing throughput, and the both the total and the throughput
change units in the same update, than the previously shown
progress bar is not cleaned up properly:
Receiving objects: 25% (2901/11603), 772.01 KiB | 733.00 K
(Including Stefan, in case he's still interested in git and planned
something for the "submodule" restore part I mention below)
On Fri, Mar 08, 2019 at 10:01:25AM -0800, Elijah Newren wrote:
> Thanks for working on this; overall looks really good. I've got a few
> comments here and there on the w
(resending in plain text mode, sorry for the noise)
Thanks Junio, that's super helpful!
A month or two ago I contacted the author of git-hyper-blame, Matt
Giuca, asking whether anyone had looked into adding the feature to git
blame. I didn't receive a response but maybe that prompted Barret
Rhode
On Mon, Mar 25 2019, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> On Sun, Mar 24 2019, Junio C Hamano wrote:
>>
>>> Ævar Arnfjörð Bjarmason writes:
>>>
The reason I'm raising this is that it seems like sweeping an existing
issue under the rug. We document that the "si
Am 25.03.19 um 07:40 schrieb Jeffrey Walton:
> I'm working on a low-resource dev-board. It is missing a lot of
> utilities to save space. I'm building Git 2.20 from sources. Make is
> failing due to '/bin/sh: 1: msgfmt: not found'. I don't cross-compile
> because that's a bigger pain in the ass tha
99 matches
Mail list logo
