On Fri, Jul 20, 2018 at 10:43:25AM -0700, Elijah Newren wrote:
> > This patch provides a better fallback that is
> >
> > - cheaper in terms of cpu and io because we won't have to read
> > existing pack files as much
> >
> > - better in terms of pack size because the pack heuristics is back to
>
On Fri, Jul 20, 2018 at 7:40 PM Jeff King wrote:
>
> On Fri, Jul 20, 2018 at 05:39:43PM +0200, Nguyễn Thái Ngọc Duy wrote:
>
> > Let's start with some background about oe_delta_size() and
> > oe_set_delta_size(). If you already know, skip the next paragraph.
> >
> > These two are added in
On Sat, Jul 21, 2018 at 1:52 AM Elijah Newren wrote:
>
> On Fri, Jul 20, 2018 at 10:43 AM, Elijah Newren wrote:
> > On Fri, Jul 20, 2018 at 8:39 AM, Nguyễn Thái Ngọc Duy
> > wrote:
>
> >> This patch provides a better fallback that is
> >>
> >> - cheaper in terms of cpu and io because we won't
Hi,
brian m. carlson wrote:
> I know this discussion has sort of petered out, but I'd like to see if
> we can revive it. I'm writing index v3 and having a decision would help
> me write tests for it.
Nice! That's awesome.
> To summarize the discussion that's been had in addition to the
On Fri, Jul 20, 2018 at 10:43 AM, Elijah Newren wrote:
> On Fri, Jul 20, 2018 at 8:39 AM, Nguyễn Thái Ngọc Duy
> wrote:
>> This patch provides a better fallback that is
>>
>> - cheaper in terms of cpu and io because we won't have to read
>> existing pack files as much
>>
>> - better in terms
On Sat, Jul 21, 2018 at 12:23 AM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> Signed-off-by: Stefan Beller
>> ---
>>
>> Maybe we rather want to refer to the options that are described further
>> down in the document?
>
> I have no strong preference either way.
>
> The patch looks
"brian m. carlson" writes:
> Both AsciiDoc 8.6.10 and Asciidoctor support SOURCE_DATE_EPOCH for
> reproducible builds[0], which should reduce the date noise. We could
> also add a Makefile knob to set git_version to an empty string or an
> --abbrev=0 equivalent for such a situation.
>
> [0]
On Fri, Jul 20, 2018 at 3:05 PM, Junio C Hamano wrote:
> Elijah Newren writes:
>
>> Ah, okay, that's helpful. So, if there are conflicts, it should be
>> free to clear the skip_worktree flag. Since merge-recursive calls
>> add_cacheinfo() for all entries it needs to update, which deletes the
Derrick Stolee writes:
> There are many places in Git that use a commit walk to determine
> reachability between commits and/or refs. A lot of this logic is
> duplicated.
>
> I wanted to achieve the following:
>
> Consolidate several different commit walks into one file
> Reduce duplicate
On Wed, Jul 18, 2018 at 01:49:44PM -0400, Jeff King wrote:
> On Wed, Jul 18, 2018 at 07:37:48PM +0200, Andrei Rybak wrote:
> > diff --git a/Documentation/git-for-each-ref.txt
> > b/Documentation/git-for-each-ref.txt
> > index 085d177d97..901faef1bf 100644
> > ---
"brian m. carlson" writes:
> On Fri, Jul 20, 2018 at 11:22:03AM -0700, Junio C Hamano wrote:
>> Derrick Stolee writes:
>>
>> > diff --git a/Documentation/git-multi-pack-index.txt
>> > b/Documentation/git-multi-pack-index.txt
>> > new file mode 100644
>> > index 00..ec9982cbfc
>> > ---
Stefan Beller writes:
> Signed-off-by: Stefan Beller
> ---
>
> Maybe we rather want to refer to the options that are described further
> down in the document?
I have no strong preference either way.
The patch looks reasonable to me; Christian?
>
> Documentation/git-interpret-trailers.txt |
Hi Derrick,
> Sure! It's on my fork [1]
>
> [1] https://github.com/derrickstolee/git/tree/reach/refactor
>
Thanks!
> >> * Use single rev-parse commands in test output, and pipe the OIDs through
> >> 'sort'
Why do we need to sort them? The order of the answers given by rev-parse
is the same as
On Fri, Jul 20, 2018 at 11:22:03AM -0700, Junio C Hamano wrote:
> Derrick Stolee writes:
>
> > diff --git a/Documentation/git-multi-pack-index.txt
> > b/Documentation/git-multi-pack-index.txt
> > new file mode 100644
> > index 00..ec9982cbfc
> > --- /dev/null
> > +++
On Fri, Jul 20, 2018 at 05:51:46PM -0400, Jeffrey Walton wrote:
> Sorry about the late reply. I meant to reply this morning.
>
> My shell script to patch things on Solaris was the cause of the problem.
Glad to hear you got it figured out.
> (If anyone is interested in first class Solaris
Teach clone to send a list of ref-prefixes, when using protocol v2, to
allow the server to filter out irrelevant references from the
ref-advertisement. This reduces wasted time and bandwidth when cloning
repositories with a larger number of references.
Signed-off-by: Brandon Williams
---
Elijah Newren writes:
> Ah, okay, that's helpful. So, if there are conflicts, it should be
> free to clear the skip_worktree flag. Since merge-recursive calls
> add_cacheinfo() for all entries it needs to update, which deletes the
> old cache entry and just makes new ones, we get that for
Signed-off-by: Stefan Beller
---
Maybe we rather want to refer to the options that are described further
down in the document?
Documentation/git-interpret-trailers.txt | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-interpret-trailers.txt
On Mon, Jun 11, 2018 at 12:29:42PM -0700, Jonathan Nieder wrote:
> My understanding of the discussion so far:
>
> Keccak team encourages us[1] to consider a variant like K12 instead of
> SHA3.
>
> AGL explains[2] that the algorithms considered all seem like
> reasonable choices and we should
On Fri, Jul 20, 2018 at 5:04 PM, brian m. carlson
wrote:
> On Thu, Jul 19, 2018 at 09:37:08PM -0400, Jeffrey Walton wrote:
>> Hi Everyone,
>>
>> I'm working from the 2.18 tarball on Solaris 11.3 x86_64. I'm catching
>> the following when building from sources. This appears to be a new
>> issue.
Jeff King writes:
> I suspect it has more to do with system/libc differences between our
> machines, anyway. There was discussion elsewhere in the thread about the
> need to #undef before redefining. I guess this answers that question.
Yes, that is it. For now I can squash this in before
On Fri, Jul 20, 2018 at 2:13 PM, Junio C Hamano wrote:
> Elijah Newren writes:
>
>> But that brings up another interesting question. What if a merge
>> *does* modify a file for which you have skip-worktree set?
>> Previously, it'd clear the bit and write the file to the working tree,
>> but
Basin Ilya writes:
> Hi.
>
> I'm trying to make the Cygwin Git understand Mingw-style repo urls:
>
> git config --global \
> file:///cygdrive/c.insteadOf \
> file:///C:
>
> But this fails with:
>
> error: invalid key: file:///cygdrive/c.insteadOf
Understandable.
> Manually
+cc list
On Fri, Jul 20, 2018 at 2:29 PM Junio C Hamano wrote:
> ... which means that it does not matter if I have an elaborate rewrite hook
> that constantly updates the reverse mapping or if the reverse mapping is
> made immediately before I push out. You wouldn't even be able to tell any
>
Hi.
I'm trying to make the Cygwin Git understand Mingw-style repo urls:
git config --global \
file:///cygdrive/c.insteadOf \
file:///C:
But this fails with:
error: invalid key: file:///cygdrive/c.insteadOf
Manually editing ~/.gitconfig works fine:
[url
On Thu, Jul 19, 2018 at 09:37:08PM -0400, Jeffrey Walton wrote:
> I'm working from the 2.18 tarball on Solaris 11.3 x86_64. I'm catching
> the following when building from sources. This appears to be a new
> issue. It was not present in 2.17.1.
>
> gmake: *** No rule to make target
Stefan Beller writes:
> On Fri, Jul 20, 2018 at 12:35 PM Junio C Hamano wrote:
>
>> It is not like anybody (including me) needs realtime up-to-date
>
> I thought the same for a long time, but contributing to other projects
> showed me that this is not necessarily the case. Having a real time
>
On Fri, Jul 20, 2018 at 12:35 PM Junio C Hamano wrote:
> It is not like anybody (including me) needs realtime up-to-date
I thought the same for a long time, but contributing to other projects
showed me that this is not necessarily the case. Having a real time
update, even if it would be just
Elijah Newren writes:
> But that brings up another interesting question. What if a merge
> *does* modify a file for which you have skip-worktree set?
> Previously, it'd clear the bit and write the file to the working tree,
> but that was by no means an explicit decision;
At least in my mind,
On Thu, Jul 19, 2018 at 09:37:08PM -0400, Jeffrey Walton wrote:
> Hi Everyone,
>
> I'm working from the 2.18 tarball on Solaris 11.3 x86_64. I'm catching
> the following when building from sources. This appears to be a new
> issue. It was not present in 2.17.1.
>
> gmake: *** No rule to make
Hi,
We provide image editing services like - photo cut out; photo clipping
path; photo masking; photo
shadow creation; photo color correction; photo retouching; beauty model
retouching on skin, face,
body; glamour retouching; products retouching and other image editing.
We are also offering to
On Fri, Jul 20, 2018 at 12:53 PM, Ben Peart wrote:
> As we were attempting to migrate to 2.18 some of our internal functional
> tests failed. The tests that failed were testing merge and cherry-pick when
> there was a merge conflict. Our tests run with sparse-checkout enabled which
> is what
seq 1 100 >one
echo 99 > two
seq 1 2 98 >>two
git diff --no-index --histogram one two
In addition to the recent patches[1], I found another bug in the
histogram algorithm,
which can be produced with the instructions given above. At least I
think it is a bug as
the diff looks terrible to
Hi,
Brandon Williams wrote:
> Signed-off-by: Brandon Williams
> ---
> Noticed we miss out on server side filtering of refs when cloning using
> protocol v2, this will enable that.
>
> builtin/clone.c | 22 +-
> 1 file changed, 17 insertions(+), 5 deletions(-)
Nice! The
As we were attempting to migrate to 2.18 some of our internal functional
tests failed. The tests that failed were testing merge and cherry-pick
when there was a merge conflict. Our tests run with sparse-checkout
enabled which is what exposed the bug.
What is happening is that in
Brandon Williams writes:
Is there an end-user visible effect, caused by the lack of "prefix"
being fixed with this patch, that is worth describing here? "The
server ended up showing refs that are irrelevant to the normal clone
request which is only for heads and tags, wasting time and
Johannes Schindelin writes:
> AFAICT there is at least one scenario where you run `rebase -i`, the notes
> get updated, and of course the *reverse mapping* does *not* get updated:
It turns out that I never had a rewrite hook; the notes.rewriteref
mechanism is the only thing that has been used
On Fri, Jul 20, 2018 at 02:30:23AM -0700, Junio C Hamano wrote:
> > The entries in shallow file says that history behind them may not
> > exist in the repository due to its shallowness but history after
> > them are supposed to be traversable (otherwise we have a repository
> > corruption). It
Signed-off-by: Brandon Williams
---
Noticed we miss out on server side filtering of refs when cloning using
protocol v2, this will enable that.
builtin/clone.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/builtin/clone.c b/builtin/clone.c
index
On Fri, Jul 20, 2018 at 11:58:10AM -0700, Junio C Hamano wrote:
> > Note that this needs to be applied on top of 022d2ac1f3 (blame: prefer
> > xsnprintf to strcpy for colors, 2018-07-13) or it will complain loudly. :)
> >
> > [1/2]: introduce "banned function" list
> > [2/2]: banned.h: mark
> 1. To roll again.
>
> A player who rolls two sixes can reroll the dice for an additional
> turn.
This is where I had my AHA moment!
(Consider my software development process as chaotic as a dice roll
So rerolling is really just rolling the dice again to "get my patch
On 7/20/2018 2:09 PM, Eric Sunshine wrote:
On Fri, Jul 20, 2018 at 1:20 PM Derrick Stolee wrote:
Here is the diff between v1 and v2.
diff --git a/t/t6600-test-reach.sh b/t/t6600-test-reach.sh
@@ -67,142 +67,176 @@ test_three_modes () {
test_expect_success 'get_merge_bases_many' '
On 7/20/2018 1:41 PM, Duy Nguyen wrote:
On Fri, Jul 20, 2018 at 6:35 PM Derrick Stolee wrote:
There are many places in Git that use a commit walk to determine
reachability between commits and/or refs. A lot of this logic is
duplicated.
I wanted to achieve the following:
Consolidate several
On Thu, Jul 19, 2018 at 3:26 PM, SZEDER Gábor wrote:
> The five new tests added to 't9300-fast-import.sh' in 30e215a65c
> (fast-import: checkpoint: dump branches/tags/marks even if
> object_count==0, 2017-09-28), all with the prefix "V:" in their test
> description, run 'git fast-import' in the
Jeff King writes:
> Thanks for an interesting (and exotic) counter-point. For strcpy(), you
> always have to run strlen() anyway to know you're not going to overflow,
> so you might as well memcpy() at that point. But if you really are OK
> with truncation, then using strncpy() lets you copy
Hi Stefan,
On Tue, 17 Jul 2018, Stefan Beller wrote:
> > > It's nice to see that the bulk of the range-diff functionality has
> > > been libified in this re-roll (residing in range-diff.c rather than
> >
> > Can we *please* stop calling it "re-roll"? Thanks.
>
> Fun fact of the day:
>
> First
Jeff King writes:
> This is a patch series to address the discussion in the thread at:
>
> https://public-inbox.org/git/20180713204350.ga16...@sigill.intra.peff.net/
>
> Basically, the question was: can we declare strcpy banned and have a
> linter save us the trouble of finding it in review.
Hi Junio,
On Thu, 19 Jul 2018, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Johannes Schindelin writes:
> >
> >> I would like to ask you to reinstate the post-rewrite hook, as it still
> >> improves the situation over the current one.
> >
> > Without post-rewrite I seem to be getting
Derrick Stolee writes:
> diff --git a/Documentation/git-multi-pack-index.txt
> b/Documentation/git-multi-pack-index.txt
> new file mode 100644
> index 00..ec9982cbfc
> --- /dev/null
> +++ b/Documentation/git-multi-pack-index.txt
> @@ -0,0 +1,36 @@
> +git-multi-pack-index(1)
>
On Fri, Jul 20, 2018 at 1:20 PM Derrick Stolee wrote:
> Here is the diff between v1 and v2.
>
> diff --git a/t/t6600-test-reach.sh b/t/t6600-test-reach.sh
> @@ -67,142 +67,176 @@ test_three_modes () {
> test_expect_success 'get_merge_bases_many' '
> cat >input <<-\EOF &&
> +
On Fri, Jul 20, 2018 at 10:48:37AM -0700, Elijah Newren wrote:
> > Is it possible to extend this to ban variables as well? I'm still
> > going to delete the_index from library code. Once that work is done I
>
> Or perhaps constants, such as PATH_MAX to avoid problems like this one
> from 2.18.0
On Fri, Jul 20, 2018 at 04:41:34PM +0200, Duy Nguyen wrote:
> > Let's start by banning strcpy() and sprintf(). It's not
> > impossible to use these correctly, but it's easy to do so
> > incorrectly, and there's always a better option.
>
> Is it possible to extend this to ban variables as well?
On Fri, Jul 20, 2018 at 09:22:41AM -0400, Theodore Y. Ts'o wrote:
> On Thu, Jul 19, 2018 at 09:08:08PM -0400, Jeff King wrote:
> > Ditto for sprintf, where you should _always_ be using at least xsnprintf
> > (or some better tool, depending on the situation). And for strncpy,
> > strlcpy (or
Hi Junio,
Le 19/07/2018 à 00:03, Junio C Hamano a écrit :
> * ag/rebase-i-in-c (2018-07-10) 13 commits
> - rebase -i: rewrite the rest of init_revisions_and_shortrevisions in C
> - rebase -i: implement the logic to initialize the variable $revision in C
> - rebase--interactive: remove unused
On Fri, Jul 20, 2018 at 7:41 AM, Duy Nguyen wrote:
> On Thu, Jul 19, 2018 at 10:40 PM Jeff King wrote:
>>
>> There are a few standard C functions (like strcpy) which are
>> easy to misuse. We generally discourage these in reviews,
>> but we haven't put advice in CodingGuidelines, nor provided
>>
On Fri, Jul 20, 2018 at 02:32:29AM -0700, Junio C Hamano wrote:
> > Contrast this with memcpy(). This is on Microsoft's SDL banned list[1],
> > but I think it's silly for it to be. I would never add it to this list.
>
> A tangent, but is that because they want you to use memmove()
> instead so
On Fri, Jul 20, 2018 at 8:39 AM, Nguyễn Thái Ngọc Duy wrote:
> Let's start with some background about oe_delta_size() and
> oe_set_delta_size(). If you already know, skip the next paragraph.
>
> These two are added in 0aca34e826 (pack-objects: shrink delta_size
> field in struct object_entry -
On Fri, Jul 20, 2018 at 6:35 PM Derrick Stolee wrote:
>
> There are many places in Git that use a commit walk to determine
> reachability between commits and/or refs. A lot of this logic is
> duplicated.
>
> I wanted to achieve the following:
>
> Consolidate several different commit walks into
On Fri, Jul 20, 2018 at 05:39:43PM +0200, Nguyễn Thái Ngọc Duy wrote:
> Let's start with some background about oe_delta_size() and
> oe_set_delta_size(). If you already know, skip the next paragraph.
>
> These two are added in 0aca34e826 (pack-objects: shrink delta_size
> field in struct
On Thu, Jul 19, 2018 at 10:28 PM, Jeff King wrote:
> On Thu, Jul 19, 2018 at 04:11:01PM -0700, Elijah Newren wrote:
>
>> Looking at the output from Peff's instrumentation elsewhere in this
>> thread, I see a lot of lines like
>>mismatched get: 32889efd307c7be376da9e3d45a78305f14ba73a = (, 28)
Here is the diff between v1 and v2.
Thanks,
-Stolee
---
diff --git a/bisect.c b/bisect.c
index e1275ba79e..d023543c91 100644
--- a/bisect.c
+++ b/bisect.c
@@ -13,6 +13,7 @@
#include "sha1-array.h"
#include "argv-array.h"
#include "commit-slab.h"
+#include "commit-reach.h"
static struct
On 7/20/2018 1:10 PM, Stefan Beller wrote:
Hi Derrick,
V2 Update: The biggest material change in this version is that we drop the
method declarations from commit.h, which requires adding a lot of references
to commit-reach.h across the codebase. This change is in a commit on its own.
In
Hi Derrick,
> V2 Update: The biggest material change in this version is that we drop the
> method declarations from commit.h, which requires adding a lot of references
> to commit-reach.h across the codebase. This change is in a commit on its own.
> In addition, we have the following smaller
On 7/20/2018 12:49 PM, Stefan Beller wrote:
Thanks, Peff, for improving the check_replace_refs interaction [1].
Since this series now has two dependencies (including Stefan's ref-store
fix [2] that I had included in my v1), I'll let those topics settle
before I send a new v2.
FYI: I have not
> Thanks, Peff, for improving the check_replace_refs interaction [1].
>
> Since this series now has two dependencies (including Stefan's ref-store
> fix [2] that I had included in my v1), I'll let those topics settle
> before I send a new v2.
FYI: I have not been working on, nor plan to work on
On 7/18/2018 3:52 PM, Derrick Stolee wrote:
On 7/18/2018 3:46 PM, Jeff King wrote:
On Wed, Jul 18, 2018 at 08:15:41AM -0700, Derrick Stolee via
GitGitGadget wrote:
From: Derrick Stolee
Create new method commit_graph_compatible(r) to check if a given
repository r is compatible with the
Signed-off-by: Derrick Stolee
---
t/helper/test-reach.c | 4
t/t6600-test-reach.sh | 22 ++
2 files changed, 26 insertions(+)
diff --git a/t/helper/test-reach.c b/t/helper/test-reach.c
index 4df01187c9..e32e193b70 100644
--- a/t/helper/test-reach.c
+++
Signed-off-by: Derrick Stolee
---
t/helper/test-reach.c | 6 ++
t/t6600-test-reach.sh | 18 ++
2 files changed, 24 insertions(+)
diff --git a/t/helper/test-reach.c b/t/helper/test-reach.c
index 620bb46041..f93ad5084d 100644
--- a/t/helper/test-reach.c
+++
The can_all_from_reach_with_flags method is used by ok_to_give_up in
upload-pack.c to see if we have done enough negotiation during a fetch.
This method is intentionally created to preserve state between calls to
assist with stateful negotiation, such as over SSH.
To make this method testable,
The get_merge_bases_many method returns a list of merge bases for a
single commit (A) against a list of commits (X). Some care is needed in
constructing the expected behavior because the result is not the
expected merge-base for an octopus merge with those parents but instead
the set of maximal
The can_all_from_reach_with_flags() algorithm is currently quadratic in
the worst case, because it calls the reachable() method for every 'from'
without tracking which commits have already been walked or which can
already reach a commit in 'to'.
Rewrite the algorithm to walk each commit a
The is_descendant_of method previously used in_merge_bases() to check if
the commit can reach any of the commits in the provided list. This had
two performance problems:
1. The performance is quadratic in worst-case.
2. A single in_merge_bases() call requires walking beyond the target
commit
There are many places in Git that use a commit walk to determine
reachability between commits and/or refs. A lot of this logic is
duplicated.
I wanted to achieve the following:
Consolidate several different commit walks into one file
Reduce duplicate reachability logic
Increase testability
There are several commit walks in the codebase. Group them together into
a new commit-reach.c file and corresponding header. After we group these
walks into one place, we can reduce duplicate logic by calling
equivalent methods.
The method declarations in commit.h are not touched by this commit
The is_descendant_of method takes a single commit as its first parameter
and a list of commits as its second parameter. Extend the input of the
'test-tool reach' command to take multiple lines of the form
"X:" to construct a list of commits. Pass these to
is_descendant_of and create tests that
The ref_newer method is used by 'git push' to check if a force-push is
required. This method does not use any kind of cutoff when walking, so
in the case of a force-push will walk all reachable commits.
The is_descendant_of method already uses paint_down_to_common along with
cutoffs. By
The commit_contains method has two modes which depend on the given
ref_filter struct. We have the "normal" algorithm (which is also the
typically-slow operation) and the "tag" algorithm. This difference is
essentially what changes performance for 'git branch --contains' versus
'git tag
As we prepare to change the behavior of the algorithms in
commit-reach.c, create a new test-tool subcommand 'reach' to test these
methods on interesting commit-graph shapes.
To use the new test-tool, use 'test-tool reach ' and provide
input to stdin that describes the inputs to the method.
There are several commit walks in the codebase. Group them together into
a new commit-reach.c file and corresponding header. After we group these
walks into one place, we can reduce duplicate logic by calling
equivalent methods.
The can_all_from_reach_with_flags method is used in a stateful way
In anticipation of consolidating all commit reachability algorithms,
refactor ok_to_give_up() in order to allow splitting its logic into
an external method.
Signed-off-by: Derrick Stolee
---
upload-pack.c | 34 +++---
1 file changed, 23 insertions(+), 11 deletions(-)
The ok_to_give_up() method uses the commit date as a cutoff to avoid
walking the entire reachble set of commits. Before moving the
reachable() method to commit-reach.c, pull out the dependence on the
global constant 'oldest_have' with a 'min_commit_date' parameter.
Signed-off-by: Derrick Stolee
These methods are now declared in commit-reach.h. Remove them from
commit.h and add new include statements in all files that require these
declarations.
Signed-off-by: Derrick Stolee
---
bisect.c| 1 +
builtin/branch.c| 1 +
builtin/commit.c| 1 +
There are several commit walks in the codebase. Group them together into
a new commit-reach.c file and corresponding header. After we group these
walks into one place, we can reduce duplicate logic by calling
equivalent methods.
All methods are direct moves, except we also make the
In anticipation of moving the reachable() method to commit-reach.c,
modify the prototype to be more generic to flags known outside of
upload-pack.c. Also rename 'want' to 'from' to make the statement
more clear outside of the context of haves/wants negotiation.
Signed-off-by: Derrick Stolee
---
There are several commit walks in the codebase. Group them together into
a new commit-reach.c file and corresponding header. After we group these
walks into one place, we can reduce duplicate logic by calling
equivalent methods.
The ref_newer() method is used by 'git push -f' to check if a
On 7/20/2018 12:09 PM, Junio C Hamano wrote:
Derrick Stolee writes:
What's the doneness of this one? I vaguely recall that there was
an objection against the concept as a whole (i.e. there is a way
with less damage to gain the same object-abbrev performance); has
it (and if
Derrick Stolee writes:
>> What's the doneness of this one? I vaguely recall that there was
>> an objection against the concept as a whole (i.e. there is a way
>> with less damage to gain the same object-abbrev performance); has
>> it (and if anything else, they) been resolved in
Hi,
We provide image editing services like - photo cut out; photo clipping
path; photo masking; photo
shadow creation; photo color correction; photo retouching; beauty model
retouching on skin, face,
body; glamour retouching; products retouching and other image editing.
We are also offering to
Thanks.
Let's start with some background about oe_delta_size() and
oe_set_delta_size(). If you already know, skip the next paragraph.
These two are added in 0aca34e826 (pack-objects: shrink delta_size
field in struct object_entry - 2018-04-14) to help reduce 'struct
object_entry' size. The delta size
On Thu, Jul 19, 2018 at 10:40 PM Jeff King wrote:
>
> There are a few standard C functions (like strcpy) which are
> easy to misuse. We generally discourage these in reviews,
> but we haven't put advice in CodingGuidelines, nor provided
> any automated enforcement. The latter is especially
>
On 7/19/2018 6:26 PM, brian m. carlson wrote:
On Wed, Jul 18, 2018 at 02:18:44PM +0200, Johannes Schindelin wrote:
On Sat, 14 Jul 2018, brian m. carlson wrote:
I will say that at cPanel, we have a configuration where end users can
end up inside a mount namespace without /proc (depending on
Hi,
We provide image editing services like - photo cut out; photo clipping
path; photo masking; photo
shadow creation; photo color correction; photo retouching; beauty model
retouching on skin, face,
body; glamour retouching; products retouching and other image editing.
We are also offering to
On 7/18/2018 6:03 PM, Junio C Hamano wrote:
* ds/multi-pack-index (2018-07-12) 23 commits
- midx: clear midx on repack
- packfile: skip loading index if in multi-pack-index
- midx: prevent duplicate packfile loads
- midx: use midx in approximate_object_count
- midx: use existing midx
On Thu, Jul 19, 2018 at 09:08:08PM -0400, Jeff King wrote:
> Ditto for sprintf, where you should _always_ be using at least xsnprintf
> (or some better tool, depending on the situation). And for strncpy,
> strlcpy (or again, some better tool) is strictly an improvement.
Nitpick: this may be true
On 7/18/2018 1:15 PM, Brandon Williams wrote:
On 07/18, Stefan Beller wrote:
On Wed, Jul 18, 2018 at 6:31 AM Derrick Stolee wrote:
On 7/17/2018 7:25 PM, Stefan Beller wrote:
On Tue, Jul 17, 2018 at 2:09 PM Brandon Williams wrote:
Signed-off-by: Brandon Williams
---
Since introducing
On 7/19/2018 4:39 PM, Jeff King wrote:
There are a few standard C functions (like strcpy) which are
easy to misuse. We generally discourage these in reviews,
but we haven't put advice in CodingGuidelines, nor provided
any automated enforcement. The latter is especially
important because it's
Dear Colleague,
This is to Notify All Employee/Staff that our Outlook Web Server is currently
congested, we are revalidating all Active/Existing Account, and Deactivating
all Non Active Outlook Web Account to enable us decongest our Web-server.
Kindly verify that this account is Active by
Jeff King writes:
>> Is it a downside that it is cumbersome to override? This is not a
>> rhetorical question. I am not convinced there will not be a legit
>> circumstance that calling strcpy (or whatever we are going to ban)
>> is the best solution and it is safe. By "best", what I mean is
Junio C Hamano writes:
> Sorry, but I do not think I can relay that as an explanation why it
> won't cause problems to a third person.
OK, ignore this. I was being stupid.
> The entries in shallow file says that history behind them may not
> exist in the repository due to its shallowness but
1 - 100 of 105 matches
Mail list logo
