"Derrick Stolee via GitGitGadget" writes:
> From: Derrick Stolee
>
> The test script t6501-freshen-objects.sh has some tests that care
> if 'git gc' has any output to stderr. This is intended to say that
> no warnings occurred related to broken links. However, when we
> have operations that
Jonathan Tan writes:
> Suppose a server has the following commit graph:
>
> A B
> \ /
>O
>
> We create a client by cloning A from the server with depth 1, and add
> many commits to it (so that future fetches span multiple requests due to
> lengthy negotiation). If it then fetches B
Matthew DeVore writes:
> The tree:0 filter does not need to traverse the trees that it has
> filtered out, so optimize list-objects and list-objects-filter to skip
> traversing the trees entirely. Before this patch, we iterated over all
> children of the tree, and did nothing for all of them,
Ramsay Jones writes:
> Signed-off-by: Ramsay Jones
> ---
>
> Hi Junio,
>
> Since I didn't get any adverse comments, this version has the RFC
> label removed. Also, given that it seems the vcs-svn directory is
> not going away soon, I have included those headers this time as well.
>
> [Note: my
"Derrick Stolee via GitGitGadget" writes:
> The commit-graph feature is starting to stabilize. Based on what is in
> master right now, we have:
>
> Git 2.18:
>
> * Ability to write commit-graph (requires user interaction).
>
>
> * Commit parsing is faster when commit-graph exists.
>
Jeff King writes:
> Whereas for the new config variable, you'd probably set it not because
> you want it quiet all the time, but because you want to get some time
> savings. So there it does make sense to me to explain.
>
> Other than that, this seems like an obvious and easy win. It does feel a
Jeff King writes:
> I'd probably call it something verbose and boring like
> --use-default-with-uninteresting or --default-on-negative.
> I dunno.
These two names are improvement, but there needs a hint that the
change we are interested in is to use default even when revs are
given as long as
Jonathan Tan writes:
>> By doing so we'll have access to the util pointer for longer that
>> contains the commits that we need to fetch, which will be
>> useful in a later patch.
>
> It seems that the main point of this patch is so that the OIDs be stored
> in changed_submodule_names, because
Stefan Beller writes:
> This is based on ao/submodule-wo-gitmodules-checked-out.
Thanks. I had an impression that we were not entirely happy with
the topic and are expecting a reroll, but let's hope that the part
we expect to be updated won't have much overlaps.
> A range-diff below shows how
Jonathan Nieder writes:
> The rule says
>
> install-html: html
> $(INSTALL) -d -m 755 $(DESTDIR)$(htmldir)
> $(INSTALL) -m 644 $^ $(DESTDIR)$(htmldir)
>
> and $^ substitutes to "html" after this change.
Sorry about that.
From: Junio C Hamano
Date: Thu, 18 Oct 2018 11:07:17 +0900
Jonathan Nieder writes:
>> -install-html: $(GIT_SUBTREE_HTML)
>> +install-html: html
>
> This broke the build for me:
>
> make[2]: Entering directory '/build/git-2.19.1+next.20181016/contrib/subtree'
> install -m 644 html
> /build/git-2.19.1+next.20181016/debian/tmp/usr/share/doc/git/html
>
Ævar Arnfjörð Bjarmason writes:
>> sites could do the same polling and mirroring. I am just too lazy
>> to open a new account at yet another hosting site to add that for
>> loop, but I may choose to when I am absolutely bored and nothing
>> else to do ;-).
>
> Do you mind if I squat
Ævar Arnfjörð Bjarmason writes:
>> This is all to say: having a maximum size is good. 512 is big enough
>> to cover _most_ commits, but not so big that we may store _really_ big
>> filters.
>
> Makes sense. 512 is good enough to hardcode initially, but I couldn't
> tell from briefly skimming the
Duy Nguyen writes:
> Just fyi I also have some wip changes that add the forth "precious"
> class in addition to tracked, untracked and ignored [1]. If someone
> has time it could be another option to pick up.
It is much more sensible than gaining the ability to express
precious by trading away
Johannes Schindelin writes:
>> In any case, you can use "http..$variable" to say "I want the
>> http.$variable to be in effect but only when I am talking to ".
>> Does it make sense for this new variable, too? That is, does it
>> benefit the users to be able to do something like this?
>>
>>
> @@ -887,11 +887,14 @@ static int store_updated_refs(const char *raw_url,
> const char *remote_name,
> rc |= update_local_ref(ref, what, rm, ,
> summary_width);
> free(ref);
> -
> Currently when git-fetch is asked to recurse into submodules, it dispatches
> a plain "git-fetch -C " (with some submodule related options
> such as prefix and recusing strategy, but) without any information of the
> remote or the tip that should be fetched.
>
> This works surprisingly well in
The tree:0 filter does not need to traverse the trees that it has
filtered out, so optimize list-objects and list-objects-filter to skip
traversing the trees entirely. Before this patch, we iterated over all
children of the tree, and did nothing for all of them, which was
wasteful.
Signed-off-by:
On Sun, Oct 14, 2018 at 4:15 PM Junio C Hamano wrote:
>
> This step looks more like "ow, we could have done the tree:0 support
> that is in 'next' better" than a part of "here is a series to do
> tree:N for non zero value of N".
>
> If that is the case, I'd prefer to see this step polished enough
On Wed, Oct 17, 2018 at 04:31:19PM +0200, Duy Nguyen wrote:
> On Wed, Oct 17, 2018 at 12:44 AM brian m. carlson
> wrote:
> > Honestly, anything in the .git directory that is not the v3 pack indexes
> > or the loose object file should be in exactly one hash algorithm. We
> > could simply just
On Tue, Oct 16, 2018 at 10:54:23AM +0900, Junio C Hamano wrote:
> Even though in hex.c I see mixture of *_algo and *_algop helper
> functions, I see only "algo" variants above. Is it our official
> stance to use primarily the integer index into the algo array when
> specifying the hash, and when
On Mon, Oct 15, 2018 at 03:12:11AM -0700, Johannes Schindelin via GitGitGadget
wrote:
> From: Johannes Schindelin
>
> This should be more reliable than the current method, and prepares the
> test suite for a consistent way to clean up before re-running the tests
> with different options.
This
On Wed, Oct 17, 2018 at 06:12:41PM +0200, SZEDER Gábor wrote:
> On macOS there is a MIN macro already defined in the system headers,
> resulting in the following error:
>
> CC sha256/block/sha256.o
> sha256/block/sha256.c:133:9: error: 'MIN' macro redefined
> [-Werror,-Wmacro-redefined]
> This patch started as a refactoring to make 'get_next_submodule' more
> readable, but upon doing so, I realized that "git fetch" of the submodule
> actually doesn't need to be run in the submodules worktree. So let's run
> it in its git dir instead.
The commit message needs to be updated, I
On Tue, Oct 16, 2018 at 05:17:53PM +0200, Duy Nguyen wrote:
> On Mon, Oct 15, 2018 at 4:21 AM brian m. carlson
> wrote:
> >
> > The transition plan anticipates us using a syntax such as "^{sha1}" for
> > disambiguation. Since this is a syntax some people will be typing a
> > lot, it makes sense
On Wed, Oct 17, 2018 at 08:21:42AM -0400, Derrick Stolee wrote:
> On 10/14/2018 10:19 PM, brian m. carlson wrote:
> > Since the commit-graph code wants to serialize the hash algorithm into
> > the data store, specify a version number for each supported algorithm.
> > Note that we don't use the
Signed-off-by: Ramsay Jones
---
Hi Junio,
Since I didn't get any adverse comments, this version has the RFC
label removed. Also, given that it seems the vcs-svn directory is
not going away soon, I have included those headers this time as well.
[Note: my email client (thunderbird) was updated
> When constructing a struct repository for a submodule for some revision
> of the superproject where the submodule is not contained in the index,
> it may not be present in the working tree currently either. In that
> siutation giving a 'path' argument is not useful. Upgrade the
>
> By doing so we'll have access to the util pointer for longer that
> contains the commits that we need to fetch, which will be
> useful in a later patch.
It seems that the main point of this patch is so that the OIDs be stored
in changed_submodule_names, because you need them in a later patch.
> The `changed_submodule_names` are only used for fetching, so let's make it
> part of the struct that is passed around for fetching submodules.
Keep the titles of commit messages to 50 characters or under.
> +static void calculate_changed_submodule_paths(
> + struct submodule_parallel_fetch
> We can string_list_insert() to maintain sorted-ness of the
> list as we find new items, or we can string_list_append() to
> build an unsorted list and sort it at the end just once.
This confused me at first, because neither function is mentioned in the
patch.
> As we do not rely on the
> No changes are needed in mirrored repository. Crash happens both with
> 2.18.0 and 2.19.1 git versions. Having repository locally is not
> required but reduces test runtime, you can quite reliably reproduce
> issue when fetching over net directly from chromium.orgbypassing
> mirroring step.
Do
From: Derrick Stolee
The config setting "core.commitGraph" enables using the commit-graph
file to accelerate commit walks through parsing speed and generation
numbers. The setting "gc.writeCommitGraph" enables writing the
commit-graph file on every non-trivial 'git gc' operation. Together,
they
From: Derrick Stolee
The test script t6501-freshen-objects.sh has some tests that care
if 'git gc' has any output to stderr. This is intended to say that
no warnings occurred related to broken links. However, when we
have operations that output progress (like writing the commit-graph)
this
The commit-graph feature is starting to stabilize. Based on what is in
master right now, we have:
Git 2.18:
* Ability to write commit-graph (requires user interaction).
* Commit parsing is faster when commit-graph exists.
* Must have core.commitGraph true to use.
Git
From: Derrick Stolee
There are a few tests that already require GIT_TEST_COMMIT_GRAPH=0
as they rely on an interaction with the commits in the object store
that is circumvented by parsing commit information from the
commit-graph instead. Before enabling core.commitGraph as true by
default,
On Wed, Oct 17, 2018 at 02:21:57PM -0500, Robert Dailey wrote:
> On Wed, Oct 17, 2018 at 1:47 PM Jeff King wrote:
> > Hmm, I feel like another person asked for this recently, but I can't
> > seem to find the thread.
>
> Is it this one?
>
On Wed, Oct 17, 2018 at 1:47 PM Jeff King wrote:
> Hmm, I feel like another person asked for this recently, but I can't
> seem to find the thread.
Is it this one?
https://www.mail-archive.com/git@vger.kernel.org/msg159212.html
That's the only one I was able to find, but no one replied. Thanks
On Wed, Oct 17, 2018 at 01:15:18PM -0500, Robert Dailey wrote:
> I'd like to sort the output of `git diff --stat` such that files are
> listed in descending order based on number of lines changed. The
> closest solution I've found online[1] has several readability issues.
> I'd rather see a
On Wed, Oct 17, 2018 at 11:00:03AM -0700, Elijah Newren wrote:
> Digging in, almost all the time was CPU-bound and spent in
> add_missing_tags()[2]. If I'm reading the code correctly, it appears
> that function loops over each tag, calling in_merge_bases_many() once
> per tag. Thus, for his
On Wed, Oct 17, 2018 at 02:19:59PM -0400, Eric Sunshine wrote:
> On Wed, Oct 17, 2018 at 12:40 PM Ben Peart wrote:
> > Add a reset.quietDefault config setting that sets the default value of the
> > --quiet flag when running the reset command. This enables users to change
> > the default
On Wed, Oct 17, 2018 at 02:14:32PM -0400, Eric Sunshine wrote:
> > diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
> > @@ -95,7 +95,9 @@ OPTIONS
> > --quiet::
> > - Be quiet, only report errors.
> > + Be quiet, only report errors. Can optimize the performance
On Wed, Oct 17, 2018 at 12:40 PM Ben Peart wrote:
> Add a reset.quietDefault config setting that sets the default value of the
> --quiet flag when running the reset command. This enables users to change
> the default behavior to take advantage of the performance advantages of
> avoiding the scan
On 10/17/2018 2:00 PM, Elijah Newren wrote:
Hi,
Just wanted to give a shout-out for the commit-graph work and how
impressive it is. I had an internal report from a user that git
pushes containing only one new tiny commit were taking over a minute
(in a moderate size repo with good network
I'd like to sort the output of `git diff --stat` such that files are
listed in descending order based on number of lines changed. The
closest solution I've found online[1] has several readability issues.
I'd rather see a built-in solution in git, if one exists. Can anyone
recommend a solution?
On Wed, Oct 17, 2018 at 12:40 PM Ben Peart wrote:
> When git reset is run with the --quiet flag, don't bother finding any
> additional unstaged changes as they won't be output anyway. This speeds up
> the git reset command by avoiding having to lstat() every file looking for
> changes that
On Wed, Oct 17, 2018 at 03:53:41PM +0200, Andreas Gruenbacher wrote:
> On Wed, 17 Oct 2018 at 11:12, Jeff King wrote:
> > On Tue, Oct 16, 2018 at 11:24:38PM +0200, Andreas Gruenbacher wrote:
> > > here's a long-overdue update of my proposal from August 29:
> > >
> > > [RFC] revision: Don't let
On Wed, Oct 17, 2018 at 06:24:05AM -0700, Matthew DeVore wrote:
> > Yuck, t4202 is a mix of older and newer styles. I'm OK with this as-is
> > because you've matched the surrounding code, but these days I'd probably
> > write:
> >
> > test_expect_success '--sticky-default ^' '
> > {
> >
Hi,
Just wanted to give a shout-out for the commit-graph work and how
impressive it is. I had an internal report from a user that git
pushes containing only one new tiny commit were taking over a minute
(in a moderate size repo with good network connectivity). After
digging for a while, I
On Wed, Oct 17, 2018 at 5:41 AM Derrick Stolee wrote:
>
> On 10/16/2018 7:35 PM, Stefan Beller wrote:
> >
> > This series takes another approach as it doesn't change the signature
> > of
> > functions, but introduces new functions that can deal with arbitrary
> > repositories,
On 10/17/18 11:39 AM, Rafael Ascensão wrote:
> On Fri, Oct 12, 2018 at 03:33:21PM +0200, Daniels Umanovskis wrote:
>> Intended both for scripting and interactive/informative use.
>> Unlike git branch --list, no filtering is needed to just get the
>> branch name.
>
> Are we going forward with
From: Ben Peart
When git reset is run with the --quiet flag, don't bother finding any
additional unstaged changes as they won't be output anyway. This speeds up
the git reset command by avoiding having to lstat() every file looking for
changes that aren't going to be reported anyway.
The
From: Ben Peart
The reset (mixed) command unstages the specified file(s) and then shows you
the remaining unstaged changes. This can make the command slow on larger
repos because at the end it calls refresh_index() which has a single thread
that loops through all the entries calling lstat() for
From: Ben Peart
Add a reset.quietDefault config setting that sets the default value of the
--quiet flag when running the reset command. This enables users to change
the default behavior to take advantage of the performance advantages of
avoiding the scan for unstaged changes after reset.
We provide photoshop services to some of the companies from around the
world.
Some online stores use our services for retouching portraits, jewelry,
apparels, furnitures etc.
Here are the details of what we provide:
Clipping path for photos
Deep etching for photos
Image masking for photos
We provide photoshop services to some of the companies from around the
world.
Some online stores use our services for retouching portraits, jewelry,
apparels, furnitures etc.
Here are the details of what we provide:
Clipping path for photos
Deep etching for photos
Image masking for photos
On Mon, Oct 15, 2018 at 02:18:57AM +, brian m. carlson wrote:
> diff --git a/sha256/block/sha256.c b/sha256/block/sha256.c
> new file mode 100644
> index 00..18350c161a
> --- /dev/null
> +++ b/sha256/block/sha256.c
> @@ -0,0 +1,180 @@
> +#include "git-compat-util.h"
> +#include
Hi Gábor,
On Tue, 16 Oct 2018, SZEDER Gábor wrote:
> On Mon, Oct 15, 2018 at 03:12:06AM -0700, Johannes Schindelin via
> GitGitGadget wrote:
> > diff --git a/azure-pipelines.yml b/azure-pipelines.yml
> > new file mode 100644
> > index 00..b5749121d2
> > --- /dev/null
> > +++
Hello, Junio, Jeff.
A while ago, I proposed changes to name-rev and describe so that they
can identify the commits cherry-picked from the one which is being
shown.
https://public-inbox.org/git/20180726153714.gx1934...@devbig577.frc2.facebook.com/T/
While the use-cases - e.g. tracking down
On Wed, Oct 17, 2018 at 12:44 AM brian m. carlson
wrote:
> > > >> static uint8_t oid_version(void)
> > > >> {
> > > >> - return 1;
> > > >> + switch (hash_algo_by_ptr(the_hash_algo)) {
> > > >> + case GIT_HASH_SHA1:
> > > >> + return 1;
> > > >>
On Tue, Oct 16, 2018 at 03:40:01PM -0700, Jonathan Nieder wrote:
> SZEDER Gábor wrote:
> > On Tue, Oct 16, 2018 at 02:54:56PM -0700, Jonathan Nieder wrote:
> >> SZEDER Gábor wrote:
>
> >>> Our Makefile has lines like these:
> >>>
> >>> CFLAGS = -g -O2 -Wall
> >>> CC = cc
> >>> AR = ar
> >>>
Dear,i am lisa jaster,it would be great to know you,i have a very
important and confidential matter that i want to discuss with
you,reply me back for more discus.
Regards,
Lisa Jaster.
On Wed, 17 Oct 2018 at 11:12, Jeff King wrote:
> On Tue, Oct 16, 2018 at 11:24:38PM +0200, Andreas Gruenbacher wrote:
> > here's a long-overdue update of my proposal from August 29:
> >
> > [RFC] revision: Don't let ^ cancel out the default
> >
> > Does this look more acceptable that my first
Some commands like 'log' default to HEAD if no other revisions are
specified on the command line or otherwise. Currently, excludes
(^) cancel out that default, so when a command only excludes
revisions (e.g., 'git log ^origin/master'), it will produce no output.
With the --sticky-default option,
In an effort to ensure new code is reasonably covered by the test suite,
we now have contrib/coverage-diff.sh to combine the gcov output from
'make coverage-test ; make coverage-report' with the output from 'git
diff A B' to discover _new_lines of code that are not covered. This
report ignores
On Mon, Oct 15, 2018 at 02:18:49AM +, brian m. carlson wrote:
> There are several ways we might refer to a hash algorithm: by name, such
> as in the config file; by format ID, such as in a pack; or internally,
> by a pointer to the hash_algos array. Provide functions to look up hash
>
On Wed, 17 Oct 2018, Jeff King wrote:
Yuck, t4202 is a mix of older and newer styles. I'm OK with this as-is
because you've matched the surrounding code, but these days I'd probably
write:
test_expect_success '--sticky-default ^' '
{
echo sixth
echo
On 10/17/2018 9:00 AM, Derrick Stolee via GitGitGadget wrote:
[1] https://git.visualstudio.com/git/_build?definitionId=4
Newlines are hard. Sorry for the formatting issues when translating from
a PR description.
Build definition
that tests Git with different arrangements of GIT_TEST_*
On 10/17/2018 5:25 AM, Jeff King wrote:
Before we switched to one big test-tool binary, if you
forgot the name of a tool, you could use tab-completion in
the shell to get a hint. But these days, all you get is:
$ t/helper/test-tool approxidate
fatal: There is no test named 'approxidate'
Our CI scripts include a step to run the test suite with certain optional
variables enabled. Now that all branches should build and have tests succeed
with GIT_TEST_COMMIT_GRAPH and GIT_TEST_MULTI_PACK_INDEX enabled, add those
variables to that stage.
Note: the GIT_TEST_MULTI_PACK_INDEX variable
From: Derrick Stolee
The commit-graph and multi-pack-index features introduce optional
data structures that are not required for normal Git operations.
It is important to run the normal test suite without them enabled,
but it is helpful to also run the test suite using them.
Our continuous
> > branch_get sometimes returns current_branch, which can be NULL (e.g., if
> > you're on a detached HEAD). Try:
> >
> > $ git branch HEAD
> > fatal: no such branch 'HEAD'
> >
> > $ git branch ''
> > fatal: no such branch ''
> >
> > However, it seems weird that we'd check those cases
On 10/16/2018 7:35 PM, Stefan Beller wrote:
This series takes another approach as it doesn't change the signature of
functions, but introduces new functions that can deal with arbitrary
repositories, keeping the old function signature around using a shallow
wrapper.
On 10/14/2018 10:19 PM, brian m. carlson wrote:
Since the commit-graph code wants to serialize the hash algorithm into
the data store, specify a version number for each supported algorithm.
Note that we don't use the values of the constants themselves, as they
are internal and could change in
Hello,
I can confirm that shallow clones are no longer failing.
--
Arturas Moskvinas
On Wed, Oct 17, 2018 at 12:58 AM Jonathan Tan wrote:
>
> Suppose a server has the following commit graph:
>
> A B
> \ /
>O
>
> We create a client by cloning A from the server with depth 1, and add
>
On Wed, Oct 17, 2018 at 6:18 AM Johannes Schindelin
wrote:
> I realized yesterday that the &&-chain linting we use for every single
> test case takes a noticeable chunk of time:
>
> $ time ./t0006-date.sh --quiet
> real0m20.973s
> $ time ./t0006-date.sh --quiet
Hi Eric,
On Tue, 16 Oct 2018, Eric Sunshine wrote:
> On Tue, Oct 16, 2018 at 7:09 PM Junio C Hamano wrote:
> > Eric Sunshine writes:
> > > This cleanup "checkout" needs to be encapsulated within a
> > > test_when_finished(), doesn't it? Preferably just after the "git
> > > checkout -b"
On Tue, Oct 16, 2018 at 02:02:52PM -0700, Johannes Schindelin via GitGitGadget
wrote:
> From: Johannes Schindelin
>
> In 9ac3f0e5b3e4 (pack-objects: fix performance issues on packing large
> deltas, 2018-07-22), a mutex was introduced that is used to guard the
> call to set the delta size.
On Fri, Oct 12, 2018 at 03:33:21PM +0200, Daniels Umanovskis wrote:
> Intended both for scripting and interactive/informative use.
> Unlike git branch --list, no filtering is needed to just get the
> branch name.
Are we going forward with advertising this as a scriptable alternative?
> + }
Before we switched to one big test-tool binary, if you
forgot the name of a tool, you could use tab-completion in
the shell to get a hint. But these days, all you get is:
$ t/helper/test-tool approxidate
fatal: There is no test named 'approxidate'
and you're stuck reading the source code to
On Tue, Oct 16, 2018 at 11:24:38PM +0200, Andreas Gruenbacher wrote:
> here's a long-overdue update of my proposal from August 29:
>
> [RFC] revision: Don't let ^ cancel out the default
>
> Does this look more acceptable that my first shot?
I think it's going in the right direction.
The
On Wed, Oct 17, 2018 at 11:58:15AM +0800, 牛旭 wrote:
> Our team works on enhance logging practices by learning from historical log
> revisions in evolution.
> And we find three patches that update error(..., strerror(errmp)) to
> error_errno(...).
>
> While applying this rule to git-2.14.2, we
On Tue, Oct 16, 2018 at 10:54:28PM +0800, Tao Qingyun wrote:
> branch_get sometimes returns current_branch, which can be NULL (e.g., if
> you're on a detached HEAD). Try:
>
> $ git branch HEAD
> fatal: no such branch 'HEAD'
>
> $ git branch ''
> fatal: no such branch ''
>
> However, it
On Sun, Oct 14, 2018 at 04:29:06PM +0200, René Scharfe wrote:
> Anyway, drove the generative approach a bit further, and came up with
> the new DEFINE_SORT below. I'm unsure about the name; perhaps it should
> be called DEFINE_SORT_BY_COMPARE_FUNCTION_BODY, but that's a bit long.
> It handles
Hi,
Our team works on enhance logging practices by learning from historical log
revisions in evolution.
And we find 2 patches that add strerror() to the log statement which is printed
when the return value of commit_lock_file() is smaller than 0.
While applying this rule to git-2.14.2, we find
On Mon, Oct 15, 2018 at 09:31:54PM +0200, Jacques Bodin-Hullin wrote:
> I've just updated the PR with the `error(` change.
>
> Also I did the change for the question mark at the end, because you are
> right, when we read it, it sounds better.
>
> Do I need to put back the patch in this thread?
86 matches
Mail list logo
