On Sat, Dec 08 2018, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> On Fri, Dec 7, 2018 at 1:40 PM Jonathan Nieder wrote:
>>>
>>> Brandon Williams wrote:
>>>
>>> > Signed-off-by: Brandon Williams
>>> > ---
>>> > .mailmap | 1 +
>>> > 1 file changed, 1 insertion(+)
>>>
>>> I can confirm
On Fri, Dec 07 2018, Jonathan Nieder wrote:
> Hi,
>
> Konstantin Ryabitsev wrote:
>
>> Every now and again I come across a patch sent to LKML without a leading
>> "diff a/foo b/foo" -- usually produced by quilt. E.g.:
>>
>> https://lore.kernel.org/lkml/20181125185004.151077...@linutronix.de/
>>
On Fri, Dec 07 2018, Konstantin Ryabitsev wrote:
> Hi, all:
>
> Every now and again I come across a patch sent to LKML without a leading
> "diff a/foo b/foo" -- usually produced by quilt. E.g.:
>
> https://lore.kernel.org/lkml/20181125185004.151077...@linutronix.de/
>
> I am guessing quilt does
Let's ignore how bad this patch is for git.git, and just focus on how
diff.colorMoved treats it:
diff --git a/builtin/add.c b/builtin/add.c
index f65c172299..d1155322ef 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -6,5 +6,3 @@
#include "cache.h"
-#include
On Thu, Dec 06 2018, Jeff King wrote:
> On Thu, Dec 06, 2018 at 10:08:57AM +0900, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > In my opinion this feature is so contrary to Git's general assumptions
>> > that it's likely to create a ton of information leaks of the supposedly
>> >
On Wed, Dec 05 2018, Josh Steadmon wrote:
> Breaks load_commit_graph_one() into a new function,
> parse_commit_graph(). The latter function operates on arbitrary buffers,
> which makes it suitable as a fuzzing target.
>
> Adds fuzz-commit-graph.c, which provides a fuzzing entry point
>
On Wed, Dec 05 2018, Coiner, John wrote:
I forgot to mention this in my initial reply in
<878t13zp8y@evledraar.gmail.com>, but on a re-reading I re-spotted
this:
> - hashes are secret. If the hashes from a protected tree leak, the
> data also leaks. No check on the server prevents it
On Wed, Dec 05 2018, Duy Nguyen wrote:
> On Wed, Dec 5, 2018 at 9:46 PM Derrick Stolee wrote:
>> This directory-level security is not a goal for VFS for Git, and I don't
>> see itbecoming a priority as it breaks a number of design decisions we
>> made in our object storage and communication
On Wed, Dec 05 2018, Coiner, John wrote:
> I'm an engineer with AMD. I'm looking at whether we could switch our
> internal version control to a monorepo, possibly one based on git and
> VFSForGit.
>
> One obstacle to moving AMD to git/VFSForGit is the lack of access
> control support in git.
On Wed, Dec 05 2018, SZEDER Gábor wrote:
> On Wed, Dec 05, 2018 at 03:01:41PM +0100, Ævar Arnfjörð Bjarmason wrote:
>> >> decide to stress test in advance, since we'd either flock() the trash
>> >> dir, or just mktemp(1)-it.
>> >
>> > While '
On Wed, Dec 05 2018, Jonathan Nieder wrote:
> Martin Mares wrote[1]:
>
>> After upgrade to Stretch, gitweb no longer finds the configuration file
>> "gitweb_config.perl" in the current directory. However, "man gitweb" still
>> mentions this as one of the possible locations of the config file
On Wed, Dec 05 2018, SZEDER Gábor wrote:
> On Tue, Dec 04, 2018 at 07:11:08PM +0100, Ævar Arnfjörð Bjarmason wrote:
>> It's a frequent annoyance of mine in the test suite that I'm
>> e.g. running t*.sh with some parallel "prove" in one screen, and then I
>>
On Tue, Dec 04 2018, SZEDER Gábor wrote:
> Unfortunately, we have a few flaky tests, whose failures tend to be
> hard to reproduce. We've found that the best we can do to reproduce
> such a failure is to run the test repeatedly while the machine is
> under load, and wait in the hope that the
On Tue, Dec 04 2018, SZEDER Gábor wrote:
> The number of parallel invocations is determined by, in order of
> precedence: the number specified as '--stress=', or the value of
> the GIT_TEST_STRESS_LOAD environment variable, or twice the number of
> available processors in '/proc/cpuinfo', or 8.
exists. It's a legitimate use-case
to point to an existing alternate that hasn't been populated yet, but
pointing to one where an "X/objects" or "X/.git/objects" directory
exists is definitely a mistake we should warn the user about.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
should die() in that case, but let's start by adding a test
here to assert the long-standing existing behavior.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
t/t5613-info-alternate.sh | 7 +++
1 file changed, 7 insertions(+)
diff --git a/t/t5613-info-alternate.sh b/t/t5613-info-alternate.sh
index
's confusing to emit an "error" when e.g. "git fsck" will exit with
0, so let's emit a "warning:" instead.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
sha1-file.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/sha1-file.c b/sha1-file.c
This adds a warning for the issue discussed upthread. As noted in
these patches we've been emitting an "error" while not impacting the
exit code, should we die() instead? Maybe, but until there's consensus
on that let's change this to warning() while we're at it.
Ævar Arnfjörð Bj
On Fri, Feb 09 2018, Nguyễn Thái Ngọc Duy wrote:
> +static int show_gitcomp(struct parse_opt_ctx_t *ctx,
> + const struct option *opts)
> +{
Says it returns 'static int'...
> [...]
> + exit(0);
Then just exits...
> + /* lone --git-completion-helper is
On Sat, Dec 01 2018, Cameron Boehmer wrote:
> 1) add a new flag
> -l, --local
> Do not consult git config --global core.excludesFile in
> determining what files git ignores. This is useful in conjunction with
> -x/-X to preserve user files while removing build artifacts.
Or perhaps a
On Sun, Dec 02 2018, Robert P. J. Day wrote:
> as part of an upcoming git class i'm delivering, i thought it would
> be amusing to demonstrate the maximum length of colliding SHA-1
> prefixes in a repository (in my case, i use the linux kernel git repo
> for most of my examples).
>
> is
On Fri, Nov 30 2018, Duy Nguyen wrote:
> On Fri, Nov 30, 2018 at 12:05 AM Ævar Arnfjörð Bjarmason
> wrote:
>> Assuming greenfield development (which we definitely don't have), I
>> don't like the "restore-files" name, but the alternative that makes
>> sens
On Fri, Nov 30 2018, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>>> I had to delay -rc2 to see these last minute tweaks come to some
>>> reasonable place to stop at, and I do not think we want to delay the
>>> final any longer or destablizing it further by piling last minute
>>>
On Thu, Nov 29 2018, Ævar Arnfjörð Bjarmason wrote:
> On Thu, Nov 29 2018, Nguyễn Thái Ngọc Duy wrote:
>
>> v3 sees switch-branch go back to switch-branch (in v2 it was
>> checkout-branch). checkout-files is also renamed restore-files (v1 was
>> restore-paths). Hopefu
On Thu, Nov 29 2018, Nguyễn Thái Ngọc Duy wrote:
> v3 sees switch-branch go back to switch-branch (in v2 it was
> checkout-branch). checkout-files is also renamed restore-files (v1 was
> restore-paths). Hopefully we won't see another rename.
>
> I'll try to summarize the differences between the
On Thu, Nov 29 2018, Johannes Schindelin wrote:
> Hi Ævar,
>
> On Thu, 29 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
>
>> On Thu, Nov 29 2018, Johannes Schindelin wrote:
>>
>> > On Thu, 29 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
>> >
>> &
On Thu, Nov 29 2018, Mateusz Loskot wrote:
> On Thu, 29 Nov 2018 at 16:03, Ævar Arnfjörð Bjarmason
> wrote:
>> On Wed, Nov 28 2018, Mateusz Loskot wrote:
>> >
>> > (using git version 2.19.2.windows.1)
>> >
>> > I've just encountered one of those
On Thu, Nov 29 2018, Stefanie Leisestreichler wrote:
> Hi.
>
> I have done this (on box A):
>
> git commit -m "Message"
> git tag -a 0.9.0
> git push origin master
>
> In my local repository, when I run "git tag" it is showing me "0.9.0".
>
> Then I did (on box B)
> git clone
On Wed, Nov 28 2018, Mateusz Loskot wrote:
> Hi,
>
> (using git version 2.19.2.windows.1)
>
> I've just encountered one of those WTH moments.
>
> I have a bare repository
>
> core.git (BARE:master) $ git branch
> 1.0
> 2.0
> * master
>
> core.git (BARE:master) $ git tag
> 1.0.1651
> 1.0.766
On Thu, Nov 29 2018, Johannes Schindelin wrote:
> Hi Ævar,
>
> On Thu, 29 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
>
>> On Thu, Nov 29 2018, Johannes Schindelin wrote:
>>
>> > On Wed, 28 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
>> >
>> >>
On Thu, Nov 29 2018, Johannes Schindelin wrote:
> Hi Ævar,
>
> On Wed, 28 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
>
>> Change the semantics of the "--range-diff" option so that the regular
>> diff options can be provided separately for the range-diff and the
&
On Wed, Nov 28 2018, Derrick Stolee via GitGitGadget wrote:
> One of the biggest remaining pain points for users of very large
> repositories is the time it takes to run 'git push'. We inspected some slow
> pushes by our developers and found that the "Enumerating Objects" phase of a
> push was
On Wed, Nov 28 2018, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> What do you think about some patch like that which retains the plumbing
>> behavior for things like read-tree, doesn't introduce "precious" or
>> "trashable",
Let's add one.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
t/t3206-range-diff.sh | 60 +++
1 file changed, 60 insertions(+)
diff --git a/t/t3206-range-diff.sh b/t/t3206-range-diff.sh
index 90def330bd..bc5facc1cd 100755
--- a/t/t3206-range-diff.sh
+++ b/t/t
and
the patch independently, now you can, and the implementation is much
less nasty now that we're not having to share diffopts across two
different modes of operation.
Ævar Arnfjörð Bjarmason (2):
format-patch: add test for --range-diff diff output
format-patch: allow for independent diff & r
ch boilerplate to do
all the frees with/without the die() and not worth it. 2) We call
repo_init_revisions() for "rd_rev" even though we could get away with
a shallow copy like the code we're replacing (and which
show_range_diff() itself does). This is to make this code more easily
u
On Wed, Nov 28 2018, Martin Ågren wrote:
> Asciidoctor removes the indentation of each line in these tables, so the
> last lines of each table have a completely broken alignment.
>
> Similar to 379805051d ("Documentation: render revisions correctly under
> Asciidoctor", 2018-05-06), use an
On Thu, Nov 22 2018, Jeff King wrote:
> On Thu, Nov 22, 2018 at 02:17:01AM -0800, Carlo Arenas wrote:
>> PS. upstreaming the PERL_PATH fix is likely to be good to do soonish
>> as I presume at least all BSD might be affected, let me know if you
>> would rather me do that instead as I suspect we
On Wed, Nov 28 2018, Thomas Braun wrote:
Looks much better this time around.
> The -G option of log looks for the differences whose patch text
> contains added/removed lines that match regex.
>
> As the concept of patch text only makes sense for text files, we need to
> ignore binary files
On Wed, Nov 28 2018, Johannes Schindelin wrote:
> Hi Jonathan,
>
> On Tue, 27 Nov 2018, Jonathan Nieder wrote:
>
>> At https://bugs.debian.org/914695 is a report of a test regression in
>> an outside project that is very likely to have been triggered by the
>> new faster rebase code.
>
> From
On Wed, Nov 28 2018, Bryan Turner wrote:
> On Tue, Nov 27, 2018 at 3:47 PM Ævar Arnfjörð Bjarmason
> wrote:
>>
>>
>> On Tue, Nov 27 2018, Bryan Turner wrote:
>>
>> >
>> > Is there anything I can set, perhaps some invalid configuration
>> &
On Tue, Nov 27 2018, Bryan Turner wrote:
> Something of an odd question, but is there something I can do in the
> configuration for a repository that forces any "git gc" run in that
> repository to always fail without doing anything? (Ideally I'd like to
> make "git reflog expire" _also_ fail.)
On Tue, Nov 27 2018, Johannes Schindelin wrote:
> Hi Junio & Paul,
>
> On Mon, 26 Nov 2018, Junio C Hamano wrote:
>
>> Paul-Sebastian Ungureanu writes:
>>
>> > The old shell script `git-stash.sh` was removed and replaced
>> > entirely by `builtin/stash.c`. In order to do that, `create` and
>>
On Tue, Nov 27 2018, Will wrote:
> On 27 Nov 2018, at 19:24, Stefan Beller wrote:
>
>> The different phases taking each one line takes up precious
>> screen real estate, so another approach would be delete the line
>> after one phase is finished, such that you'd only see the currently
>> active
An earlier change changed this paragraph to make the first line quite
short as to produce a more minimal diff. Let's re-flow it. There's no
changes here if diffed with --word-diff.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
t/README | 9 -
1 file changed, 4 insertions(+), 5 deletions
that need unzip", 2009-03-16). Fix the docs accordingly.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
t/README | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/t/README b/t/README
index b6ec28f634..3139f4330a 100644
--- a/t/README
+++ b/t/README
@@ -202,20
TODO_TESTS if they're already TODO tests.
1. https://public-inbox.org/git/875zwm15k2@evledraar.gmail.com/
Signed-off-by: Ævar Arnfjörð Bjarmason
---
ci/lib-travisci.sh | 2 +-
t/README | 18 +--
t/t-basic.sh | 81 +++---
t/t
ere.
Let's clean up this confusion by renaming the section, and while we're
at it improve the example. Usually we don't use the PERL prerequisite,
and we should accurately describe why you'd want to use prerequisites,
as opposed to GIT_SKIP_TESTS. So let's say "Tests that depend[...]"
Add a test for the when GIT_SKIP_TESTS is used to skip entire test
files. Support for this was added back in 04ece59399 ("GIT_SKIP_TESTS:
allow users to omit tests that are known to break", 2006-12-28), but
never tested for.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
t/t-bas
o convert the grafts into replace refs.
hint:
hint: Turn this message off by running
hint: "git config advice.graftFileDeprecated false"
Add a check for that case and skip printing the advice while the user
is busy following our advice.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
bui
On Tue, Nov 27 2018, Eric Sunshine wrote:
> On Tue, Nov 27, 2018 at 11:43 AM Ævar Arnfjörð Bjarmason
> wrote:
>> Avoid a bug in dash that's been fixed ever since its
>> ec2c84d ("[PARSER] Fix clobbering of checkkwd", 2011-03-15)[1] first
>> released with das
uot;svn.pathnameencoding"
before URL encoding", 2016-02-09).
This particular test has been failing since 5f9674243d ("config: add
--expiry-date", 2017-11-18).
1. https://git.kernel.org/pub/scm/utils/dash/dash.git/
Signed-off-by: Ævar Arnfjörð Bjarmason
---
t/t1300-config.sh
On Mon, Nov 26 2018, Junio C Hamano wrote:
> Per Lundberg writes:
>
>> How about something like this:
>> ...
>> Would this be a reasonable compromise for everybody?
>
> I do not think you'd need to introduce such a deliberately breaking
> change at all. Just introduce a new "precious" class,
On Tue, Nov 20 2018, Duy Nguyen wrote:
> On Mon, Nov 19, 2018 at 04:19:53PM +0100, Duy Nguyen wrote:
>> I promise to come back with something better (at least it still
>> sounds better in my mind). If that idea does not work out, we can
>> come back and see if we can improve this.
>
> So this
On Mon, Nov 26 2018, Duy Nguyen wrote:
> On Mon, Nov 26, 2018 at 4:34 PM Ævar Arnfjörð Bjarmason
> wrote:
>>
>>
>> On Mon, Nov 26 2018, Duy Nguyen wrote:
>>
>> > On Mon, Nov 26, 2018 at 10:30 AM Per Lundberg
>> > wrote:
>>
On Sun, Nov 25 2018, Carlo Marcelo Arenas Belón wrote:
> Likely still missing changes as it only completes a run with a minimal
> number of dependencies but open for feedback
>
> Requires pkgsrc packages for gmake, perl, bash and curl and completes a run
>
> $ gmake
On Mon, Nov 26 2018, Duy Nguyen wrote:
> On Mon, Nov 26, 2018 at 10:30 AM Per Lundberg wrote:
>>
>> On 11/13/18 1:22 AM, brian m. carlson wrote:
>> > This is going to totally hose automation. My last job had files which
>> > might move from tracked to untracked (a file that had become
On Mon, Nov 26 2018, Per Lundberg wrote:
> On 11/13/18 1:22 AM, brian m. carlson wrote:
>> This is going to totally hose automation. My last job had files which
>> might move from tracked to untracked (a file that had become generated),
>> and long-running CI and build systems would need to be
On Sun, Nov 25 2018, Torsten Bögershausen wrote:
> On Sun, Nov 25, 2018 at 05:28:35AM +0100, Torsten Bögershausen wrote:
>> On Sat, Nov 24, 2018 at 08:33:37PM +0100, Ævar Arnfjörð Bjarmason wrote:
>> >
>> > On Wed, Sep 05 2018, Ævar Arnfjörð Bjarmason wrote:
>
On Fri, Nov 23 2018, Guilhem Bonnefille wrote:
> I'm managing many bare repositories for development teams.
>
> One service we want to offer is to let developers retrieve old state
> of the repository up to 30 days. For example, one developer
> (accidently) removed (push -f) a branch/tag and
I've had access to the GCC Compile Farm for testing on various
architectures for a while. Around the 2.19.0 release I submitted some
patches / bug reports found there.
I've now improved this to run it via GitLab CI & made the output
accessible. Outline of how this works at
On Wed, Nov 21 2018, Junio C Hamano wrote:
> * "git rebase" and "git rebase -i" have been reimplemented in C.
Here's another regression in the C version (and rc1), note: the
sha1collisiondetection is just a stand in for "some repo":
(
rm -rf /tmp/repo &&
git init
On Wed, Sep 05 2018, Ævar Arnfjörð Bjarmason wrote:
> On Wed, Sep 05 2018, Eric Sunshine wrote:
>
>> On Wed, Sep 5, 2018 at 4:29 AM Ævar Arnfjörð Bjarmason
>> wrote:
>>> I recently gained access to a Solaris 10 SPARC (5.10) box and discovered
>>> t
On Sun, Oct 21 2018, Nguyễn Thái Ngọc Duy wrote:
This change has a regression in 2.20:
> [...]
> static void files_reflog_path(struct files_ref_store *refs,
> struct strbuf *sb,
> const char *refname)
> @@ -158,6 +178,9 @@ static void
On Sat, Nov 24 2018, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> Change the narrow test added in 31e2617a5f ("format-patch: add
>> --range-diff option to embed diff in cover letter", 2018-07-22) to
>> test the full output. This te
t.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
t/t3206-range-diff.sh | 27 ++-
1 file changed, 22 insertions(+), 5 deletions(-)
diff --git a/t/t3206-range-diff.sh b/t/t3206-range-diff.sh
index e497c1358f..0235c038be 100755
--- a/t/t3206-range-diff.sh
+++ b/t/t3206-ran
x.org/git/87d0ri7gbs@evledraar.gmail.com/
Signed-off-by: Ævar Arnfjörð Bjarmason
---
builtin/log.c | 7 ++-
t/t3206-range-diff.sh | 12
2 files changed, 6 insertions(+), 13 deletions(-)
diff --git a/builtin/log.c b/builtin/log.c
index 0fe6f9ba1e..7cd2db0be9 100644
--- a/builtin/log.c
[Dropping LKML & git-packagers from CC]
On Thu, Nov 22 2018, Eric Sunshine wrote:
> On Thu, Nov 22, 2018 at 10:58 AM Ævar Arnfjörð Bjarmason
> wrote:
>> There's a regression related to this that I wanted to send a headsup
>> for, but don't have time to fix today. Now rang
On Thu, Nov 22 2018, Jeff King wrote:
> On Wed, Nov 21, 2018 at 11:48:14AM +0100, Ævar Arnfjörð Bjarmason wrote:
>
>>
>> On Wed, Nov 21 2018, Junio C Hamano wrote:
>>
>> > * jk/loose-object-cache (2018-11-13) 9 commits
>> > (merged to 'next' on 20
have a local variable called
'num_extra_edges'.
It can be confusing on first sight whether large edges and extra edges
refer to the same thing or not, but they do, so let's rename those
variables to 'num_large_edges'.
Signed-off-by: SZEDER Gábor
Signed-off-by: Ævar Arnfjörð Bjarmason
---
commit
for the initial bug report & subsequent discussion about other
approaching to solving this.
1. https://public-inbox.org/git/20181015165447.gh19...@szeder.dev/
Reported-by: SZEDER Gábor
Signed-off-by: Ævar Arnfjörð Bjarmason
---
commit-graph.c | 2 +-
1 file changed, 1 insertion(+), 1
for such commits.
Don't call write_graph_chunk_large_edges() when that chunk won't be
written to spare an unnecessary iteration over all commits.
Signed-off-by: SZEDER Gábor
Signed-off-by: Ævar Arnfjörð Bjarmason
---
commit-graph.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
pending
on the graph we're processing. A later change will make this explicit
to the user.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
commit-graph.c | 48 +++-
1 file changed, 39 insertions(+), 9 deletions(-)
diff --git a/commit-graph.c b/commit-grap
797222/797222), done.
Writing out commit graph in 4 passes: 100% (318/318), done.
The "Counting distinct commits in commit graph" phase will spend most
of its time paused at "0/*" as we QSORT(...) the list. That's not
optimal, but at least we don't seem to be stallin
1 second. So always show it in the commit message examples,
that's less confusing for the reader.
SZEDER Gábor (2):
commit-graph: rename 'num_extra_edges' variable to 'num_large_edges'
commit-graph: don't call write_graph_chunk_large_edges() unnecessarily
Ævar Arnfjörð Bjarmason (8):
ut commit graph in 4 passes: 100% (318/318), done.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
commit-graph.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/commit-graph.c b/commit-graph.c
index 80f201adf4..6c6edc679b 100644
--- a/commit-graph.c
+++ b/commi
use the plural function we need to use this format.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
commit-graph.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/commit-graph.c b/commit-graph.c
index dc57b8fedc..3de65bc2e9 100644
--- a/commit-graph.c
+++ b/commit-graph.c
@@
Signed-off-by: Ævar Arnfjörð Bjarmason
---
commit-graph.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/commit-graph.c b/commit-graph.c
index 43b15785f6..199155bd68 100644
--- a/commit-graph.c
+++ b/commit-graph.c
@@ -890,7 +890,6 @@ void write_commit_graph(const char *obj_dir,
close
short of 100%. So let's make sure
it snaps to 100% at the end.
The inverse case is also possible and more likely. I.e. that a new
pack has been added between approximate_object_count() and
for_each_packed_object(). In that case the percentage will go beyond
100%, and we'll do nothing to snap it back
Finding commits for commit graph from 165203 refs: 100% (165203/165203),
done.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
commit-graph.c | 25 ++---
1 file changed, 18 insertions(+), 7 deletions(-)
diff --git a/commit-graph.c b/commit-graph.c
index 42d8365f0d..43b15785f6 1
Signed-off-by: Ævar Arnfjörð Bjarmason
---
commit-graph.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/commit-graph.c b/commit-graph.c
index cb1aebeb79..21751231e0 100644
--- a/commit-graph.c
+++ b/commit-graph.c
@@ -890,7 +890,6 @@ void write_commit_graph(const char *obj_dir,
close
ing out commit graph: 2399912, done.
The "Counting distinct commits in commit graph" phase will spend most
of its time paused at "0/*" as we QSORT(...) the list. That's not
optimal, but at least we don't seem to be stalling anymore.
Signed-off-by: Ævar Arnfjörð Bjarmason
-
packed objects: 100%
(6365442/6365442), done.
Annotating commit graph: 100% (2391666/2391666), done.
Computing commit graph generation numbers: 100% (797222/797222), done.
Writing out commit graph in 5 passes: 100% (3986110/3986110), done.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
ter change will make this explicit
to the user.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
commit-graph.c | 48 +++-
1 file changed, 39 insertions(+), 9 deletions(-)
diff --git a/commit-graph.c b/commit-graph.c
index d11370a2b3..e32a5cc1bc 100644
--- a/
: don't call write_graph_chunk_large_edges() unnecessarily
Ævar Arnfjörð Bjarmason (8):
commit-graph write: rephrase confusing progress output
commit-graph write: add "Writing out" progress output
commit-graph write: more descriptive "writing out" output
commit-graph
Finding commits for commit graph from 165203 refs: 100% (165203/165203),
done.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
commit-graph.c | 25 ++---
1 file changed, 18 insertions(+), 7 deletions(-)
diff --git a/commit-graph.c b/commit-graph.c
index d6166beb19..cb1aebeb79 1
short of 100%. So let's make sure
it snaps to 100% at the end.
The inverse case is also possible and more likely. I.e. that a new
pack has been added between approximate_object_count() and
for_each_packed_object(). In that case the percentage will go beyond
100%, and we'll do nothing to snap it back
for such commits.
Don't call write_graph_chunk_large_edges() when that chunk won't be
written to spare an unnecessary iteration over all commits.
Signed-off-by: SZEDER Gábor
Signed-off-by: Ævar Arnfjörð Bjarmason
---
commit-graph.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
t.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
commit-graph.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/commit-graph.c b/commit-graph.c
index e32a5cc1bc..8e5970f0b9 100644
--- a/commit-graph.c
+++ b/commit-graph.c
@@ -780,6 +780,7 @@ void write_commit_gr
for the initial bug report & subsequent discussion about other
approaching to solving this.
1. https://public-inbox.org/git/20181015165447.gh19...@szeder.dev/
Reported-by: SZEDER Gábor
Signed-off-by: Ævar Arnfjörð Bjarmason
---
commit-graph.c | 2 +-
1 file changed, 1 insertion(+), 1
have a local variable called
'num_extra_edges'.
It can be confusing on first sight whether large edges and extra edges
refer to the same thing or not, but they do, so let's rename those
variables to 'num_large_edges'.
Signed-off-by: SZEDER Gábor
Signed-off-by: Ævar Arnfjörð Bjarmason
---
commit
On Thu, Nov 22, 2018 at 11:31 AM Stephen P. Smith wrote:
>
> On Wednesday, November 21, 2018 2:00:16 AM MST Junio C Hamano wrote:
> > [Stalled]
> >
> > * lt/date-human (2018-07-09) 1 commit
> > - Add 'human' date format
> >
> > A new date format "--date=human" that morphs its output depending
>
>
On Wed, Nov 21 2018, Thomas Braun wrote:
> The -G option of log looks for the differences whose patch text
> contains added/removed lines that match regex.
>
> The concept of differences only makes sense for text files, therefore
> we need to ignore binary files when searching with -G as
On Wed, Nov 21 2018, Thomas Braun wrote:
> The -S option of log looks for differences that changes the
> number of occurrences of the specified string (i.e. addition/deletion)
> in a file.
>
> Add a test to ensure that we keep looking into binary files with -S
> as changing that would break
On Wed, Nov 21 2018, Junio C Hamano wrote:
> * jk/loose-object-cache (2018-11-13) 9 commits
> (merged to 'next' on 2018-11-18 at 276691a21b)
> + fetch-pack: drop custom loose object cache
> + sha1-file: use loose object cache for quick existence check
> + object-store: provide helpers for
On Wed, Nov 21 2018, Jonathan Nieder wrote:
> Junio C Hamano wrote:
>
>> This series has a strong smell of pushing back by the
>> toolsmiths who refuse to promptly upgrade to help their users, and
>> that is why I do not feel entirely happy with this series.
>
> Last reply, I
ommit graph" phase will spend most
of its time paused at "0/*" as we QSORT(...) the list. That's not
optimal, but at least we don't seem to be stalling anymore.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
commit-graph.c | 13 +
1 file changed, 13 insertions(+)
diff --gi
Finding commits for commit graph from 165203 refs: 100% (165203/165203),
done.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
commit-graph.c | 28 +---
1 file changed, 21 insertions(+), 7 deletions(-)
diff --git a/commit-graph.c b/commit-graph.c
index 7c1afa4704..fd1fd61750 1
short of 100%. So let's make sure
it snaps to 100% at the end.
The inverse case is also possible and more likely. I.e. that a new
pack has been added between approximate_object_count() and
for_each_packed_object(). In that case the percentage will go beyond
100%, and we'll do nothing to snap it back
Signed-off-by: Ævar Arnfjörð Bjarmason
---
commit-graph.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/commit-graph.c b/commit-graph.c
index fd1fd61750..0e98679bce 100644
--- a/commit-graph.c
+++ b/commit-graph.c
@@ -888,7 +888,6 @@ void write_commit_graph(const char *obj_dir,
close
1 - 100 of 2740 matches
Mail list logo
